But i was not talking about url generation
Just handling the component listeners (After the parsing of the url)
So pure the java side (so really the method where the talk is for now:
I was talking pure for this method:
private void invokeInterface(final Component component, final Method method, final Page page)
If it was me that method can be pushed to RequestCycle and made protected.
then you don't have to do this:
if (page instanceof WebPage)
{
((WebPage)page).beforeCallComponent(component, method);
}
but just this:
page.beforeCallComponent(component, method);
so page could have that method.
I agree the parsing right before that methods is somethign for WebRequestCycle
But the handling of it can go to RequestCycle itself.
I think that in every request cycle impl you will get that component interface handling
(that doesn't have anything to do with web/http)
On 10/28/05, Eelco Hillenius <[EMAIL PROTECTED]> wrote:
Yeah, we have done some ofline discussing on this topic too. For 1.2.
we could start thinking about a better model for handling urls.
Something like:
A. The creation of urls (e.g. for a link). Instead of letting urlFor
doing the whole url construction, we could have a strategy for this
(Igor wondered why we didn't have this in the first place). Now the
trick is (imo) that we should combine idea of reachability with the
idea of state management. That would mean letting components
contribute to that url constructing. Like: strategy implements the
'url stub' and collects the component's contribitions to this url.
What a url would look like however would be strategy dependend, so the
strategy has to know how to collect specific info. Strategy 1 could
result in a url like we have now, strategy 2 could result in something
like http://myhost/myapp/admin?path=3,form1=12341,form2=some other
key. I'm just thinking out loud, but the plan is to have something
that enables us to be really smart with state handling; the above
example has form1 that has a detachable model with an object key
12341... that's the only thing needed for that form to be
reconstructed, as the rest (in my example the form has only components
with compound property models nested) can be derived. Oh, and this has
been about urls so far, but I really mean something a little bit more
abstract, so that a strategy can decide whether to end up with an
actual url, or something like a set of hidden form fields. Maybe.
B. The parsing of a request. Again this would be done by strategies.
The idea would be to 'mount' strategies to url patterns (akin to
mounting servlets and I think Tapestry's application services work
like that?). Steps would be like:
1. request comes in, Wicket looks for the mounted strategy for this
specific request.
2. strategy parses the request and tries to get/ rebuild the component
tree. Two concrete case are: a strategy that just needs the page id,
and gets it out of the session, and a strategy for bookmarkable pages
that needs the class name to create a page instance and then passes in
the url parameters. But if we think this through well, we could end up
having the ability to work with pages that doesn't have to be stored
in the session, but that can be reacreated on a request.
3. now that the component tree is available, optionally execute a
listener method. Again the strategy decides when/ how this is done.
It's easier to talk about this than write it down in a short time.
Anyway, I think something like above is the direction we need to go
for the ultra scalability.
Eelco
On 10/28/05, Johan Compagner < [EMAIL PROTECTED]> wrote:
> My question about this is can anybody name a Page that isn't a webpage?
> And that would also have a own requestcycle? that doesn't use a
> componentListener?
>
> Why i ask this. Could componentListener handling not pushed to
> RequestCycle?
> What is so WEB about it?
>
>
>
> On 10/28/05, Juergen Donnerstag < [EMAIL PROTECTED]> wrote:
> > On 10/28/05, [EMAIL PROTECTED] <[EMAIL PROTECTED] > wrote:
> > > Regarding the newly added 'around functionality' of WebRequestCycle and
> WebPage.
> > >
> > > I certainly welcome this addition in the background of Spring
> integration and AOP, but I see some problems with this implementation.
> > >
> > > First of all we now have a new dependency to HTML markup in
> WebRequestCycle.java:
> > >
> >
> > WebPage are meant for HTML markup, which is why they have the prefix
> > "Web". The base clase Page is meant to be independent.
> >
> > > import wicket.markup.html.WebPage ;
> > > ....
> > > if (page instanceof WebPage)
> > > {
> > > ((WebPage)page).beforeCallComponent(component, method);
> > > }
> > > ......
> > > if (page instanceof WebPage)
> > > {
> > > ((WebPage)page).afterCallComponent(component, method);
> > > }
> > >
> > > Secondly WebPage.java has a new dependency on java.lang.reflect :
> > >
> >
> > Is that realy a problem? It is not a dependency to another jar, isn't it?
> >
> > > import java.lang.reflect.Method;
> > > ....
> > > public void beforeCallComponent(final Component component, final Method
> method)
> > > public void afterCallComponent(final Component component, final Method
> method)
> > >
> > > IMHO this lifecycle notification would be solved more elegant, if the
> latter two methods were moved into WebRequestCycle instead, serving as
> hooks:
> > >
> >
> > So your WebRequestCyle implementations will than look like
> > if (component is MyPageA)
> > ...
> > else if (component is MyPageB)
> > ..
> > else
> > else
> > else
> >
> > Not sure, this is the better approach. Turning your argumentation
> > around, one could say: create a common base BasePage which implements
> > before/afterXXX and invoke an appropriate implementation in
> > MyWebRequestCycle if you realy want to do that. Actually, I like the
> > current implementation a little bit better.
> >
> > > /** Unchanged javadoc **/
> > > protected void beforeCallComponent(final Component component, final
> Method method) {}
> > > /** Unchanged javadoc **/
> > > protected void afterCallComponent(final Component component, final
> Method method) {}
> > >
> > > I see the following benefits:
> > > - no new dependencies as described above
> > > - the reflection stuff is isolated in WebRequestCycle, were it's already
> used
> > > - more flexible since project specific subclasses of WebRequestCycle
> could easily
> > > ... apply their aspects (e.g. inject dependencies with Spring) from
> *outside* of their pages
> > > ... forward these lifecyle notifications into their pages (as the
> current implementation) if they really need to.
> > >
> > > Please reread the javadoc of beforeCallComponent() and
> afterCallComponent() as if they were already located in WebRequestCycle,
> IMHO they make much more sense there.
> > >
> > > Thanks
> > >
> > > Sven
> > >
> > >
> > > -------------------------------------------------------
> > > This SF.Net email is sponsored by the JBoss Inc.
> > > Get Certified Today * Register for a JBoss Training Course
> > > Free Certification Exam for All Training Attendees Through End of 2005
> > > Visit http://www.jboss.com/services/certification for
> more information
> > > _______________________________________________
> > > Wicket-user mailing list
> > > Wicket-user@lists.sourceforge.net
> > >
> https://lists.sourceforge.net/lists/listinfo/wicket-user
> > >
> >
> >
> > -------------------------------------------------------
> > This SF.Net email is sponsored by the JBoss Inc.
> > Get Certified Today * Register for a JBoss Training Course
> > Free Certification Exam for All Training Attendees Through End of 2005
> > Visit http://www.jboss.com/services/certification for
> more information
> > _______________________________________________
> > Wicket-user mailing list
> > Wicket-user@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/wicket-user
> >
>
>
-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc.
Get Certified Today * Register for a JBoss Training Course
Free Certification Exam for All Training Attendees Through End of 2005
Visit http://www.jboss.com/services/certification for more information
_______________________________________________
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
