about that class path scanning..
is spring taken into account that you can have wicket components packages
and added throught OSGI?
What class loaders does it use?
johan
On Sun, May 4, 2008 at 3:57 PM, Doug Donohoe <[EMAIL PROTECTED]> wrote:
>
> Hi Johan,
>
> Yes, I came across that issue late yesterday - a small oversight :-). I'm
> still
> getting to know the framework. However, all is not lost. The bulk
> of my work was getting the annotations working properly. It will
> be easy to go back my original idea of classpath scanning via some
> Spring utility classes. They are quite fast (in answer to the question
> about speed). You can also limit the scan to a portion of the classpath
> e.g., "classpath*:com.donohoedigital".
>
> This probably means it will have to go into a wicket stuff project
> at least at the start.
>
> I'm working the switch this morning. It shouldn't take too long as I
> already have the code written to class-path scan for an Annotated
> class that I used in another part of my code base.
>
> -Doug
>
>
>
> Johan Compagner wrote:
> >
> > So you create mounts on the fly when a setResponsePage(Class) is set?
> > How do you do it the other way around? If the mount didnt happen yet
> > by a setResponsePage call but there is a url coming in?? This can
> > happen just fine if you had to restart the server or something.
> >
> > On 5/4/08, Doug Donohoe <[EMAIL PROTECTED]> wrote:
> >>
> >> Yes, you can do that. But I prefer not to have to modify Application
> >> when I
> >> add a new page. With an annotation-based approach, I define a page,
> >> annotate it and then I'm done.
> >>
> >> Really, this is just a philosophical difference. Rather than argue
> which
> >> is
> >> better, we could offer both. Annotation usage is a matter of
> preference.
> >> Some people will want to use it; others not. Adding mounts in the
> >> application init() method may make more sense for some applications
> than
> >> others. In my application, I think using annotations is much simpler.
> >>
> >> The code I have is working and is pretty non-invasive change to
> >> WebRequestCodingStrategy (see below for how I did it via subclassing).
> I
> >> need to get Wicket building in my environment so I can figure out where
> >> to
> >> put the annotation classes so I can submit a patch.
> >>
> >> -Doug
> >>
> >> public class AnnotationAwareWebRequestCodingStrategy extends
> >> WebRequestCodingStrategy
> >> {
> >> @Override
> >> protected IRequestTargetUrlCodingStrategy
> >> getMountEncoder(IRequestTarget
> >> requestTarget)
> >> {
> >> IRequestTargetUrlCodingStrategy strategy =
> >> super.getMountEncoder(requestTarget);
> >>
> >> // if no strategy found, see if there is one we can create via
> >> annotations
> >> if (strategy == null)
> >> {
> >> strategy = getAnnotatedMountEncoder(requestTarget);
> >> if (strategy != null)
> >> {
> >> mount(strategy);
> >> }
> >> }
> >> return strategy;
> >> }
> >>
> >> protected IRequestTargetUrlCodingStrategy
> >> getAnnotatedMountEncoder(IRequestTarget requestTarget)
> >> {
> >> IRequestTargetUrlCodingStrategy strategy = null;
> >>
> >> // If this is a bookmarkable page reqeuest, see if it has a
> mount
> >> annotation
> >> if (requestTarget instanceof IBookmarkablePageRequestTarget)
> >> {
> >> // Look for @MountPath annotation on the page class
> >> IBookmarkablePageRequestTarget target =
> >> (IBookmarkablePageRequestTarget)requestTarget;
> >> Class<? extends Page> pageClass = target.getPageClass(); //
> >> FIX:
> >> this may change in Wicket 1.4
> >> strategy = getAnnotatedMountEncoder(pageClass);
> >> }
> >> return strategy;
> >> }
> >>
> >> protected IRequestTargetUrlCodingStrategy
> >> getAnnotatedMountEncoder(Class<? extends Page> pageClass)
> >> {
> >> // ... meat of the code here ...
> >> }
> >>
> >>
> >> igor.vaynberg wrote:
> >> >
> >> > 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.
> >> >>
> >> >>
> >> >
> >> >
> >>
> >> --
> >> View this message in context:
> >>
> http://www.nabble.com/how-to-contribute---wicket-1.4-plans-tp17034501p17040515.html
> >> Sent from the Wicket - Dev mailing list archive at Nabble.com.
> >>
> >>
> >
> >
>
> --
> View this message in context:
> http://www.nabble.com/how-to-contribute---wicket-1.4-plans-tp17034501p17046767.html
> Sent from the Wicket - Dev mailing list archive at Nabble.com.
>
>
