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
