You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@wicket.apache.org by Sebastiaan van Erk <se...@sebster.com> on 2007/11/07 23:08:53 UTC
Attempted summary of multiple thread
Hi,
Since the thread on multiple <wicket:child/> support is insanely long
I'm going to try make a clear and concise summary of what has been
proposed and what the arguments for and against were. Bear with me. :-)
1. What is proposed?
Currently Wicket supports *merging* of markup on a base page with markup
on an a page which extends it through the <wicket:child/> and
<wicket:extend/> tags. When the child page is rendered, the markup of
the base page is used, but the <wicket:child>...</wicket:child> part is
*replaced* by what is between the <wicket:extend>...</wicket:extend>
part in the child page (thus *merging* the two). Currently only 1 child
part is allowed in the base page and only 1 extend part in allowed in
the child page.
The request is to allow multiple such parts to be replaced during the
murge. To know which part must be replaced with which, it is proposed
that the above tags have an id attribute to match them pair by pair.
As Chris Colman aptly put it: the *only* thing being requested is to
remove the limitation of n=1 pairs and to allow n>1 pairs of parts to
replaced during the merge.
NOTE:
This has been called markup inheritance (as suggested by the names child
and extend), but in the thread has also been compared to abstract
methods and implementing them. I recommend not using any analogies to
confuse matters and just seeing it for what it is, a relaxation of the
constraint that n=1 during merge.
NOTE 2:
A patch by Stefan Fussenegger which implements this feature request has
been submitted to the Wicket JIRA. In his patch he used different tags
names, but the behavior for the case n=1 is exactly that of the current
feature.
2. Is <wicket:child/> even necessary?
No, it's a convenience feature. You can get the same effect by making a
BasePage.html, BasePage.java, ChildPage.java, ChildPanel.java and
ChildPanel.html, and using an abstract method or onBeforeRender (see the
thread). If you don't like child/extend, you don't have to use it.
3. Arguments *for* the change.
It is (very) convenient (same reason as for the current child/extend)
and does not change how current Wicket applications work (i.e., it is
100% backward compatible). Only when you *add* an extra identifier
attribute and put in multiple child/extends pairs, are you using the new
feature. If you don't like it, you don't have to use it.
4. Arguments *against* the change.
I saw only a few arguments against the change:
a) It can already be done using
- wicket panels/fragments + abstract methods
- wicket panels/fragments + onBeginRender
Apart from the obvious problems with the above methods (calling an
overridable method from the constructor or extra IMHO non-intuitive
boilerplate code), I do not see how this is an argument against just
*removing an arbitrary restriction* on <wicket:child />.
b) No more extra tags! We already have enough tags in Wicket! In
principle, no extra tags required; there is *no* collision with the
current <wicket:child> and <wicket:extend> tags. But if it is done with
other tags (I would suggest deprecating child/extend in the next version
of wicket then), you don't have to use these extra tags.
c) It creates a mess: all the components contained in any of the extend
parts are added to the child page in the constructor: this can cause
name collisions and a huge number of components to be added, which is bad.
But I do not see the difference between this and any other normal page
where you use components. A bunch of them are added to the page itself,
and another bunch are separated into components. It is up to the
developer to choose how to do this.
A (real world) demonstration of the two different *use cases*, namely
the reason why you would use a panel for one and a wicket/child for
another, can be seen on the following page I recently built:
http://www.denherdervarga.com/programma
On the left there is a menu, in the center the content, on the right
some context information for the page.
The center (the content) is a clear use case of the current child/extend.
The left is a panel, implemented with an abstract method getMenu(String
id) on the base class. The MainMenu panel is reused across pages, and
can change (in the admin section of the site the getMenu() method is
overriden to return a completely different AdminMenu).
The right is currently a <wicket:fragment> with an abstract method on
the base page. *But this a case where I would have preferred another
child/extend.* The fact that the content is on the right is *PURE
LAYOUT*. If I had chosen another layout where it was at the bottom of
the content, it would have been *in* the content part. I would have had
to add all the top level components to the page in the constructor, and
I would have had to make sure that no wicket:id collisions occurred, *IN
EXACTLY THE SAME WAY* as with multiple child/extends. Futhermore, there
is no point in making a panel out of it, because it is specific to this
page, and I'll *never* reuse it. Finally, in this (specific) case there
is not even a wicket component in it, so if there would have been
multiple child/extends, I could have done it with *zero* java code!
5) Conclusion
In conclusion, the proposed change:
- is useful
- does not have to be used if you don't like it
- is 100% backwards compatible
- it introduces no new tags (if using child/extends)
I also do not see any real issues. This is purely about merging markup
when rendering, I think the analogies between this and OO concepts in
Java are clouding the issue!
Regards,
Sebastiaan
RE: Attempted summary of multiple thread
Posted by Chris Colman <ch...@stepaheadsoftware.com>.
> ...
>
> 5) Conclusion
>
> In conclusion, the proposed change:
> - is useful
> - does not have to be used if you don't like it
> - is 100% backwards compatible
> - it introduces no new tags (if using child/extends)
>
> I also do not see any real issues. This is purely about merging markup
> when rendering, I think the analogies between this and OO concepts in
> Java are clouding the issue!
>
> Regards,
> Sebastiaan
Great summary Sebastiaan!
I just thought of a possible, even more powerful, improvement (whoops!)
What if the base page sections (child or abstract tag) were "optionally"
overridden in a derived page. Ie., the section in the derived page
markup is used if supplied otherwise Wicket defaults to using that
provided in the base page.
That's immensely powerful because you could provide some default markup
in the base page and that will be used if the derived page does not
provide an implementation of that section. A derived page now only needs
to provide override sections for sections that it actually needs to
override. It makes 'abstract' not a good choice for a tag name because
abstract implies there is no implementation in the base page.
In this case we could drop the OO language terms and use easy to
understand terms for the tags like <wicket default id="header" />" in a
base page section and <wicket override id="header" /> in a derived page
section.
Even my graphic designers could understand a tag pair called
default/override!
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Attempted summary of multiple thread
Posted by Eelco Hillenius <ee...@gmail.com>.
> I hope people don't start thinking that "this damn newbie" comes and wants
> to change a proven framework without knowing it really. But as owner of the
> patch I am very interested in this discussion and probably even responsible
> for it - or maybe eelco was, when he said "And hey, maybe some working code
> convinces us :-)" (probably) without being prepared to see working code ;)
Nah, that's never a problem. I don't think any of the team cares about
who starts discussions, as long as you stick to technical arguments.
Threads like these are quite time consuming though, and time is
something we all are short on. :-) As long as there is a good JIRA
issue for it, it'll stay in our TODO list to look at. Or... you create
that wicket-stuff project I talked about and you have it whenever
you're ready. Makes it easier for us/ team to look at it later.
Eelco
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Attempted summary of multiple thread
Posted by Stefan Fußenegger <st...@gmx.at>.
hi bruno,
so we do start to convince you ;)
I hope people don't start thinking that "this damn newbie" comes and wants
to change a proven framework without knowing it really. But as owner of the
patch I am very interested in this discussion and probably even responsible
for it - or maybe eelco was, when he said "And hey, maybe some working code
convinces us :-)" (probably) without being prepared to see working code ;)
I don't think that whatever kind of declaration on the java side would help
to make things clearer. merging markup based on child/extend currently is
really trivial. therefore, the outcome is easy to predict for
developers/designers. this could also be beneficial for IDE support:
previewing the outcome would be an easy-to-implement feature for Wicket
Bench (including warnings for duplicate ids in the resulting markup).
-- stefan
Bruno Borges wrote:
>
> 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 <ch...@stepaheadsoftware.com>
> 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: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
>
> --
> 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
>
>
-----
-------
Stefan Fußenegger
http://talk-on-tech.blogspot.com // looking for a nicer domain ;)
--
View this message in context: http://www.nabble.com/Attempted-summary-of-multiple-%3Cwicket%3Achild--%3E-thread-tf4767718.html#a13690139
Sent from the Wicket - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
RE: Attempted summary of multiple thread
Posted by Chris Colman <ch...@stepaheadsoftware.com>.
> I give up. Looks like this enhancement is really receiving positive
votes.
> :)
:) :) :) :) :) :) :) :)
Just some of the many happy faces!
> 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:
It's great that you're now at the level of suggesting improvements! And
I'm already hating myself for my following comments but in the interest
of keeping this enhancement simple:
My first thoughts about your suggestion are: I wonder if components
associated with default/overridden markup should be treated any
differently. I have always found Wicket's error detection on missing
tags or unbound components to be excellent. It would still continue to
work in the exact same way without needing to define, as you suggest, at
the Java level, special components that will bind to abstract
(default/override) markup sections.
I think the elegance of the new feature is that is purely an enablement
(I think I just invented a new word!) of multiplicity on an existing
feature and some new tags to more accurately define the feature
(previous tags are aliased to the new ones for backwards compatibility).
If we start having to define "overridden" or abstract components at the
Java level then it turns into a whole 'nuther beast and I worry that we
lose some of the genericity of component definition that we have now in
wicket.
On first glance I believe that your suggestion may create problems for
backwards compatibility with existing pages using the current
<child><extend> feature. It would mean people would have to add
addAbstractMarkup to their existing pages to allow them to work in the
new system which would be a bad thing I think.
Ok, I can stop hating myself now ;)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Attempted summary of multiple thread
Posted by Bruno Borges <br...@gmail.com>.
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 <ch...@stepaheadsoftware.com> 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: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
--
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
RE: Attempted summary of multiple thread
Posted by Chris Colman <ch...@stepaheadsoftware.com>.
> 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: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Attempted summary of multiple thread
Posted by Stefan Fußenegger <st...@gmx.at>.
Of course, it really is optional. Wicket only checks whether a page has a
<wicket:extend> tag or not to decide if markup merging is needed.
(Therefore, my patch does not have any impact on that, as there is no markup
merging triggered)
Thanks for pointing this out!
-- stefan
Sebastiaan van Erk 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).
>
> 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.
>
> Regards,
> Sebastiaan
>
> Stefan Fußenegger wrote:
>> I think it would be a nice feature to define defaults and overrides this
>> way.
>> However, this wouldn't be backwards compatible anymore as the contents
>> are
>> currently ignored. (Ok, you are currently forced to extend them, so you
>> probably wouldn't see the markup from such sections in *old*
>> applications.)
>>
>> My vote on this:
>> - I would love to have multiple sections.
>> - I would appreciate default markup for extendible sections.
>>
>> Kind regards,
>>
>> -- stefan
>>
>> PS: I'm keeping my fingers crossed for RC1! Go, Wicket, go! :)
>>
>>
>>
>> Chris Colman wrote:
>>>> That is what I'd suggest as well, since it involves the least amount
>>> of
>>>> change. As an added bonus, if no id's are added and 2 <wicket:child>
>>>> sections are used, it could throw an exception (which it currently
>>> does
>>>> not do, it just silently ignores the second <wicket:child>).
>>> That would be magic!
>>>
>>> While we're at this epic moment after spending days thrashing this out
>>> could we spend just 3 extra minutes to investigate implementing standard
>>> Java method like behavior for this feature?
>>> Ie., In the case that no override <extend> is provided in a derived
>>> page, simply use the markup in the <child> tag in the base page.
>>>
>>> Then it would work like methods work in Java - and it's probably how
>>> most Java developers would naturally expect an OO framework like wicket
>>> to work anyway.
>>>
>>> Intuitively it seems like an easy to implement option in the framework:
>>> the <child>/<extend> feature is already merging code from the base page
>>> anyway - if there is no override <extend> tag in a derived page then it
>>> simply pulls the markup from the base page's <child> tag.
>>>
>>>> Regards,
>>>> Sebastiaan
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>
>>>
>>>
>>
>>
>> -----
>> -------
>> Stefan Fußenegger
>> http://talk-on-tech.blogspot.com // looking for a nicer domain ;)
>
>
>
-----
-------
Stefan Fußenegger
http://talk-on-tech.blogspot.com // looking for a nicer domain ;)
--
View this message in context: http://www.nabble.com/Attempted-summary-of-multiple-%3Cwicket%3Achild--%3E-thread-tf4767718.html#a13666078
Sent from the Wicket - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Attempted summary of multiple thread
Posted by Sebastiaan van Erk <se...@sebster.com>.
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).
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.
Regards,
Sebastiaan
Stefan Fußenegger wrote:
> I think it would be a nice feature to define defaults and overrides this way.
> However, this wouldn't be backwards compatible anymore as the contents are
> currently ignored. (Ok, you are currently forced to extend them, so you
> probably wouldn't see the markup from such sections in *old* applications.)
>
> My vote on this:
> - I would love to have multiple sections.
> - I would appreciate default markup for extendible sections.
>
> Kind regards,
>
> -- stefan
>
> PS: I'm keeping my fingers crossed for RC1! Go, Wicket, go! :)
>
>
>
> Chris Colman wrote:
>>> That is what I'd suggest as well, since it involves the least amount
>> of
>>> change. As an added bonus, if no id's are added and 2 <wicket:child>
>>> sections are used, it could throw an exception (which it currently
>> does
>>> not do, it just silently ignores the second <wicket:child>).
>> That would be magic!
>>
>> While we're at this epic moment after spending days thrashing this out
>> could we spend just 3 extra minutes to investigate implementing standard
>> Java method like behavior for this feature?
>> Ie., In the case that no override <extend> is provided in a derived
>> page, simply use the markup in the <child> tag in the base page.
>>
>> Then it would work like methods work in Java - and it's probably how
>> most Java developers would naturally expect an OO framework like wicket
>> to work anyway.
>>
>> Intuitively it seems like an easy to implement option in the framework:
>> the <child>/<extend> feature is already merging code from the base page
>> anyway - if there is no override <extend> tag in a derived page then it
>> simply pulls the markup from the base page's <child> tag.
>>
>>> Regards,
>>> Sebastiaan
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>>
>
>
> -----
> -------
> Stefan Fußenegger
> http://talk-on-tech.blogspot.com // looking for a nicer domain ;)
RE: Attempted summary of multiple thread
Posted by Stefan Fußenegger <st...@gmx.at>.
I think it would be a nice feature to define defaults and overrides this way.
However, this wouldn't be backwards compatible anymore as the contents are
currently ignored. (Ok, you are currently forced to extend them, so you
probably wouldn't see the markup from such sections in *old* applications.)
My vote on this:
- I would love to have multiple sections.
- I would appreciate default markup for extendible sections.
Kind regards,
-- stefan
PS: I'm keeping my fingers crossed for RC1! Go, Wicket, go! :)
Chris Colman wrote:
>
>> That is what I'd suggest as well, since it involves the least amount
> of
>> change. As an added bonus, if no id's are added and 2 <wicket:child>
>> sections are used, it could throw an exception (which it currently
> does
>> not do, it just silently ignores the second <wicket:child>).
>
> That would be magic!
>
> While we're at this epic moment after spending days thrashing this out
> could we spend just 3 extra minutes to investigate implementing standard
> Java method like behavior for this feature?
> Ie., In the case that no override <extend> is provided in a derived
> page, simply use the markup in the <child> tag in the base page.
>
> Then it would work like methods work in Java - and it's probably how
> most Java developers would naturally expect an OO framework like wicket
> to work anyway.
>
> Intuitively it seems like an easy to implement option in the framework:
> the <child>/<extend> feature is already merging code from the base page
> anyway - if there is no override <extend> tag in a derived page then it
> simply pulls the markup from the base page's <child> tag.
>
>>
>> Regards,
>> Sebastiaan
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
>
-----
-------
Stefan Fußenegger
http://talk-on-tech.blogspot.com // looking for a nicer domain ;)
--
View this message in context: http://www.nabble.com/Attempted-summary-of-multiple-%3Cwicket%3Achild--%3E-thread-tf4767718.html#a13662915
Sent from the Wicket - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
RE: Attempted summary of multiple thread
Posted by Chris Colman <ch...@stepaheadsoftware.com>.
> That is what I'd suggest as well, since it involves the least amount
of
> change. As an added bonus, if no id's are added and 2 <wicket:child>
> sections are used, it could throw an exception (which it currently
does
> not do, it just silently ignores the second <wicket:child>).
That would be magic!
While we're at this epic moment after spending days thrashing this out
could we spend just 3 extra minutes to investigate implementing standard
Java method like behavior for this feature?
Ie., In the case that no override <extend> is provided in a derived
page, simply use the markup in the <child> tag in the base page.
Then it would work like methods work in Java - and it's probably how
most Java developers would naturally expect an OO framework like wicket
to work anyway.
Intuitively it seems like an easy to implement option in the framework:
the <child>/<extend> feature is already merging code from the base page
anyway - if there is no override <extend> tag in a derived page then it
simply pulls the markup from the base page's <child> tag.
>
> Regards,
> Sebastiaan
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Attempted summary of multiple thread
Posted by Sebastiaan van Erk <se...@sebster.com>.
Jan Kriesten wrote:
> hi everyone,
>
> actually, i wonder what is wrong with al's suggestion to add id's to
> <wicket:child> and <wicket:extend>?
>
> regards, --- jan.
That is what I'd suggest as well, since it involves the least amount of
change. As an added bonus, if no id's are added and 2 <wicket:child>
sections are used, it could throw an exception (which it currently does
not do, it just silently ignores the second <wicket:child>).
Regards,
Sebastiaan
Re: Attempted summary of multiple thread
Posted by Johan Compagner <jc...@gmail.com>.
Yes that is the solution that also gets my vote for 1.4 if we can implement
it
nicely and if it is backwards compartible and straightforward to use.
johan
On Nov 8, 2007 10:37 AM, Jan Kriesten <ja...@renitence.de> wrote:
>
> hi everyone,
>
> actually, i wonder what is wrong with al's suggestion to add id's to
> <wicket:child> and <wicket:extend>?
>
> regards, --- jan.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
Re: Attempted summary of multiple thread
Posted by Jan Kriesten <ja...@renitence.de>.
hi everyone,
actually, i wonder what is wrong with al's suggestion to add id's to
<wicket:child> and <wicket:extend>?
regards, --- jan.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
RE: Attempted summary of multiple thread
Posted by Chris Colman <ch...@stepaheadsoftware.com>.
> > The advantage of having this separate project
> > is that such inheritance would be available for people who like it,
> > and hey, maybe in the longer term you have something that works so
> > good that you can convince people based on something that works.
> > Executable code works much better than simply words when it comes to
> > that ;-)
Having it as a separate project is better than no project at all. I'd be
glad to use that if a separate project is the only option on offer.
As it's a separate project we'll need different tag names. I'm not sure
if you caught my 11th hour submission on your "final summary" post:
Suggested minor modification to the design:
Call tags "default" and "override" instead of "abstract" and
"implements" - it's less *techie* plus it allows us to define a default
markup section in a base page that can be "optionally" overridden in any
derived pages. That's even more OO and allows even greater simplicity
through reusability.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Attempted summary of multiple thread
Posted by Stefan Fußenegger <st...@gmx.at>.
Hi eelco.
Did you see what I changed in order to make this working? There is nearly no
extra complexity. So I think complexity isn't an argument here.
best regards
-- stefan
Eelco Hillenius wrote:
>
>> In conclusion, the proposed change:
>> - is useful
>> - does not have to be used if you don't like it
>> - is 100% backwards compatible
>> - it introduces no new tags (if using child/extends)
>
> The thing is though, even though it is 100% backwards compatible, it
> is something we'll have to support. It adds complexity to the
> implementation, and we'll have to answer questions about it on the
> list. That would be fine if everyone would have been wildly
> enthusiastic about it, but that is not the case - whether you think
> that is justified or not.
>
> So, like I propose in the main thread, the best way to go is to
> implement this as a separate project, using separate tags. We'll be
> happy to support any internal API changes if that is needed to make
> the implementation work. The advantage of having this separate project
> is that such inheritance would be available for people who like it,
> and hey, maybe in the longer term you have something that works so
> good that you can convince people based on something that works.
> Executable code works much better than simply words when it comes to
> that ;-)
>
> Do people want to work on this?
>
> Regards,
>
> Eelco
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
>
-----
-------
Stefan Fußenegger
http://talk-on-tech.blogspot.com // looking for a nicer domain ;)
--
View this message in context: http://www.nabble.com/Attempted-summary-of-multiple-%3Cwicket%3Achild--%3E-thread-tf4767718.html#a13643264
Sent from the Wicket - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Attempted summary of multiple thread
Posted by Sebastiaan van Erk <se...@sebster.com>.
Eelco wrote:
> The thing is though, even though it is 100% backwards compatible, it
> is something we'll have to support. It adds complexity to the
> implementation, and we'll have to answer questions about it on the
> list. That would be fine if everyone would have been wildly
> enthusiastic about it, but that is not the case - whether you think
> that is justified or not.
>
> So, like I propose in the main thread, the best way to go is to
> implement this as a separate project, using separate tags. We'll be
> happy to support any internal API changes if that is needed to make
> the implementation work. The advantage of having this separate project
> is that such inheritance would be available for people who like it,
> and hey, maybe in the longer term you have something that works so
> good that you can convince people based on something that works.
> Executable code works much better than simply words when it comes to
> that ;-)
Some small questions on doing this as a separate project:
1) If API changes are necessary, is it not adding more complexity that
needs to be supported than the change itself? The change is relatively
minor change (heck, even mark it experimental/use at own risk/may be
removed in a future release). Can the same be said for other API changes
yet to be thought of...
2) If other tags are going to have to be used, are tags in the wicket
namespace allowed? Would that not be a potential source of future naming
conflicts? What is the policy here?
Regards,
Sebastiaan
Re: Attempted summary of multiple thread
Posted by Sebastiaan van Erk <se...@sebster.com>.
Hi,
Eelco Hillenius wrote:
>> In conclusion, the proposed change:
>> - is useful
>> - does not have to be used if you don't like it
>> - is 100% backwards compatible
>> - it introduces no new tags (if using child/extends)
>
> The thing is though, even though it is 100% backwards compatible, it
> is something we'll have to support. It adds complexity to the
> implementation, and we'll have to answer questions about it on the
> list. That would be fine if everyone would have been wildly
> enthusiastic about it, but that is not the case - whether you think
> that is justified or not.
The fact that you guys would have to support it and answer questions is
fair enough.
> So, like I propose in the main thread, the best way to go is to
> implement this as a separate project, using separate tags. We'll be
> happy to support any internal API changes if that is needed to make
> the implementation work. The advantage of having this separate project
> is that such inheritance would be available for people who like it,
> and hey, maybe in the longer term you have something that works so
> good that you can convince people based on something that works.
> Executable code works much better than simply words when it comes to
> that ;-)
>
> Do people want to work on this?
Sure, I would like to work on this. It would eliminate my need for
<wicket:fragment> and would allow me to do everything I need
consistently with 1 tag pair, as well as eliminate some java code.
Regards,
Sebastiaan
> Regards,
>
> Eelco
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
Re: Attempted summary of multiple thread
Posted by Eelco Hillenius <ee...@gmail.com>.
> In conclusion, the proposed change:
> - is useful
> - does not have to be used if you don't like it
> - is 100% backwards compatible
> - it introduces no new tags (if using child/extends)
The thing is though, even though it is 100% backwards compatible, it
is something we'll have to support. It adds complexity to the
implementation, and we'll have to answer questions about it on the
list. That would be fine if everyone would have been wildly
enthusiastic about it, but that is not the case - whether you think
that is justified or not.
So, like I propose in the main thread, the best way to go is to
implement this as a separate project, using separate tags. We'll be
happy to support any internal API changes if that is needed to make
the implementation work. The advantage of having this separate project
is that such inheritance would be available for people who like it,
and hey, maybe in the longer term you have something that works so
good that you can convince people based on something that works.
Executable code works much better than simply words when it comes to
that ;-)
Do people want to work on this?
Regards,
Eelco
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org