I put it on my todo list. I'm currently cleaning up the markup
inheritance and header support sources which I would like to finish
first

Juergen

On 8/14/05, Jonathan Locke <[EMAIL PROTECTED]> wrote:
> 
> maybe juergen would be willing to do this from our comments... he's the
> markup guy these days...
> 
> Jonathan Locke wrote:
> 
> >
> > yes.
> >
> > not sure when i can get to this, but hopefully someone will get it
> > done for 1.1...
> >
> > Seth Ladd wrote:
> >
> >> On 8/13/05, Jonathan Locke <[EMAIL PROTECTED]> wrote:
> >>
> >>
> >>> to do page name resolution you might extend some kind of
> >>> AbstractMarkupLocator
> >>> with default functionality that uses a replaceable
> >>> resourcestreamlocator
> >>> to actually
> >>> load stuff.  then to locate the markup, just mangle the class in your
> >>> ShortClassNameMarkupLocator
> >>> implementation and call the base class loader functionality... make
> >>> sense?
> >>>
> >>
> >>
> >> Ahh, I think I see where we are "crossing streams".  I'm coming from a
> >> delegating/composition background, so I was looking for a solution
> >> that didn't require subclassing anything.  Instead, I was looking at
> >> the solution that broke the algorithm up and used the Template pattern
> >> to delegate the details to other classes (say, for example, the
> >> details of resolving the page name).
> >>
> >> You're suggesting the inheritence approach, where I subclass the
> >> default behavior and override the generatePageName() method.
> >>
> >> Sounds fine to me.  Do me a favor, and provide the "name resolution"
> >> method as protected.  This way, the subclass needs only to override
> >> that method, and never has to override the getMarkup() method.  Just
> >> have getMarkup() delegate to that method for name resolution (the
> >> default impl simply returns the FQCN).
> >>
> >> Seth
> >>
> >>
> >> -------------------------------------------------------
> >> SF.Net email is Sponsored by the Better Software Conference & EXPO
> >> September 19-22, 2005 * San Francisco, CA * Development Lifecycle
> >> Practices
> >> Agile & Plan-Driven Development * Managing Projects & Teams * Testing
> >> & QA
> >> Security * Process Improvement & Measurement *
> >> http://www.sqe.com/bsce5sf
> >> _______________________________________________
> >> Wicket-user mailing list
> >> [email protected]
> >> https://lists.sourceforge.net/lists/listinfo/wicket-user
> >>
> >>
> >>
> >
> >
> > -------------------------------------------------------
> > SF.Net email is Sponsored by the Better Software Conference & EXPO
> > September 19-22, 2005 * San Francisco, CA * Development Lifecycle
> > Practices
> > Agile & Plan-Driven Development * Managing Projects & Teams * Testing
> > & QA
> > Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
> > _______________________________________________
> > Wicket-user mailing list
> > [email protected]
> > https://lists.sourceforge.net/lists/listinfo/wicket-user
> >
> 
> 
> -------------------------------------------------------
> SF.Net email is Sponsored by the Better Software Conference & EXPO
> September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
> Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
> Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
> _______________________________________________
> Wicket-user mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/wicket-user
>


-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Wicket-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-user

Reply via email to