Indeed, I find it highly inconsistent and problematic.
Why should url parameters and hidden form field objects be stored
differently if they are for a "hidden form field" or "listener" vs. if
they are for client side persistence? If you are using forms and posts
to do the client side persistence, then the objects are getting written
to hidden form fields. If you are using get, then they are written to
the URL. I see no reason for the difference. Personally, I use
cayenne; I wrote a cayenne squeeze adapter; the fact that I would have
to handle objects different for client side persistence essentially
relegates the usefulness of client-side persistence, for me, to about 0.
I suspect that there was some motivation behind this decision (because,
obviously, a consistent developer experience wasn't it), but I don't
know what that motivation was. Anybody who /does/ know the motivation
want to comment on it?
Robert
Vjeran Marcinko wrote:
> Hi all.
>
> Robert probably knows that he can overcome his problem by manually
> taking care of entity's ID, but whole point of having custom
> DataSqueezer in application should be that developer should never again
> have to worry what part of entity is being squeezed, and how it is being
> unsqueezed afterwards.
>
> As said, it all works nicely for listener parameters and form fields,
> but strangely, same mechanism hasn't been utilized for client persistence.
> Not that it bothers me, since I never used custom DataSqueezers, but I
> think I understand Robert's confusion.
>
> -Vjeran
>
> ----- Original Message ----- From: "Ron Piterman" <[EMAIL PROTECTED]>
> To: <tapestry-user@jakarta.apache.org>
> Sent: Tuesday, November 01, 2005 9:19 PM
> Subject: Re: Persist large objects
>
>
> I did not quite follow Henri's idea.
> I would do exacly as you suggest- persist just the id and use it.
> *maybe* that will work:
>
> <property name="id" persist="..."/>
> <property name="object" initial-value="populateId(id)"/>
>
> public Object populateId(Object id) {
> return ....;
> }
>
> Cheers,
> Ron
>
>
> ציטוט Martin Strand:
>
>> Ok, does that mean that the best way is to persist the object id and
>> then simply re-create the object myself on each request?
>> That's what I'm doing now, I just found that the same set of methods
>> (detach(), get/setSomeObject(), @Persist get/setSomeObjectId()) keeps
>> repeating itself in several of my page classes, so I figured perhaps
>> Tapestry could give me a hand. :)
>>
>> --Martin
>>
>> On Tue, 01 Nov 2005 17:44:27 +0100, Howard Lewis Ship
>> <[EMAIL PROTECTED]> wrote:
>>
>>> The client property persistent manager doesn't use the data squeezer;
>>> it always serializes a bunch of objects to a MIME64 stream. A
>>> DataSqueezer is used for objects encoded as listener parameters or as
>>> hidden form fields.
>>>
>>> On 11/1/05, Robert Zeigler <[EMAIL PROTECTED]> wrote:
>>>
>>>> Create a custom data squeezer for your object and register it.
>>>>
>>>> Robert
>>>>
>>>> Martin Strand wrote:
>>>> > Hi.
>>>> > I want to persist a large object on the client, but it would be much
>>>> > better if I could just persist its id and then re-create it on the
>>>> > server on each request. Can Tapestry do this for me? I could do it
>>>> > myself, something like this:
>>>> >
>>>> > ----
>>>> > private User user;
>>>> >
>>>> > public void detach()
>>>> > {
>>>> > user = null;
>>>> > super.detach();
>>>> > }
>>>> >
>>>> > public User getUser()
>>>> > {
>>>> > if (user == null)
>>>> > {
>>>> > user = new User(getUserId());
>>>> > }
>>>> > return user;
>>>> > }
>>>> >
>>>> > @Persist("client:page")
>>>> > public abstract int getuserId();
>>>> > ----
>>>> >
>>>> >
>>>> >
>>>> > But I'd prefer to let Tapestry do it for me, something like this:
>>>> >
>>>> > ----
>>>> > @Persist("client:page")
>>>> > public abstract User getUser();
>>>> > ----
>>>> >
>>>> > How could I make the second version understand that it only needs to
>>>> > persist the user id?
>>>> >
>>>> > Thanks,
>>>> > Martin
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
