Where is all the logic that is now in getMarkup (that caching, resource
watching, reloading)?
Developers can already do anything they want because as far as i can see
the change from class to path name is not in
the MarkupCache or anything
It is in the ResourceStreamLocator.
just override:
public IResourceStream locate(final Class c, final String style, final
Locale locale, final String extension)
and call in that method:
public IResourceStream locate(String path, final String style, final
Locale locale, final String extension)
Maybe if we didn't make DefaultResourceStreamLocator final then people
can extend that oen and just
override the locate by class method.
johan
Jonathan Locke wrote:
i still don't like this idea!! it solves today's problem, but it's
not simple enough or general enough. we ought to take care of this
once and for all.
here's an idea:
what if MarkupCache implemented:
public interface IMarkupStreamLocator
{
public MarkupStream getMarkupStream(MarkupContainer container,
Class parent);
}
(and we get rid of the boolean throw exception overload... clients can
do that manually)
this contract says pretty neatly what markupcache does. it finds a
markup stream for a given markup container (with an optional parent
class for inheritance).
so then we just make MarkupCache subclassable, make getMarkup()
overridable, provide a few convenience methods and create an
IMarkupCacheFactory interface to make the markup cache pluggable.
you should be able to do this with your markup cache:
- replace the entire thing. - replace the part that locates markup
for a given container
- replace just the part that locates a resource stream for a given
container
- replace just the part that turns a container class into a path
this is just a matter of neatly refactoring the implementation details
of MarkupCache into nice overridable protected methods.
i can possibly do this refactor if juergen doesn't want to. it
doesn't look too hard... and we really shouldn't be copping out here
just to get classname->name functionality in sooner. let's do this
simple and right.
Seth Ladd wrote:
So my vote is not to mess with the current loading of markup. Only the
resolving the name!!
Correct!
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