Eelco Hillenius wrote:
Thanks for thinking,
-Every component can only contain models as data. This isn't to big a
deal, but it's a limitation.
Some components have data themselfs.. Stored as a instance var..
So you really have to serialize also the component and not only its
model.. (and that is a pitty/limitation)
For components that don't have internal state. You could just say that
it is a ComponentX with id ='xx' instance.
with ModelData Y (if model is not a shared/compound model from a parent
because then you don't have to serialize the model)
But what will it cost to serialize a deattached page (with deattached
models i mean) and all its components and everything a component can get to.
I see that most things in a page is transient except for example the
version manager..
And if we serialize state to the client this isn't needed anymore so
that one doesn't have to be serialized.
-Somehow a form needs to get onto pages that wouldn't normally have
them.
Yep. We could do that I think. Juergen was able to insert <header>
elements when needed. Does anyone know whether we /really/ need the
form (I know that is what .NET and JSF are doing), or that there might
be a javascript trick to do this?
i think we ajax you could make a post... without a form..
Don't know any other way currently.
-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.
yes one hidden field (or other javascript variable) in the generated
form that is used by links
And all other forms should copy that variable when they are going to be
submitted. So they also should auto have that hidden field.. (but not set)
-Recreating every model object on every request may give the garbage
collector a whole lot of work. Especially on forms where there's
really only one model, but every field has a property model.
True. We should come up with something smarter than that.
That's compound....
Then all fields have null models.
-To really do this right, some kind of page pooling would have to be
implemented.
Dunno. I am thinking about a per-page persistence strategy now (just
to keep things simple). The server state strategy would work as
currently (gets the page from the session, and stores new pages in the
session). The client state strategy would work like: instead of
getting from session, just create a new page instance and apply state
from incomming request.
yes serializing one page is enough except if an other page is a variable
inside a component.
For example a link could have an onClick event that transfers them to
the previous page. Then that page must also be serialized because else
that link wouldn't work anymore.
johan
-------------------------------------------------------
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_id=7477&alloc_id=16492&op=click
_______________________________________________
Wicket-develop mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-develop
