Juergen Donnerstag wrote:
But I wonder if stripping "extension: before" and "extension:after"
makes more sense. It would make it more consistent with Panel and
Border as well. I failed to come up with an use case where I actually
need extension:before/after. What do you think?
I think it would be fine to have these two on the same level. Not only will that be easier implement (?) and more straightforward when debugging wicket apps, I also like the fact that you can do things like defining 'abstract' components and replacing parent components like you would override Java.
Eelco
One more question: I was thinking about the component hierachy. I assume it makes sense (avoid the problem of identical component names) to separate the base markup/class and subclass markup/class into two separate components, e.g. ..../<subclass-id>/_child. Assuming your base class markup is inherited as well, you'd end up with hierachies like .../<subclass-id>/_child/_child. Base class components gets added to _child and subclass components to <subclass-id>. Does that make sense?
Juergen
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Wicket-develop mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-develop
------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ Wicket-develop mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/wicket-develop
