Re: [Wicket-user] beforeCallComponent and afterCallComponent
import wicket.markup.html.WebPage;
if (page instanceof WebPage)
{
((WebPage)page).beforeCallComponent(component, method);
}
.
if (page instanceof WebPage)
{
((WebPage)page).afterCallComponent(component, method);
}
Is that realy a problem? It is not a dependency to another jar, isn't it?
Well, IMHO dependencies should always be justified, wether in the same
jar or not.
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.
I didn't write that, this is of course a bad idea.
If someone wants to forward the notification to the page, fine:
protected beforeCallComponent(Component component, Method method) {
getMyPage(component).,myBeforeCallComponent(component, method);
}
I'd prefer:
protected beforeCallComponent(Component component, Method method) {
getSpringInjector().injectDependencies(getPage(component));
}
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.
I'd call this a cumbersome approach: Why first forward to the page, just
to let the page turn back to the request to do lifecycle things? This
requires a common base class for all pages just to do this housekeeping.
Perhaps the modifier of invokeInterface(**Component,Method,Page) could
just be changed to protected. This way both solution would be possible.
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
[Wicket-user] beforeCallComponent and afterCallComponent
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:
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:
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:
/** 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
Re: [Wicket-user] beforeCallComponent and afterCallComponent
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
Re: [Wicket-user] beforeCallComponent and afterCallComponent
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 thetrick is (imo) that we should combine idea of reachability with theidea 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 thestrategy has to know how to collect specific info. Strategy 1 could
result in a url like we have now, strategy 2 could result in somethinglike http://myhost/myapp/admin?path=3,form1=12341,form2=some otherkey. I'm just thinking out loud, but the plan is to have something
that enables us to be really smart with state handling; the aboveexample has form1 that has a detachable model with an object key12341... that's the only thing needed for that form to bereconstructed, as the rest (in my example the form has only components
with compound property models nested) can be derived. Oh, and this hasbeen about urls so far, but I really mean something a little bit moreabstract, so that a strategy can decide whether to end up with anactual 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 tomounting servlets and I think Tapestry's application services worklike that?). Steps would be like:
1. request comes in, Wicket looks for the mounted strategy for thisspecific request.2. strategy parses the request and tries to get/ rebuild the componenttree. Two concrete case are: a strategy that just needs the page id,
and gets it out of the session, and a strategy for bookmarkable pagesthat needs the class name to create a page instance and then passes inthe 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 storedin the session, but that can be reacreated on a request.3. now that the component tree is available, optionally execute alistener 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 gofor the ultra scalability.EelcoOn 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
Re: [Wicket-user] beforeCallComponent and afterCallComponent
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
