i prefer a simple factory method on pages that construct
pageparameters or even an entire bookmarkable page link...
PageParameters params=Leaderboard.newPageParameters(someType, someDays);
add(new BookmarkablePageLink("id", Leaderboard.class, params));
or just
add(Leaderboard.newBookmarkableLink("id", someType, someDays));
encapsulation without all the overhead of annots, etc
-igor
On Sat, May 3, 2008 at 2:25 PM, Doug Donohoe <[EMAIL PROTECTED]> wrote:
>
> One thing that is valuable is encapsulation. For example, take my
> Leaderboard class which has two main inputs via PageParameters:
>
>
>
> static final String PARAM_TYPE = "type";
> static final String PARAM_DAYS = "days";
>
> Now, using the current metaphor, I when I want to mount using a MixedParam
> strategy, I have to (a) expose these as public and (b) then add code in my
> init() method like:
>
> mount(new MixedParamUrlCodingStrategy("leaderboard", Leaderboard.class,
> new String { Leaderboard.PARAM_TYPE, Leaderboard.PARAM_DAYS});
>
> I'm exposing information I don't really want to. Instead, why I'm doing now
> is:
>
> @MountPath(path = "leaderboard")
> @MountMixedParam(parameterNames = {Leaderboard.PARAM_TYPE,
> Leaderboard.PARAM_DAYS})
> public class Leaderboard extends WebPage { ... }
>
> If I add or change the PARAMS, I only have to change Leaderboard - it
> controls how it is mounted rather than up at the Application level.
>
> If somebody else wants to use this page and change the mount point, they can
> subclass:
>
> @MountPath(path = "my/leaderboard")
> public class MyLeaderboard extend Leaderboard
>
> The @MountMixedParam annotation is inherited wherea the @MountPath is not.
> I haven't tested this yet (I'll add it to my unit test), but you could also
> specify a different mount strategy than MixedParam if you wanted to override
> that.
>
> If a class is not annotated with @MountPath, it is not mountable (via
> annotations).
>
> If you just define @MountPath and no supporting annotation, it defaults to
> BookmarkablePage...Strategy.
>
> Regarding multiple mounts, I could add that by making path a string array -
> I wasn't sure how often that was used because the way
> WebRequestCodingStrategy.getMountEncoder works is that it picks the first
> one it finds (when mapping a class to a mount path).
>
> For the curious, @MountMixedParam is defined as follows:
>
> @Target({ ElementType.TYPE })
> @Retention(RetentionPolicy.RUNTIME)
> @MountDefinition(strategyClass = MixedParamUrlCodingStrategy.class,
> argOrder = {"pageMapName", "parameterNames"})
> @Inherited
> @Documented
> public @interface MountFixedMixedParam
> {
> String pageMapName() default MountDefinition.NULL;
>
> String[] parameterNames();
> }
>
> This basically defines how to construct the mount strategy class and what
> the params are. One of these would need to be defined for each of the
> half-dozen or so UrlCodingStrategies. We could make them inner interfaces
> to keep the definition with the class.
>
> Note that this mechanism allows for easy extension by end-users.
>
> I'm using this in my site and it is quite nice.
>
> I'll post more details later - I'm still testing, etc.
>
> -Doug
>
>
> Johan Compagner wrote:
> >
> > personally i dont see any added value.
> > It is stil a line of "code", no gain here.
> > then scattered throughout your code base
> > also you have to make sure that you can have then multiply of those mounts
> > for 1 class
> > i use the same pages under different mounts..
> >
> > also what happens if you package your pages and somebody else uses it
> > or you start to also use them in an other project...
> > But that doesnt want those mount points... what then? you cant remove them
> > because then the first app breaks...
> > I still think mounting and stuff is something the Application is
> > responsible
> > for not the web app itself.
> >
> > I could see an annotation like: @Unmountable ...
> > Because it is sort of a security hole in wicket now. If a page has a
> > default
> > constructor and i know the name i could just show it... (of no other
> > security prevents that)
> > Ofcourse this is very hypothetical and not very likely that it will be
> > abused because you have to know classnames (but these can spoil out when
> > not
> > carefull with shared resouces..)
> >
> >
> > johan
> >
> >
>
> --
> View this message in context:
> http://www.nabble.com/how-to-contribute---wicket-1.4-plans-tp17034501p17039998.html
> Sent from the Wicket - Dev mailing list archive at Nabble.com.
>
>
