I give up. Looks like this enhancement is really receiving positive votes.
:)
So, let me just clarify my opinion, before giving a suggestion (yes, a
suggestion!):
I was (and I still am a little) against this improvement because of some
reasons:
1) new tag: but if we are going to see a deprecation of old ones, fine by me
2) no declaration in the Java side: I don't like the idea of having markup
containers like <wicket:abstract id="foo" /> not being declared in the
WebPage.
3) existence of other ways to do this: using panels, fragments, whatever.
Now, to change my position from "no way dude, this is no good!" to "well...
if you can't beat them, join them" I'd like to suggest this:
In my second reason, I point to something that is... the _core_ of wicket:
binding Java objects (Components) to HTML tags. So, not having this binding,
we could lose great features. Seeing from this point of view, my suggestion
is to allow these new
call-whatever-you-want-here-from-abstract-to-implement-to-default-to-etc
tags only when they have been declared in Java:
BasePage extends WebPage {
BasePage() {
/*
* Abstract markups could only be set with <div> element
* and their feature is that it can be overridden by specializations,
like sub classes.
*/
addAbstractMarkup("foo"); // internally sets setRenderBodyOnly(true)
ALWAYS!! this won't let enclosing <div> being printed
// this addAbstractMakup method would be a facilitator to
// some AbstractWebMarkupContainer class, controlled by Wicket and
maybe, not even public
}
}
BasePage.html
<html><body>
<div wicket:id="foo">Some default value here maybe?</div>
</body></html>
SubPage extends BasePage {}
SubPage.html
<html><body>
<div wicket:id="foo">Overrides BasePage's "foo"</div> <!-- this enclosing
<div> should also not be printed by Wicket -->
</body></html>
m2c
regards,
On Nov 9, 2007 10:11 PM, Chris Colman <[EMAIL PROTECTED]> wrote:
> > Hi,
> >
> > Actually, Wicket already works like this. It does *NOT* require the
> > <wicket:extend>, and if it's not present it just renders the contents
> of
> > the <wicket:child>. (Just tested this with beta4).
>
> Awesome!
> [This behaviour must have changed since 1.2.6 because I tried removing
> the <extend> tag in a derived page using this version and the whole of
> the derived page got rendered - ie., it did not merge in any markup from
> the base page. If later versions have fixed this already then that's
> massively awesome indeed]
>
> >
> > Furthermore, your patch works exactly the same as far for multilple
> > child sections (as far as I can tell, or otherwise it should for
> > backwards compatibility), and does precisely what both you and Chris
> want.
>
> Awesome!
>
> So it all sounds like a very low risk improvement of the existing
> functionality - cool!
>
> Sorry to all of those who've put up with such a long, sometimes noisy
> thread but I think that's just part of the enthusiastic, collaborative
> process that popular open source projects such as Wicket have become and
> it's what continues to make them great and evolve to become even
> greater.
>
> I present to you just one final tweak at the edges for your comment:
>
> The OO puritan in me would love to see <wicket:child> aliased to
> <wicket:default> so that developers could use either <child> (deprecated
> but still available for backwards compatibility) or <default> - it won't
> break existing pages and lets new people use a more naturally fitting
> and more accurate tag:
>
> Which would flow more naturally and be more easily understood by new
> users reading the documentation?
>
> A) If you don't 'extend' a 'child' section in a derived page wicket uses
> the child section provided in the base page.
>
> (Comment: Extend a child? We're not extending the child section - we're
> replacing it!)
>
> B) If you don't 'extend' a 'default' section in a derived page wicket
> uses the default section provided in the base page.
>
> (Comment: Extend? It is the page you are extended by overriding one or
> more of its default sections. Again you aren't extending a default
> section you are replacing it!)
>
> Or even - now I'm really pushing my luck asking to provide two aliases
> ;)
>
> C) If you don't 'override' a 'default' section in a derived page wicket
> uses the 'default' section provided in the base page.
>
> (Comment - arrhh beautiful - 100% accurate and natural)
>
> At university I remember a lecturer telling a story of an interview with
> one of the creators of Unix. He was asked if he had any regrets over his
> illustrious career and he said "Yes I do, I regret naming the 'create'
> function 'creat' instead of 'create' just to save one byte!". How much
> frustration does a bad name cause?
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
--
Bruno Borges
blog.brunoborges.com.br
+55 1185657739
"The glory of great men should always be
measured by the means they have used to
acquire it."
- Francois de La Rochefoucauld
