I'm fine with any changes on the short term if that makes it better
for people to use. For the longer term (1.2.), we should re-think more
about generalizing it. It's probably not difficult either, just a lot
of thinking before implementing.
Eelco
On 10/28/05, Johan Compagner <[EMAIL PROTECTED]> wrote:
> Would be very nice to give it some though
> 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
> >
>
>
-------------------------------------------------------
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
