Cris Daniluk wrote:
> We do a slight variation on this - I wrote a simple object holder that lets
> you put objects into the session scope and retrieve them by their hashCode
> (or the hashCode of the ObjectId in this case). This relies on DataObject
> and its ObjectId To Do The Right Thing as far as unique hashCodes go, but it
> hasn't been a problem yet. Then, we can just pass the hashCode in string
> form via the request scope or however appropriate. I do prefer the hashCode
> to a random key, as it adds a more consistent behavior.
Hashcode would be a suitable approach. But... from my perspective, at
least, an ISqueezeAdaptor implementation is something that allows one to
/not/ store anything in persistent server-memory... right? =) I mean...
if I'm going to store the object/list of objects in the session, I may
as well utilize tapestry persistent properties and forget the data
squeezer. =) Thoughts?
>
> Incidentally, I use the same object holder to register lists containing
> DataObjects as well, and can pull back a specific DataObject as a
> combonation of the list and object hashCodes. It's a cheap way to handle
> dropdowns in wizards, etc.
>
> The only downside to this method is the pollution of the session scope. The
> reason I used an object holder was to add the ability to clean up via TTLs.
>
>
>>3) I've thought about deregistering the object, serializing
>>it, and then
>> reregistering the object on reserialization. As far as I can
>>tell, this
>>means that you would lose relationship-information, but
>>retain attribute
>>information.
>
>
> I also do this occasionally, for simple objects. It doesn't work whenever
> the interface needs to traverse the relationships, but for the simple cases,
> its quick, clean, and very understandable. Unfortunately, there are quite a
> few cases where you need to maintain those relationships.
Too true. =) On the other hand... we're dealing with the case of an
object in a "new" state (vs. hollow, committed, uncommitted, etc.).
Usually if its
> complex enough, I write a custom domain object that acts as a sort of
> adapter to the DataObject. It results in annoying duplication of fields, but
> then again, if "O" and "R" fit perfectly together, who would ever even think
> about using an object database :) Besides, so far in my experience with
> Cayenne, that has only been 1-2 times, and in situations that are so
> intimate to the domain problem that the decoupling from the repository is
> very desirable.
>
> Just a word of caution.. for existing objects, I generally retrieve the
> object back from its persistent state and then copy the properties (either
> via reflection or write/readProperty or whatnot). This ensures that the
> object stays unique.
The adaptor as it stands will generally grab the existing object from
the data context (which will fetch from the db as needed). It's only the
case of an object which is newly registered with a data context, but
which hasn't been committed, which is the problem. As far as
duplication/etc., goes, what I've started doing is to create raw objects
which are "lost" between requests; when a form/whatever is submitted,
the objects are created via the dataContext.createAndRegisterNewObject;
this keeps both tapestry and cayenne happy, but does require the work to
do the object instantiation at render time, and a check for is rewinding
or not.
>
>
>>4) Throw an exception informing the developer of their bad habits. =)
>>
>
> I think some solution to this problem, even if it doesn't solve every
> possible case, is required. Otherwise, you end up duplicating what
> effectively amounts to all of your domain objects, in some manner of
> speaking.
True.. either you duplicate the object by creating an adaptor object, as
you've mentioned, or duplicate the object in the fashion I've described
above, or else you have other properties that act as "holders", and then
create the objects and set the properties at form submission; this also
results in duplication in some form.
>
> Just my 2 cents though... obviously the solution depends, among other
> things, very substantially on project-specific stuff like resource
> contention, etc., so there is no "right" or "wrong" choice.
True... but I'm seeking a very general "works right in the majority of
the situations" solution... something which I could donate back to the
community for other people to use without significant (or any?)
modifications. =) So... I think I handle 2 of 3 cases well... it's only
when a developer creates and registers a new object and then tries to do
something with it that requires squeezing, without first committing the
object to the db. Anyway... thanks for the feedback; definitely some
food for thought. =)
Robert
This archive was generated by hypermail 2.0.0 : Mon Apr 04 2005 - 17:39:10 EDT