如何有效地使用绑定框架 [英] How to use a binding framework efficiently
问题描述
我一直在使用绑定框架一段时间，我想知道你如何处理这种情况。
你有一个报纸有一些属性如
- （String）标题
- （布尔值）已发布
- （日期）publishmentDate
在您看来，您有一份报纸列表，可以同时编辑所有。这意味着您可以在单个请求中更改所有报纸的标题或所有状态发布。
事实是，正如我们正在使用绑定框架，您将编辑报纸的数据，就像您正在编辑数据库中的数据一样，将每个值绑定到一个字段，彼此独立。
但是，我想做的是，当我发布报纸时，publishmentDate将更新为当前日期。
我可以肯定在表单上放置一个publishmentDate字段，甚至设置为当前日期的隐藏字段...但这不是干净或安全的。
我认为最好有一个动作publish（）将flag设置为true，但也更新publishmentDate（和其他逻辑，如果需要...）
我只是想知道你是如何处理的？
我已经看到并考虑过不同的方法：
1）有时我们将新参数绑定到现有的持久性ORM实体。
这意味着我们在绑定之前检索实体，以便将值绑定到现有的已经填充实体对象。这有时被称为保湿实体
因此，知道是否必须启动发布操作的唯一方法是通过将旧字段与新字段进行比较，以便知道是否被编辑哪个方向（false-> true = publish）
可以使用一个ORM监听器（如@PostLoad，一个Hibernate Interceptor / EventListener或其他任何东西），以便保留这些绑定前所需的值。 / p>
这个工作很好，但是对车辆启动发布动作相当奇怪，而绑定已经将发布的标志设置为true。
2）可以做几乎相同的事情，但要使用另一个标志...例如代表用户希望的标志发布报纸
因此，您不必与以前的值进行比较，您只需检查用户是否希望发布报纸，然后启动操作...（和真正发布的标志当你推出a时，还是= false这个时候...）
事实是，当你使用绑定框架时，你希望在你的视图上检查已发布的复选框，以便已经有报纸已发表。
所以如果绑定的属性现在publish_wish，你必须设置一个值，否则所有的复选框将永远不会被选中...
这意味着你会在显示视图之前，做一些像published_wish = published
大多数时候，希望标志不会被持续，但是我看到一些情况下，愿望必须坚持，因此不需要做published_wish = published
3）对绑定使用一个空的非持久化实体，然后将该非持久化实体的值重新复制到实际持久对象
所以当你将值从一个对象重新映射到另一个对象时，你可以启动任何你想要的动作，自定义所有的东西...
但是重新复制所有这些参数...
可能还有其他方法可以...
你会怎么做？所以这不是很好，但它也是优雅，可维护 ...我没有看到任何完美的解决方案在这里
我同意你的意见，我也会在这种情况下使用发布按钮（也可能是取消发布按钮），允许用户选择多个文章并将其全部发布一旦。我不允许用户直接编辑发布复选框和发布日期。
I've been using binding frameworks for a while now and i'd like to know how you handle this cases.
You have a newspaper that has some attributes like
- (String) headline
- (Boolean) published
- (Date) publishmentDate
On your view, you have a list of newspapers, than can be edited all in the same time. This means you can change the headlines of all newspapes, or all their state "published" in a single request.
The matter is that, as we are using a binding framework, you will edit the newspapers' data a bit like if you were editing the data in a DB... binding each value to a field, independently from each others.
But... what i'd like to do is that when i publish a newspaper, the publishmentDate is updated to the current date. I could for sure put a publishmentDate field on the form, or even a hidden field setted to the current date... But this is neither clean or secure.
I think it's better to have an action publish() that will set the flag to true, but also update the publishmentDate (and other logic if needed...)
I just wonder how do you handle that?
I've seen and thought about different approaches:
1) Sometimes we bind the new parameters to an existing persistent ORM entity. This means we retrieve the entity just before the binding, so that we bind the values to an existing, "already filled" entity object. This is sometimes called "hydrating the entity" Thus the only way to know if you have to launch a "publish action" is by comparing the old field with the new one, so that you know if it was edited and in which direction (false->true = publish) It's possible to use an ORM listener, (like @PostLoad, a Hibernate Interceptor/EventListener or anything else) so that you keep these "before binding" values you need.
This works nice but it's quite "weird" to launch a publish action on the vehicle, while the binding already set the published flag to true.
2) It's possible to do nearly the same thing but to use another flag... for exemple a flag that represents the user wish to publish a newspaper. Thus you don't have to compare with the previous value, you just check if the user wish to publish a newspaper and then launch the action... (and the real published flag was still = false when you launched the action this time...)
The matter is that as you are using a binding framework, you want the published checkbox to be checked on your view for newspapers that have already been published. So if the attribute for binding is now published_wish, you'll have to set it a value or all your checkboxes will always be unchecked... This means that you'll have, before showing the view, do something like published_wish = published Most times the wish flag will not be persisted, but i've seen some cases where the "wish" MUST BE persisted, thus no need to do published_wish = published
3) Use an empty non persisted entity for the binding, then recopy the values of this non persisted entity to the real persisted object. So when you recopy the values from one object to the other, you can launch any action you want, customize everything... But it's a bit heavy to have to recopy all these parameters...
There may be other ways to do...
How would you do that? So that it doesn't just work well, but it is also elegant, maintenable... i don't see any perfect solution here
I agree with you and I would also use a Publish button in this case (with possibly an "Unpublish" button as well), allowing the user to select multiple articles and publish them all at once. I wouldn't allow the user to edit the Published checkbox and the publication date directly.
这篇关于如何有效地使用绑定框架的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
