Thanks for thinking,
Phil Kulak wrote:
Okay, I've been playing with this for a bit now, and I think it's one
of those problems where doing it is not be that hard, but doing it
RIGHT may be. Right now I've got a PersistanceStrategy rewriting links
and added fields to forms all over the page, which I don't think is
the way to go. I think that to do it properly all components that
require any sort of callback need to be aware of the state storage
strategy, or at least be removed from being so URL-centric. URLs are
no longer of any use when a link is submitting a form, for example,
but the interface to call still is. Anyway, here are some of the
issues:
-Every component can only contain models as data. This isn't to big a
deal, but it's a limitation.
That is not a inherit limitation though? I mean, both components and
models can 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?
-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.
-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.
-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.
To sum it up: this is a tough problem, probably because Wicket is so
server-side oriented. The up side, of course, is that Wicket works so
well with server-side state that there's little reason for client
state. I was kindof hoping I would have a eureka moment and it would
all fall into place, but since that doesn't look like it's going to
happen, I'm going to shelf this idea for a bit. Any other thoughts are
welcome.
Yeah, it's a tough one. It is good to think, play and then rest for a
bit again, so you might get fresh ideas when resting. And discussing
ideas on this list is very helpfull as well.
Eelco
-Phil
On 7/2/05, Phil Kulak <[EMAIL PROTECTED]> wrote:
Wouldn't that mean proxying the component I wanted to add markup to?
If I wanted to add a form and one hidden field somewhere in the HTML
body, is there anything I could do apart from filtering the response?
On 7/2/05, Juergen Donnerstag <[EMAIL PROTECTED]> wrote:
Is it possible to run through a component tree and add xml
tags before it renders? That's the only piece I can't figure out.
visitChildren() allows you to recursively visit all children of a
container (Page) and subclassing one the onXXX() methods e.g.
onBeginRequest(), onRender(), onComponentTag() should allow you to add
xml to the response prior to the tag, after the opening tag, etc.
Juergen
-------------------------------------------------------
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&opclick
_______________________________________________
Wicket-develop mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-develop
-------------------------------------------------------
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
-------------------------------------------------------
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
