Yeah, that could be a code saver. Personally I like just private
classes better. I use that when annonymous classes get too big/ messy.
The big advantage over not using introspection is that you can easily
track down how it is called from your IDE, you won't mess up with
refactoring and stepping through an execution is easier as you don't
get the ugly reflection stuff in your face. Otoh, using relection
could help you keep your code smaller. I wouldn't be for putting such
a component in link, as I believe we shouldn't encourage this as a
best practice. However, as a nice alternative, I can see such a
component live in Wicket extensions.

Btw, what should add(new ReflectionLink("myLink", "myMethod")) call?
where does myMethod live? It's parent? The page? See, it's already
less clear compared to non-reflective java code.

There are basically three options how this link could work:
1) it invokes the method on the parent
2) it invokes the method on the page
3) you explictly define the object the method is invoked on

I think 3) would be best as it is always clear what happens, can
immediately be checked on validity (is the method available) and it's
also the most flexible way then enables you e.g. to pass command
objects.

Furthermore, I don't thing the click method suffices: it probably
needs the invoking component to be passed in as a call argument, so
that you can e.g. get it's model.

Eelco


On 3/31/06, Alex <[EMAIL PROTECTED]> wrote:
> Hi,
> we've been using wicket for about a month now, so far so good.
> The only complain is about code lisibility, sometimes our constructors
> are filled with a lot of code, particurally with all the :
>
> add(new Link("myLink")
>         {
>             public void onClick(RequestCycle cycle)
>             {
>                 // do something here...
>             }
>         );
>
> The "//do something here" can be quite large. Of course you can put that on a
> custom method...
> Coming from a WebObjects background, we're used to clean, small Java code
> associated with pages (component instanciation, binding data to component, are
> in other files).
> So we thought a custom component subclassing Link could force this approach :
>
> in constructor :
>
> add(new ReflectionLink("myLink", "myMethod"))
>
> and elsewhere :
>
> public void myMethod() { // do something here ... }
>
> Basically the ReflectionLink would contain some reflection stuff in
> onClick(RequestCycle cycle) to invoke our method...
>
> With that you get the separation between "init code" and "action code"
>
> What do you think ?
>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by xPML, a groundbreaking scripting language
> that extends applications into web and mobile media. Attend the live webcast
> and join the prime developer group breaking into this new coding territory!
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
> _______________________________________________
> Wicket-user mailing list
> Wicket-user@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wicket-user
>


-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid0944&bid$1720&dat1642
_______________________________________________
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Reply via email to