We choosed another way:
We have strictly separated view and data.
The view builds a session (with user info)
and all data requests are submitted to the data tier
with the belonging session data.
So we pretty separate developement of views and businesslogic.
What we've done in detail looks quite like the idea of andrus,
but we build our own Context Object very near to the session,
which always is master of all processes.
andru..bjectstyle.org schrieb am 06.12.04 23:12:26:
>
> Yeah, that's a pretty common situation when you have to populate some
> DataObject properties with external data (i.e. data not available within
> DataObject itself) in certain points of the object lifecycle. I think
> having a subclass of DataContext is entirely reasonable.
>
> Another technique (I am mentioning it here as a possibility, I never use
> it myself) is to bind objects carrying such information to a current
> execution thread, kind of like we do for ThreadLocal DataContexts.
>
> Re: "WILL_COMMIT". I guess in the meantime we need to fix that and fire it
> prior to validation (could someone please open an issue in Jira?) On the
> long run we need to think of a big picture for DataObject lifecycle and
> come up with some consistent design. Expanding a delegate maybe a good
> solution. It will be more simple and efficient than to send events... And
> if events are needed, a delegate can post them in a more customizable way.
>
> Andrus
__________________________________________________________
Mit WEB.DE FreePhone mit hoechster Qualitaet ab 0 Ct./Min.
weltweit telefonieren! http://freephone.web.de/?mc=021201
This archive was generated by hypermail 2.0.0 : Tue Dec 07 2004 - 03:57:44 EST