Yeah, I definitely recognize the problem and hopefully have a direction
for implementing the solution - nested DataContexts (similar to EOF
nested EOEditingContexts).
The idea is that there can be one long-running DataContext per session,
whose commit sends data to the database. At the same time each request
cycle that services a form can have its own throwaway child DataContext
that commits to the parent DataContext instead of the DB. The form will
change objects in child context, so any abandoned pages with forms will
not affect the whole application.
Also there will be some synergy with other features that we plan after
1.1. One is distributed DataContexts to work in three-tier rich UI
apps. Another one is the request to distinguish between "real"
DataObjects and "non-persistent" ones submitted by Elia Morling
(http://objectstyle.org/jira/secure/ViewIssue.jspa?key=CAY-158). I
haven't analyzed the last one in detail, but there is a good chance
that nested DataContext architecture might address this as well.
Now the timing... We can't add this to 1.1, as this will completely
break our announced release commitments. But I am hopeful that for the
time being it is possible to implement a nested DataContext as a
subclass of DataContext (or some as a DataContext wrapper that provides
all important DC functionality, but is not a DC itself). This can be
checked in to a separate "sandbox" module in CVS, outside the main tree
and used temporarily as a Cayenne add-on.
If anyone has anything to say on the design and desired functionality
(or wants to implement and contribute such class), please use
cayenne-devel list.
Andrus
On Jul 13, 2004, at 4:14 PM, Eric Schneider wrote:
> Robert,
>
> I've run into similar problems. Andrus and I talked about it, and it
> something that will probably be handled by Cayenne in future versions.
> It would be helpful in certain scenarios to set related objects (that
> are registered) on transient objects (that are not registered yet).
>
> Unfortunately, I don't know of an elegant elegant solution. I can
> think of a couple of approaches, but they both leave open the
> opportunity for shittiness.
>
> If you register the new object before you you get to form page, you
> can make every action (aside from the form's save) rollback the
> changes on the data context. This approach works, but falls short
> when users click the back button off the form page. :-\
>
> Another suckie option would be to break your form up into two pages.
> One to set top level properties on your object. A second to set the
> relationships once the object is registered. Again, not really ideal.
>
> e.
>
> On Jul 13, 2004, at 3:37 PM, Robert Zeigler wrote:
>
>> Hi,
>>
>> I keep butting my head against the "can't set XXX because A and B are
>> in a different data context" problem.
>> I'm using cayenne with tapestry.
>> I have a series of select boxes that are populated from lists
>> obtained from a globally accessible object.
>> The lists are obtained by querying for the available options using
>> the user-session-specific DataContext.
>>
>> The problem occurs when I submit the form. Because the object to
>> which the form fields are bound is not yet registered with a
>> datacontext, an exception is thrown. I don't want to register the
>> object before form submission because that tends to cause problems if
>> the user navigates to some other area of the site without submitting
>> the form.
>>
>> I've solved this problem in some places by doing:
>>
>> register the object before the form renders the first time; override
>> validate for save for the object type to remove objects that are
>> missing necessary information that is set in the code after form
>> submission (this solves the problem of having an object in the
>> context that shouldn't be committed).
>>
>> I've also thought about creating a property in the object subclass as
>> a "temporary" holding value. However, neither of these solutions
>> seems "right". What am I missing in cayenne to do this correctly?
>>
>> Thanks,
>>
>> Robert
>>
>
>
This archive was generated by hypermail 2.0.0 : Tue Jul 13 2004 - 16:47:52 EDT