How to use a binding framework efficiently

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

回答1:

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.

回答2:

The question did not open me very well, but if the case is that you want to elegantly save publish dates, why don't you leave database to do it for you. On Mysql you have example here where the database saves the lastChanged data automatically for user.

Also database triggers may make sence for you. At least I see automatical exact database queries better solution than a bunch of hacks inside the code making those things.

I do hope these answered your question or even the right question in mind.