Thanks for your input, Eelco.

On 7/5/05, Eelco Hillenius <[EMAIL PROTECTED]> wrote:
> 
> That is not a inherit limitation though? I mean, both components and
> models can be serialized.

I'd like to keep as much data out of the serialization stream as
possible though, and serializing the whole component tree is a waste
since it can be recreated on the server so easilly. That's why it's
nice that Wicket is so model oriented: it's easy to seperate the data
from the presentation.

> >-Contributing JavaScript to the header would be nice. It can be
> >embedded in every link, but this wastes bandwidth.
> 
> That's possible in current HEAD. I'm not sure what you mean though... Do
> you mean the serialized state? If possble, I'd try to just let it be one
> hidden field for the whole page. That means some merging and stuff, but
> my guess is that it is much more efficient.

No, I just mean JavaScript helper functions to reduce the amount of
inline code on every link. The way I was doing it actually had two
hidden fields on the page, one with the serialization string and one
that was blank and filled in with the submitting component's path when
the form is submitted so that the server would know what event
triggered the submit. Doing all that inline made the links a bit long.
It's good to hear that we can put that stuff in the head now.


-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id492&op=click
_______________________________________________
Wicket-develop mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-develop

Reply via email to