Dynamically.. that is something we (jan and i) already do ....

But  don't know exactly what the outcome is for this thread.
But i like the simple way of given users the option to do the conversion of the name of the markup.

I also see that you are suddenly returning a String as markup
But until now we need a URL!!
And that is not because it is handy or something but we can test for modification..

So my vote is not to mess with the current loading of markup. Only the resolving the name!!

johan

Jonathan Locke wrote:

or you could dynamically manufacture it... yikes!

Jonathan Locke wrote:


one neat and elegant outcome of IMarkupLocator is that a database or
other storage medium could be neatly used to retrieve wicket markup!

Jonathan Locke wrote:


what you're really doing in my scenario is subclassing an AbstractResourceStreamMarkupLocator it does all the work and has a protected method for turning the MarkupContainer into some kind of
resource path.

Seth Ladd wrote:

On 8/13/05, Jonathan Locke <[EMAIL PROTECTED]> wrote:
if you don't want fqcn (and btw, i dislike that abbrev. even though i
know what you mean),



Again, don't care what you call it, was just a stand in. :)

just implement your own IMarkupLocator:

new IMarkupLocator()
{
   String getMarkup(MarkupContainer container)
   {
      String name = Classes.getName(container.getClass());
         <do resource location magic with non-fqcn string>
      return markup;
   }
}



The problem I have with this is that it's mixing two things.  I'm sure
I'm beating a dead horse by now, but this single class should delegate
the:

String name = Classes.getName(container.getClass());

line to a IMarkupNameResolver (name pending approval :)

That way, if I want to change the strategy for deducing the raw name
of the HTML page, I don't have to create a full IMarkupLocator class,
because I don't care how the actual resource location works (since
that works fine and is very flexible).

How about:

new IMarkupLocator()
{
    String getMarkup(MarkupContainer container)
    {
       String name = markupNameResolver.resolve(container);
          <do resource location magic with non-fqcn string>
       return markup;
    }
}

Because once I turn com/example/Page.class into Page.html, I should
hand that off to the standard Wicket ResourceStreamLocator classes. There's no special "resource location magic" required really.

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



-------------------------------------------------------
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