One thing that is valuable is encapsulation. For example, take my
Leaderboard class which has three 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.
