Eelco Hillenius wrote:
On Nov 7, 2007 1:32 PM, Igor Vaynberg <[EMAIL PROTECTED]> wrote:
this cannot be an option. it always has to be enabled. if i write a
component that uses this and someone drops it into application where
this is disabled what should happen?
You wouldn't write such a component for general purposes obviously. Of
course it can be optional (it might have to be a whole separate tag
rather than building on wicket:extend); it's up to the users after
that.
Sorry, but I'm with Igor on this one.
What's the point of making you jump through hoops to enable this?
- It'll require thought to not break reusable components, as Igor says.
- It's extra config- and API-width we don't need; we'll have to
deprecate the method to turn it on once it becomes "standard",
mention it in migration docs for 1.5(?), support it on the mailing
list, etc. etc.
- If we add it, it looks like lots of people will use it. We're then
stuck with it - it's a change that would never get backed out unless
someone comes up with a vastly better way of doing all this such that
it's completely obsolete.
Don't give users more knobs to twiddle than you absolutely must. ;-)
FWIW, I've thought of a nice use-case for this:
BasePage.html:
<div id="help">
<wicket:child id="help"/>
</div>
<wicket:child/>
ConcretePage.html:
<wicket:extend id="help">
Here is my help text, complete with a table and other things that
would be a pain to put in a properties file and use i18n for.
</wicket:extend>
<wicket:extend>
Here is the main body of the page.
</wicket:extend>
I guess it'd be nice to be able to do this purely in markup without
having to make a help Fragment, or add an EmptyPanel if there is no help.
This issue/question is raised frequently enough on the mailing list that
I think we should just implement it. I dunno about putting it in for
1.3, though. Probably a 1.4 feature? ;-)
<shrug>
Al
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]