You are viewing a plain text version of this content. The canonical link for it is here.

Posted to users@wicket.apache.org by Stefan Fußenegger <st...@gmx.at> on 2007/11/02 17:58:06 UTC

Multiple tags on a single base page?

Hi folks,

I just stumbled on a situation where it would be useful to have two or more
<wicket:child /> tags in a base page. Just consider a layout that consists
of the usual footer, header, navigation, and content parts. But now, the
content should be arranged in two columns, e.g. two different <div />s.

To give a short example, the BasePage.html cloud look like this

--------
<body>

<!-- some layout markup -->

<div class="content_left">
<wicket:child />
</div>

<!-- more layout markup -->

<div class="content_rigt">
<wicket:child />
</div>

<!-- even more layout markup -->
</body>
--------

And the Child.html markup would look like this:

--------
<body>

<div class="content_left">
<wicket:extend>			    
<!-- content of left column (first child) goes here -->
</wicket:extend>
</div>

<div class="content_rigt">
<wicket:extend>			    
<!-- content of right column (second child) goes here -->
</wicket:extend>
</div>
</body>
--------

Wouldn't that be a desirable feature? I tried to run the above example
expecting to get an exception. The second wicket:child/wicket:extend pair
was happily ignored though.

Best regards, Stefan
-- 
View this message in context: http://www.nabble.com/Multiple-%3Cwicket%3Achild--%3E-tags-on-a-single-base-page--tf4738673.html#a13551448
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: Multiple tags on a single base page?

Posted by Stefan Fußenegger <st...@gmx.at>.

Well, the tags are not new, as they do the perfectly same as extend and
child. Basically, the patch only introduces an id attribute to those tags in
order to make linking of markup more flexible. The new names were only
introduced to keep functionality of the patch separated from the existing
(and as the names child/extend are not very well chosen, as they aren't
naturally related)

I see that it was a bad idea to rename the tags for the prototype.
Obviously, everybody fears new tags and therefore dismisses the whole idea
only for that reason.



Evan Chooly wrote:
> 
> In our app we have a ListView into which we can dump panels for, in
> our case, various different filtering options depending on the page.
> The base page keeps a List and that's used as the model for the
> ListView.  If the subclass doesn't add anything, nothing shows up.
> But the pages that need them can add them.  These panels show up in
> the base page's markup area (outside the <wicket:child/> area) with no
> hackery needed.
> 
> I think the proposed patch is an overly complicated solution to
> "problem" that has many different simple solutions.  I agree with the
> earlier comments about the proliferation of tags in wicket.  I'd
> rather not see new tags added just for this.  It fuglifies the markup
> for no real gain.
> 
> On Nov 6, 2007 11:30 AM, Stefan Fußenegger <st...@gmx.at>
> wrote:
>>
>> I posted a new message in Wicket - Dev:
>> http://www.nabble.com/Patch%3A-Multiple-%3Cwicket%3Achild--%3E-tags-on-a-single-base-page--tf4759260.html
>>
>> It contains a patch that demonstrates the discussed enhancement. Please
>> comment!
>>
>> -- stefan
>>
>>
>> Stefan Fußenegger wrote:
>> >
>> > Hi folks,
>> >
>> > I just stumbled on a situation where it would be useful to have two or
>> > more <wicket:child /> tags in a base page. Just consider a layout that
>> > consists of the usual footer, header, navigation, and content parts.
>> But
>> > now, the content should be arranged in two columns, e.g. two different
>> > <div />s.
>> >
>> > To give a short example, the BasePage.html cloud look like this
>> >
>> > --------
>> > <body>
>> >
>> > <!-- some layout markup -->
>> >
>> > <div class="content_left">
>> > <wicket:child />
>> > </div>
>> >
>> > <!-- more layout markup -->
>> >
>> > <div class="content_rigt">
>> > <wicket:child />
>> > </div>
>> >
>> > <!-- even more layout markup -->
>> > </body>
>> > --------
>> >
>> > And the Child.html markup would look like this:
>> >
>> > --------
>> > <body>
>> >
>> > <div class="content_left">
>> > <wicket:extend>
>> > <!-- content of left column (first child) goes here -->
>> > </wicket:extend>
>> > </div>
>> >
>> > <div class="content_rigt">
>> > <wicket:extend>
>> > <!-- content of right column (second child) goes here -->
>> > </wicket:extend>
>> > </div>
>> > </body>
>> > --------
>> >
>> > Wouldn't that be a desirable feature? I tried to run the above example
>> > expecting to get an exception. The second wicket:child/wicket:extend
>> pair
>> > was happily ignored though.
>> >
>> > Best regards, Stefan
>> >
>>
>>
>> -----
>> -------
>> Stefan Fußenegger
>> http://talk-on-tech.blogspot.com // looking for a nicer domain ;)
>> --
>> View this message in context:
>> http://www.nabble.com/Multiple-%3Cwicket%3Achild--%3E-tags-on-a-single-base-page--tf4738673.html#a13610287
>>
>> 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
>>
>>
> 
> ---------------------------------------------------------------------
> 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/Multiple-%3Cwicket%3Achild--%3E-tags-on-a-single-base-page--tf4738673.html#a13623106
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: Multiple tags on a single base page?

Posted by Evan Chooly <ev...@gmail.com>.

In our app we have a ListView into which we can dump panels for, in
our case, various different filtering options depending on the page.
The base page keeps a List and that's used as the model for the
ListView.  If the subclass doesn't add anything, nothing shows up.
But the pages that need them can add them.  These panels show up in
the base page's markup area (outside the <wicket:child/> area) with no
hackery needed.

I think the proposed patch is an overly complicated solution to
"problem" that has many different simple solutions.  I agree with the
earlier comments about the proliferation of tags in wicket.  I'd
rather not see new tags added just for this.  It fuglifies the markup
for no real gain.

On Nov 6, 2007 11:30 AM, Stefan Fußenegger <st...@gmx.at> wrote:
>
> I posted a new message in Wicket - Dev:
> http://www.nabble.com/Patch%3A-Multiple-%3Cwicket%3Achild--%3E-tags-on-a-single-base-page--tf4759260.html
>
> It contains a patch that demonstrates the discussed enhancement. Please
> comment!
>
> -- stefan
>
>
> Stefan Fußenegger wrote:
> >
> > Hi folks,
> >
> > I just stumbled on a situation where it would be useful to have two or
> > more <wicket:child /> tags in a base page. Just consider a layout that
> > consists of the usual footer, header, navigation, and content parts. But
> > now, the content should be arranged in two columns, e.g. two different
> > <div />s.
> >
> > To give a short example, the BasePage.html cloud look like this
> >
> > --------
> > <body>
> >
> > <!-- some layout markup -->
> >
> > <div class="content_left">
> > <wicket:child />
> > </div>
> >
> > <!-- more layout markup -->
> >
> > <div class="content_rigt">
> > <wicket:child />
> > </div>
> >
> > <!-- even more layout markup -->
> > </body>
> > --------
> >
> > And the Child.html markup would look like this:
> >
> > --------
> > <body>
> >
> > <div class="content_left">
> > <wicket:extend>
> > <!-- content of left column (first child) goes here -->
> > </wicket:extend>
> > </div>
> >
> > <div class="content_rigt">
> > <wicket:extend>
> > <!-- content of right column (second child) goes here -->
> > </wicket:extend>
> > </div>
> > </body>
> > --------
> >
> > Wouldn't that be a desirable feature? I tried to run the above example
> > expecting to get an exception. The second wicket:child/wicket:extend pair
> > was happily ignored though.
> >
> > Best regards, Stefan
> >
>
>
> -----
> -------
> Stefan Fußenegger
> http://talk-on-tech.blogspot.com // looking for a nicer domain ;)
> --
> View this message in context: http://www.nabble.com/Multiple-%3Cwicket%3Achild--%3E-tags-on-a-single-base-page--tf4738673.html#a13610287
>
> 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
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org

Re: Multiple tags on a single base page?

Posted by Stefan Fußenegger <st...@gmx.at>.

I posted a new message in Wicket - Dev:
http://www.nabble.com/Patch%3A-Multiple-%3Cwicket%3Achild--%3E-tags-on-a-single-base-page--tf4759260.html

It contains a patch that demonstrates the discussed enhancement. Please
comment!

-- stefan


Stefan Fußenegger wrote:
> 
> Hi folks,
> 
> I just stumbled on a situation where it would be useful to have two or
> more <wicket:child /> tags in a base page. Just consider a layout that
> consists of the usual footer, header, navigation, and content parts. But
> now, the content should be arranged in two columns, e.g. two different
> <div />s.
> 
> To give a short example, the BasePage.html cloud look like this
> 
> --------
> <body>
> 
> <!-- some layout markup -->
> 
> <div class="content_left">
> <wicket:child />
> </div>
> 
> <!-- more layout markup -->
> 
> <div class="content_rigt">
> <wicket:child />
> </div>
> 
> <!-- even more layout markup -->
> </body>
> --------
> 
> And the Child.html markup would look like this:
> 
> --------
> <body>
> 
> <div class="content_left">
> <wicket:extend>			    
> <!-- content of left column (first child) goes here -->
> </wicket:extend>
> </div>
> 
> <div class="content_rigt">
> <wicket:extend>			    
> <!-- content of right column (second child) goes here -->
> </wicket:extend>
> </div>
> </body>
> --------
> 
> Wouldn't that be a desirable feature? I tried to run the above example
> expecting to get an exception. The second wicket:child/wicket:extend pair
> was happily ignored though.
> 
> Best regards, Stefan
> 


-----
-------
Stefan Fußenegger
http://talk-on-tech.blogspot.com // looking for a nicer domain ;)
-- 
View this message in context: http://www.nabble.com/Multiple-%3Cwicket%3Achild--%3E-tags-on-a-single-base-page--tf4738673.html#a13610287
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: Multiple tags on a single base page?

Posted by Johan Compagner <jc...@gmail.com>.

yes i agree,
i dont think we will change the extend->child 1 on 1 relationship. (thats
just design by inheritance)
what some others want is just do it by composition and that is perfectly
possible by using panels.
And you can mix the 2 just fine.


So

Base.java/Base.html -> extend -> Sub.java/Sub.html
Base.java/Base.html -> composition -> Sub.java with Panel1.java/Panel1.html
and Panel2.java/Panel2.html
 Base.java/Base.html -> extend and composition -> Sub.java/Sub.html with
Panel1.java/Panel1.html and Panel2.java/Panel2.html

So i am curious what people really think is missing.
Don't they want the Panel1.java/Panel1.html form composition? But wicket
also have something for that thats called Fragments so:

 Base.java/Base.html -> composition -> Sub.java with Fragment1 and Fragment2

johan








On 11/5/07, Bruno Borges <br...@gmail.com> wrote:
>
> How would be the Java classes, if multiple wicket:child were supported?!
> wicket:extend and wicket:child were build under the base concept of OOP's
> inheritance.
>
> looks weird to me. :D
>
> On Nov 4, 2007 9:29 PM, Johan Compagner <jc...@gmail.com> wrote:
>
> > >
> > > The only requirement would be that if you do choose to support
> multiple
> > > abstract/overridden sections you would need to provide identifiers
> (just
> > > like an abstract method has a name) so that the 'compiler' (wicket)
> > > knows which section in a superclass an extended class section is
> > > overriding. In pages where only one section is overridden no
> identifiers
> > > would be necessary and so existing markup works without change, the
> way
> > > it does now.
> >
> >
> > isn't this section exactly what igor said in his post?
> >
> > make 1 page
> > that has 2 identifiers (that are 2 divs like
> > <div wicket:id="method1"></div>
> > <div wicket:id="method2"></div>
> >
> > and the class had
> > abstract class MyBasePage
> > {
> >      MyBasePage()
> >      {
> >           add(method1());
> >           add(method2());
> >      }
> >      abstract Panel method1()
> >      abstract Panel method2()
> > }
> >
> > as far as i know you have pretty much exactly what you describe.
> >
> > johan
> >
>
>
>
> --
> 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: Multiple tags on a single base page?

Posted by Bruno Borges <br...@gmail.com>.

How would be the Java classes, if multiple wicket:child were supported?!
wicket:extend and wicket:child were build under the base concept of OOP's
inheritance.

looks weird to me. :D

On Nov 4, 2007 9:29 PM, Johan Compagner <jc...@gmail.com> wrote:

> >
> > The only requirement would be that if you do choose to support multiple
> > abstract/overridden sections you would need to provide identifiers (just
> > like an abstract method has a name) so that the 'compiler' (wicket)
> > knows which section in a superclass an extended class section is
> > overriding. In pages where only one section is overridden no identifiers
> > would be necessary and so existing markup works without change, the way
> > it does now.
>
>
> isn't this section exactly what igor said in his post?
>
> make 1 page
> that has 2 identifiers (that are 2 divs like
> <div wicket:id="method1"></div>
> <div wicket:id="method2"></div>
>
> and the class had
> abstract class MyBasePage
> {
>      MyBasePage()
>      {
>           add(method1());
>           add(method2());
>      }
>      abstract Panel method1()
>      abstract Panel method2()
> }
>
> as far as i know you have pretty much exactly what you describe.
>
> johan
>



-- 
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: Multiple tags on a single base page?

Posted by Johan Compagner <jc...@gmail.com>.

>
> The only requirement would be that if you do choose to support multiple
> abstract/overridden sections you would need to provide identifiers (just
> like an abstract method has a name) so that the 'compiler' (wicket)
> knows which section in a superclass an extended class section is
> overriding. In pages where only one section is overridden no identifiers
> would be necessary and so existing markup works without change, the way
> it does now.


isn't this section exactly what igor said in his post?

make 1 page
that has 2 identifiers (that are 2 divs like
<div wicket:id="method1"></div>
<div wicket:id="method2"></div>

and the class had
abstract class MyBasePage
{
      MyBasePage()
      {
           add(method1());
           add(method2());
      }
      abstract Panel method1()
      abstract Panel method2()
}

as far as i know you have pretty much exactly what you describe.

johan

RE: Multiple tags on a single base page?

Posted by Chris Colman <ch...@stepaheadsoftware.com>.

> > There's nothing I would love more right now than to have to time to
> > implement a patch to support multiple overridden sections in a
wicket
> > page but unfortunately time is one thing I don't seem to have much
of
> > these days. I can't believe 2007 is almost over - heck, where did
this
> > year go?
> 
> Tell us about it :-)
> 
> Eelco

Well if time is flying by so fast that means we all must be having
waaaaaay too much fun - which is probably a good thing!

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org

Re: Multiple tags on a single base page?

Posted by Eelco Hillenius <ee...@gmail.com>.

> There's nothing I would love more right now than to have to time to
> implement a patch to support multiple overridden sections in a wicket
> page but unfortunately time is one thing I don't seem to have much of
> these days. I can't believe 2007 is almost over - heck, where did this
> year go?

Tell us about it :-)

Eelco

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org

RE: Multiple tags on a single base page?

Posted by Chris Colman <ch...@stepaheadsoftware.com>.

> > It would be quite feasible to add support for multiple overridden
> > sections using the above tag names while remaining backwards
compatible
> > with existing markup by continuing to support the old
<child/extends>
> > tags working the way they always have.
> 
> It's kind of a predictable answer, but the best way to push new ideas
> forward is to supply us with a patch, so that we can discuss some
> working code. The current committers don't see much in the idea, but
> that doesn't mean they wouldn't want to support at least the option of
> plugging this in. And hey, maybe some working code convinces us :-)
> 
> Eelco

There's nothing I would love more right now than to have to time to
implement a patch to support multiple overridden sections in a wicket
page but unfortunately time is one thing I don't seem to have much of
these days. I can't believe 2007 is almost over - heck, where did this
year go?

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org

Re: Multiple tags on a single base page?

Posted by Igor Vaynberg <ig...@gmail.com>.

this is done in MarkupCache i believe. when you load a markup file
that has wicket:extend it traverses up the hierarchy and merges all
the markup.

-igor


On 11/5/07, Stefan Fußenegger <st...@gmx.at> wrote:
>
>
> Eelco Hillenius wrote:
> >
> >> It would be quite feasible to add support for multiple overridden
> >> sections using the above tag names while remaining backwards compatible
> >> with existing markup by continuing to support the old <child/extends>
> >> tags working the way they always have.
> >
> > It's kind of a predictable answer, but the best way to push new ideas
> > forward is to supply us with a patch, so that we can discuss some
> > working code. The current committers don't see much in the idea, but
> > that doesn't mean they wouldn't want to support at least the option of
> > plugging this in. And hey, maybe some working code convinces us :-)
> >
> > Eelco
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > For additional commands, e-mail: users-help@wicket.apache.org
> >
> >
> >
>
> Hi eelco,
>
> I'd love to do a proof of concept here. Admittedly, I don't know wicket's
> inner workings very well. But if I get some support, I'd try implementing
> this. I am currently looking through the code, but can't find where the
> transition between parent and child takes place (in other words: the line of
> code that recognizes the wicket:extend tag and takes the appropriate
> action). If somebody could point me to that line I would try to implement
> this possible new feature ... well, I'll first estimate the time necessary
> to do so and see if I can afford it ;)
>
> Regards
>
>
>
> -----
> -------
> Stefan Fußenegger
> http://talk-on-tech.blogspot.com // looking for a nicer domain ;)
> --
> View this message in context: http://www.nabble.com/Multiple-%3Cwicket%3Achild--%3E-tags-on-a-single-base-page--tf4738673.html#a13586814
> 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
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org

Re: Multiple tags on a single base page?

Posted by Stefan Fußenegger <st...@gmx.at>.

Yes!

see: https://issues.apache.org/jira/browse/WICKET-1134

-- stefan 


Scott Swank wrote:
> 
> I can see how <wicket:abstract> and <wicket:implements> tags could be
> a nice enhancement to the current <wicket:extend> and <wicket:child>
> tags.  Do you have a working, or mostly working, patch?
> 
> ---------------------------------------------------------------------
> 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/Multiple-%3Cwicket%3Achild--%3E-tags-on-a-single-base-page--tf4738673.html#a13634545
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: Multiple tags on a single base page?

Posted by Eelco Hillenius <ee...@gmail.com>.

On Nov 7, 2007 2:02 PM, Igor Vaynberg <ig...@gmail.com> wrote:
> On Nov 7, 2007 1:39 PM, Eelco Hillenius <ee...@gmail.com> wrote:
> > You wouldn't write such a component for general purposes obviously.
>
> ok, that right there i really really dont like. define "general
> purpose"? so now we have features in wicket that are guaranteed to
> work and others that arent? this is going to turn the framework into
> an abysmal pile of crap. why should i only use some "safe" subset when
> writing a component im planning on reusing across projects?

Nah, you're over-reacting. It would just mean that people would use it
for their internal projects, which would be fine with me really.

Eelco

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org

Re: Multiple tags on a single base page?

Posted by Eelco Hillenius <ee...@gmail.com>.

> Now this is something I am much more wary of. If people start developing
> all sorts of "tag libraries" as extensions to Wicket, you'll get a
> proliferation of incompatible stuff. Personally I think it's better NOT
> to have this! Even though I'm in favor of the proposed extension to
> child/extends, I'd rather give it up than have an explosion of custom tags.

It is already possible to do develop custom tags. It is not considered
to be a best practice or anything, but personally, I like the fact
that people can customize Wicket if they want.

Eelco

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org

Re: Multiple tags on a single base page?

Posted by Sebastiaan van Erk <se...@sebster.com>.

Eelco Hillenius wrote:
> On Nov 7, 2007 5:53 PM, Chris Colman <ch...@stepaheadsoftware.com> wrote:
>>> heh, well....you can be against this, but i think if we take a vote
>>> right now most core-devs with binding votes will vote this down....
>> I still can't see the reason for the negativity of some of the
>> core-devs: this is an existing feature.
> 
> People just have different opinions. And the opinions tend to be
> strong around here. :-)

Well, we obviously can't complain too much about your opinions, because 
Wicket is a really good framework and very well thought out. :-)

Still I'd like to know *why* you don't like it, though I can imagine 
you're getting tired of this thread.

>> We're just proposing to enhance an existing feature - evolution not
>> revolution.
> 
> I think that regardless who is right or wrong here, we should just do
> this as a separate project, with separate tags. The advantage for the
> people who like this is then that they can implement it however they
> feel it should be done, and won't need to have crazy long threads to
> decide on things. And the core team doesn't have to support something
> they don't fully agree with.
> 
> If we do that, I think everyone should be happy, and we can close the
> case, right?

Unfortunately, that is not really the case.

- I would prefer the same tag (it is 100% backwards compatible, and it 
is the same feature it is now, but with the restriction n=1 dropped).

- I would prefer to have it in core Wicket because otherwise it's 
another dependency with extra configuration to activate it.

That said, if there's no other way, a separate project is the 
next-best-thing. Maybe it's a better way to go about it: prove the 
concept, get it stable, and try get it in core later. ;-)

Regards,
Sebastiaan

> Cheers,
> 
> Eelco
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>

Re: Multiple tags on a single base page?

Posted by Eelco Hillenius <ee...@gmail.com>.

On Nov 7, 2007 5:53 PM, Chris Colman <ch...@stepaheadsoftware.com> wrote:
> > heh, well....you can be against this, but i think if we take a vote
> > right now most core-devs with binding votes will vote this down....
>
> I still can't see the reason for the negativity of some of the
> core-devs: this is an existing feature.

People just have different opinions. And the opinions tend to be
strong around here. :-)

> If the feature sucks so bad why did people have the inspiration to add
> it in the first place in the beginning of wicket's life?

You can blame me for that actually... back then only Juergen cursed as
he was the one who was going to implement it :-)

Anyway, that was pre 1.0. Almost three years ago which is about a life
time in IT terms.

> We're just proposing to enhance an existing feature - evolution not
> revolution.

I think that regardless who is right or wrong here, we should just do
this as a separate project, with separate tags. The advantage for the
people who like this is then that they can implement it however they
feel it should be done, and won't need to have crazy long threads to
decide on things. And the core team doesn't have to support something
they don't fully agree with.

If we do that, I think everyone should be happy, and we can close the
case, right?

Cheers,

Eelco

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org

Re: Multiple tags on a single base page?

Posted by Al Maw <wi...@almaw.com>.

Chris Colman wrote:
>> heh, well....you can be against this, but i think if we take a vote
>> right now most core-devs with binding votes will vote this down....
> 
> I still can't see the reason for the negativity of some of the
> core-devs: this is an existing feature.

No offense to anyone involved, but I'm getting very bored. This thread 
is about ten times longer than it needs to be, the arguments in it have 
been rather confused, and the same thing has been said by the same 
people about a hundred times.

Please can we improve the signal-to-noise ratio? If you have anything 
concrete to add, please comment on the appropriate JIRA issue where 
hopefully people won't have such bad verbal diarrhea.

Regards,

Al

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org

RE: Multiple tags on a single base page?

Posted by Chris Colman <ch...@stepaheadsoftware.com>.

> heh, well....you can be against this, but i think if we take a vote
> right now most core-devs with binding votes will vote this down....

I still can't see the reason for the negativity of some of the
core-devs: this is an existing feature.

If the feature sucks so bad why did people have the inspiration to add
it in the first place in the beginning of wicket's life?

We're just proposing to enhance an existing feature - evolution not
revolution.

> 
> so we can make this pluggable and someone can put it on wicket-stuff
> or there is a chance it wont make it in at all...

It seems strange to want to make a more powerful version of an already
existing feature accessible only via a plug in. Maybe some of the
core-devs are starting to lose a bit of their zing or their desire for a
challenge - a zing that comes so naturally in a project's infancy.

> 
> -igor
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org

Re: Multiple tags on a single base page?

Posted by Igor Vaynberg <ig...@gmail.com>.

heh, well....you can be against this, but i think if we take a vote
right now most core-devs with binding votes will vote this down....

so we can make this pluggable and someone can put it on wicket-stuff
or there is a chance it wont make it in at all...

-igor


On Nov 7, 2007 3:59 PM, Sebastiaan van Erk <se...@sebster.com> wrote:
> Hi,
>
> I haven't really heard any real arguments against this patch. Basically
> it's just relaxing a constraint on the current implementation of
> child/extend. It's not so much a new feature as improving the current
> feature. I am honestly interested in why people are so against it.
>
> Igor Vaynberg wrote:
> > what do we need to refactor to make a plugin like this possible?
>
> Now this is something I am much more wary of. If people start developing
> all sorts of "tag libraries" as extensions to Wicket, you'll get a
> proliferation of incompatible stuff. Personally I think it's better NOT
> to have this! Even though I'm in favor of the proposed extension to
> child/extends, I'd rather give it up than have an explosion of custom tags.
>
> Regards,
> Sebastiaan
>
>
> > -igor
> >
> >
> > On Nov 7, 2007 2:50 PM, Eelco Hillenius <ee...@gmail.com> wrote:
> >>> some here like it and others dont like it, so wouldnt be an different
> >>> project like wicket-extension the part for this?
> >> That's what I'm arguing. Though thinking about it a little bit longer,
> >> it should probably not even be a core project, but rather a
> >> wicket-stuff one.
> >>
> >>> couldn't this be
> >>> applied similar to the wicket-jmx plugin where you just dump the jar
> >>> into the classpath and have it registering and enabling itself?
> >> That would be ok only if it would apply to a whole different set of
> >> tags. Which is probably the best way to go about this anyway.
> >>
> >> Is there anything in anyone's way to implement this right now as a
> >> separate bunch of tags?
> >>
> >>
> >> Eelco
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >> For additional commands, e-mail: users-help@wicket.apache.org
> >>
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > For additional commands, e-mail: users-help@wicket.apache.org
> >
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org

Re: Multiple tags on a single base page?

Posted by Sebastiaan van Erk <se...@sebster.com>.

Hi,

I haven't really heard any real arguments against this patch. Basically 
it's just relaxing a constraint on the current implementation of 
child/extend. It's not so much a new feature as improving the current 
feature. I am honestly interested in why people are so against it.

Igor Vaynberg wrote:
> what do we need to refactor to make a plugin like this possible?

Now this is something I am much more wary of. If people start developing 
all sorts of "tag libraries" as extensions to Wicket, you'll get a 
proliferation of incompatible stuff. Personally I think it's better NOT 
to have this! Even though I'm in favor of the proposed extension to 
child/extends, I'd rather give it up than have an explosion of custom tags.

Regards,
Sebastiaan

> -igor
> 
> 
> On Nov 7, 2007 2:50 PM, Eelco Hillenius <ee...@gmail.com> wrote:
>>> some here like it and others dont like it, so wouldnt be an different
>>> project like wicket-extension the part for this?
>> That's what I'm arguing. Though thinking about it a little bit longer,
>> it should probably not even be a core project, but rather a
>> wicket-stuff one.
>>
>>> couldn't this be
>>> applied similar to the wicket-jmx plugin where you just dump the jar
>>> into the classpath and have it registering and enabling itself?
>> That would be ok only if it would apply to a whole different set of
>> tags. Which is probably the best way to go about this anyway.
>>
>> Is there anything in anyone's way to implement this right now as a
>> separate bunch of tags?
>>
>>
>> Eelco
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>

Re: Multiple tags on a single base page?

Posted by Igor Vaynberg <ig...@gmail.com>.

what do we need to refactor to make a plugin like this possible?

-igor


On Nov 7, 2007 2:50 PM, Eelco Hillenius <ee...@gmail.com> wrote:
> > some here like it and others dont like it, so wouldnt be an different
> > project like wicket-extension the part for this?
>
> That's what I'm arguing. Though thinking about it a little bit longer,
> it should probably not even be a core project, but rather a
> wicket-stuff one.
>
> > couldn't this be
> > applied similar to the wicket-jmx plugin where you just dump the jar
> > into the classpath and have it registering and enabling itself?
>
> That would be ok only if it would apply to a whole different set of
> tags. Which is probably the best way to go about this anyway.
>
> Is there anything in anyone's way to implement this right now as a
> separate bunch of tags?
>
>
> Eelco
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org

Re: Multiple tags on a single base page?

Posted by Eelco Hillenius <ee...@gmail.com>.

> some here like it and others dont like it, so wouldnt be an different
> project like wicket-extension the part for this?

That's what I'm arguing. Though thinking about it a little bit longer,
it should probably not even be a core project, but rather a
wicket-stuff one.

> couldn't this be
> applied similar to the wicket-jmx plugin where you just dump the jar
> into the classpath and have it registering and enabling itself?

That would be ok only if it would apply to a whole different set of
tags. Which is probably the best way to go about this anyway.

Is there anything in anyone's way to implement this right now as a
separate bunch of tags?

Eelco

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org

Re: Multiple tags on a single base page?

Posted by Korbinian Bachl <ko...@whiskyworld.de>.

just a question to you Igor and Eelco:

some here like it and others dont like it, so wouldnt be an different 
project like wicket-extension the part for this? couldn't this be 
applied similar to the wicket-jmx plugin where you just dump the jar 
into the classpath and have it registering and enabling itself?

I mean I personally would prefer to have a slim wicket-core but dont see 
a reason to forbid this as a dependencyjar (e.g: Special BasePage ala 
MultiWebPage) as this would mean a missing package and be shown in every 
IDE?

Best

Korbinian

Igor Vaynberg schrieb:
> On Nov 7, 2007 1:39 PM, Eelco Hillenius <ee...@gmail.com> wrote:
>> You wouldn't write such a component for general purposes obviously.
> 
> ok, that right there i really really dont like. define "general
> purpose"? so now we have features in wicket that are guaranteed to
> work and others that arent? this is going to turn the framework into
> an abysmal pile of crap. why should i only use some "safe" subset when
> writing a component im planning on reusing across projects?
> 
> -igor
> 
> 
> 
> 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.
>>
>>
>> Eelco
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
> 
> 
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org

Re: Multiple tags on a single base page?

Posted by Igor Vaynberg <ig...@gmail.com>.

On Nov 7, 2007 1:39 PM, Eelco Hillenius <ee...@gmail.com> wrote:
> You wouldn't write such a component for general purposes obviously.

ok, that right there i really really dont like. define "general
purpose"? so now we have features in wicket that are guaranteed to
work and others that arent? this is going to turn the framework into
an abysmal pile of crap. why should i only use some "safe" subset when
writing a component im planning on reusing across projects?

-igor

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.
>
>
> Eelco
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org

Re: Multiple tags on a single base page?

Posted by Eelco Hillenius <ee...@gmail.com>.

> 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.

That's the responsibility of individual projects. People can create
custom tags and stuff as well.

>   - 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.

What I would be ready to do is ensure that people who want this can
implement it. We could ship it with Wicket (but disabled), or just
leave it outside altogether, leaving it up to users to create e.g. a
wicket-stuff project for it. I agree we shouldn't make it our
responsibility, not even a little bit, and certainly shouldn't hint
that this would be the way to go when a couple of core developers
don't agree with it in the first place.

Eelco

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org

Re: Multiple tags on a single base page?

Posted by Al Maw <wi...@almaw.com>.

Eelco Hillenius wrote:
> On Nov 7, 2007 1:32 PM, Igor Vaynberg <ig...@gmail.com> 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: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org

Re: Multiple tags on a single base page?

Posted by Eelco Hillenius <ee...@gmail.com>.

On Nov 7, 2007 1:32 PM, Igor Vaynberg <ig...@gmail.com> 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.

Eelco

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org

Re: Multiple tags on a single base page?

Posted by Igor Vaynberg <ig...@gmail.com>.

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?

-igor


On Nov 7, 2007 1:05 PM, Eelco Hillenius <ee...@gmail.com> wrote:
> On Nov 7, 2007 11:19 AM, Scott Swank <sc...@gmail.com> wrote:
> > I can see how <wicket:abstract> and <wicket:implements> tags could be
> > a nice enhancement to the current <wicket:extend> and <wicket:child>
> > tags.  Do you have a working, or mostly working, patch?
>
> What I think we should do with this is make it an option. It would be
> turned off by default, requiring users to an extra one or two lines of
> configuration to turn this on (we've done this before), and let it
> prove itself. Sounds to me like everyone would be happy.
>
> WDYT?
>
> Eelco
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org

Re: Multiple tags on a single base page?

Posted by Stefan Fußenegger <st...@gmx.at>.

hi eelco,

Assume the tag wouldn't be renamed. Then it would only be a new and optional
(!) attribute for the child/extend tags. So isn't it unnecessary to
explicitly turn on/off a feature that you could implicitly turn on as soon
as this attribute is used?

The naming - is abstract/implement better than child/extend - is another
topic I really didn't want to argue about.

This is just an idea. I know that supporting it as wicket core feature
(docs, mailing list, code, ...) is a totally different question.

regards, stefan

100th reply - is it a Good Thing (tm) ;)




Eelco Hillenius wrote:
> 
> On Nov 7, 2007 11:19 AM, Scott Swank <sc...@gmail.com> wrote:
>> I can see how <wicket:abstract> and <wicket:implements> tags could be
>> a nice enhancement to the current <wicket:extend> and <wicket:child>
>> tags.  Do you have a working, or mostly working, patch?
> 
> What I think we should do with this is make it an option. It would be
> turned off by default, requiring users to an extra one or two lines of
> configuration to turn this on (we've done this before), and let it
> prove itself. Sounds to me like everyone would be happy.
> 
> WDYT?
> 
> 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/Multiple-%3Cwicket%3Achild--%3E-tags-on-a-single-base-page--tf4738673.html#a13643104
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: Multiple tags on a single base page?

Posted by Eelco Hillenius <ee...@gmail.com>.

On Nov 7, 2007 11:19 AM, Scott Swank <sc...@gmail.com> wrote:
> I can see how <wicket:abstract> and <wicket:implements> tags could be
> a nice enhancement to the current <wicket:extend> and <wicket:child>
> tags.  Do you have a working, or mostly working, patch?

What I think we should do with this is make it an option. It would be
turned off by default, requiring users to an extra one or two lines of
configuration to turn this on (we've done this before), and let it
prove itself. Sounds to me like everyone would be happy.

WDYT?

Eelco

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org

Re: Multiple tags on a single base page?

Posted by Scott Swank <sc...@gmail.com>.

I can see how <wicket:abstract> and <wicket:implements> tags could be
a nice enhancement to the current <wicket:extend> and <wicket:child>
tags.  Do you have a working, or mostly working, patch?

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org

Re: Multiple tags on a single base page?

Posted by Igor Vaynberg <ig...@gmail.com>.

On Nov 7, 2007 11:22 AM, Chris Colman <ch...@stepaheadsoftware.com> wrote:
> > > How can it get messy when it's not yet possible to do in wicket?
> >
> > i believe it has been shown multiple times already that it CAN be done
> > with vanilla wicket...
>
> I didn't like the look of any of those 'coded' solutions.

i dont like the look of a lot of code in wicket, but that is not a
valid criteria

> They were not from the coding elegance book I've read.

that is extremely subjective, so once again - not a valid criteria.
you have just as many people saying they prefer it...

> They also mean I'm starting to
> arrange, layout and compose my pages in Java instead of markup (meaning
> my graphic designers lose control).

not at all. in java you simply declare the areas that can be extended.
this is no different then a page adding components that are meant to
be in some wicket:implements tag.

> The abilty to control layout completely at the markup level instead of
> the Java level is why I moved to Wicket from another framework in the
> first place and I guess a lot of others have too.

like i said, you dont lose that at all

> The division of
> responsibility in Wicket is something not achieved by any other
> framework I have used which is great because I don't think I'm going to
> be able to teach my graphic designers Java any time soon.

i can argue that now your graphics designer needs to know about the
"hierarchy" of pages in order to know which wicekt:implement areas are
available to them in some page, so...

>
> I also wouldn't classify as "vanilla" that alternative, workaround using
> low level plumbing code that hooks into the lifecycle methods.

there is nothing low-level about onbeforerender() - its not called
internalOnBeforeRender() is it?

> It's more
> like a honeycomb chocolate fudge, banana sundae, with 1" thick caramel
> sauce sprinkled with 100s and 1000s ;)  - it sounds great on the menu
> but after you've finished it you're left wondering if you made the right
> decision.

i have implemented code like that and was not left wondering at all,
but maybe thats just me

-igor

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org

RE: Multiple tags on a single base page?

Posted by Chris Colman <ch...@stepaheadsoftware.com>.

> > How can it get messy when it's not yet possible to do in wicket?
> 
> i believe it has been shown multiple times already that it CAN be done
> with vanilla wicket...

I didn't like the look of any of those 'coded' solutions. They were not
from the coding elegance book I've read. They also mean I'm starting to
arrange, layout and compose my pages in Java instead of markup (meaning
my graphic designers lose control).

The abilty to control layout completely at the markup level instead of
the Java level is why I moved to Wicket from another framework in the
first place and I guess a lot of others have too. The division of
responsibility in Wicket is something not achieved by any other
framework I have used which is great because I don't think I'm going to
be able to teach my graphic designers Java any time soon.

I also wouldn't classify as "vanilla" that alternative, workaround using
low level plumbing code that hooks into the lifecycle methods. It's more
like a honeycomb chocolate fudge, banana sundae, with 1" thick caramel
sauce sprinkled with 100s and 1000s ;)  - it sounds great on the menu
but after you've finished it you're left wondering if you made the right
decision.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org

Re: Multiple tags on a single base page?

Posted by Igor Vaynberg <ig...@gmail.com>.

On Nov 7, 2007 10:38 AM, Chris Colman <ch...@stepaheadsoftware.com> wrote:
>
> How can it get messy when it's not yet possible to do in wicket?

i believe it has been shown multiple times already that it CAN be done
with vanilla wicket...

-igor

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org

RE: Multiple tags on a single base page?

Posted by Chris Colman <ch...@stepaheadsoftware.com>.

> > And if somebody really needs 5 child areas, something else might be
even
> > messier than the page's constructor. I rather think that 2, 3 or in
rare
> > cases even 4 ids could make sense.
> 
> i must disagree - i have a basepage which defines the default layout
on a
> project, i.e. header, top-nav-container (imprint etc), navigation,
> content-left/-right/main, footer - this makes 7 panels which are added
on
> the
> way down to the resulting page...
> 
> but i don't use abstract methods for this, for it can get messy (as
stated
> in other comments).

How can it get messy when it's not yet possible to do in wicket? You
mention 7 different panels which is > 1 and so not currently supported
by wicket's current child/extends feature. Unless you mean that trying
to override 7 different sections with only one child/extends feature -
but now my brain hurts - the anticipated messiness my be a result of
trying to implement multiple specialized sections without support for it
being in wicket yet ;)

(but given that many people are starting to warm to the idea you might
be able to do this sooner rather than later!)


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org

Re: Multiple tags on a single base page?

Posted by Stefan Fußenegger <st...@gmx.at>.

But the number of added panels needn't be the number of abstract section
(though it could). 

-- stefan 


Jan Kriesten wrote:
> 
> 
> hi stefan,
> 
>> And if somebody really needs 5 child areas, something else might be even
>> messier than the page's constructor. I rather think that 2, 3 or in rare
>> cases even 4 ids could make sense.
> 
> i must disagree - i have a basepage which defines the default layout on a
> project, i.e. header, top-nav-container (imprint etc), navigation,
> content-left/-right/main, footer - this makes 7 panels which are added on
> the
> way down to the resulting page...
> 
> but i don't use abstract methods for this, for it can get messy (as stated
> in
> other comments).
> 
> regards, --- jan.
> 
> 
> 
> ---------------------------------------------------------------------
> 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/Multiple-%3Cwicket%3Achild--%3E-tags-on-a-single-base-page--tf4738673.html#a13631624
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: Multiple tags on a single base page?

Posted by Jan Kriesten <ja...@renitence.de>.

hi stefan,

> And if somebody really needs 5 child areas, something else might be even
> messier than the page's constructor. I rather think that 2, 3 or in rare
> cases even 4 ids could make sense.

i must disagree - i have a basepage which defines the default layout on a
project, i.e. header, top-nav-container (imprint etc), navigation,
content-left/-right/main, footer - this makes 7 panels which are added on the
way down to the resulting page...

but i don't use abstract methods for this, for it can get messy (as stated in
other comments).

regards, --- jan.



---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org

Re: Multiple tags on a single base page?

Posted by Stefan Fußenegger <st...@gmx.at>.

>From the Java-side, it isn't visible, whether a component will be placed in
whatever html part. So you add all components in the constructor, yes.
However, it's as messy as adding 5 components is right now ... they will
just be added at different places.

And if somebody really needs 5 child areas, something else might be even
messier than the page's constructor. I rather think that 2, 3 or in rare
cases even 4 ids could make sense.

Is that what you meant?

-- stefan


Johan Compagner wrote:
> 
> no not the merging of markup.
> but inside the constructor of the child/sub page.
> Where do you make all the root components of all the child parts?
> you will add that to the page itself right?
> 
> I just say that then it could be a bit messy when you have 5 child area's
> 
> johan
> 
> 
> 
> On 11/7/07, Stefan Fußenegger <st...@gmx.at> wrote:
>>
>>
>> hi johan,
>>
>>
>> Johan Compagner wrote:
>> >
>> > 1 thing that does bother me a bit (but maybe i have to do a deeper look
>> > into
>> > the patch) how do you separate
>> > the components in the constructor of the sub page.. i guess you just
>> add
>> > all
>> > the components over all the child fragments
>> > in the page itself. That's not a nice separation... That can lead to
>> big
>> a
>> > big mess.. Because what component belong to what child part. "
>> >
>>
>> I don't get what you mean here. However, my implementation is closely
>> related to Juergen's MergedMarkup.java (and admittedly partially copied)
>> and
>> does the same.
>>
>> -----
>> -------
>> Stefan Fußenegger
>> http://talk-on-tech.blogspot.com // looking for a nicer domain ;)
>> --
>> View this message in context:
>> http://www.nabble.com/Multiple-%3Cwicket%3Achild--%3E-tags-on-a-single-base-page--tf4738673.html#a13629154
>> 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
>>
>>
> 
> 


-----
-------
Stefan Fußenegger
http://talk-on-tech.blogspot.com // looking for a nicer domain ;)
-- 
View this message in context: http://www.nabble.com/Multiple-%3Cwicket%3Achild--%3E-tags-on-a-single-base-page--tf4738673.html#a13631363
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: Multiple tags on a single base page?

Posted by Johan Compagner <jc...@gmail.com>.

no not the merging of markup.
but inside the constructor of the child/sub page.
Where do you make all the root components of all the child parts?
you will add that to the page itself right?

I just say that then it could be a bit messy when you have 5 child area's

johan



On 11/7/07, Stefan Fußenegger <st...@gmx.at> wrote:
>
>
> hi johan,
>
>
> Johan Compagner wrote:
> >
> > 1 thing that does bother me a bit (but maybe i have to do a deeper look
> > into
> > the patch) how do you separate
> > the components in the constructor of the sub page.. i guess you just add
> > all
> > the components over all the child fragments
> > in the page itself. That's not a nice separation... That can lead to big
> a
> > big mess.. Because what component belong to what child part. "
> >
>
> I don't get what you mean here. However, my implementation is closely
> related to Juergen's MergedMarkup.java (and admittedly partially copied)
> and
> does the same.
>
> -----
> -------
> Stefan Fußenegger
> http://talk-on-tech.blogspot.com // looking for a nicer domain ;)
> --
> View this message in context:
> http://www.nabble.com/Multiple-%3Cwicket%3Achild--%3E-tags-on-a-single-base-page--tf4738673.html#a13629154
> 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: Multiple tags on a single base page?

Posted by Stefan Fußenegger <st...@gmx.at>.

hi johan,


Johan Compagner wrote:
> 
> 1 thing that does bother me a bit (but maybe i have to do a deeper look
> into
> the patch) how do you separate
> the components in the constructor of the sub page.. i guess you just add
> all
> the components over all the child fragments
> in the page itself. That's not a nice separation... That can lead to big a
> big mess.. Because what component belong to what child part. "
> 

I don't get what you mean here. However, my implementation is closely
related to Juergen's MergedMarkup.java (and admittedly partially copied) and
does the same.

-----
-------
Stefan Fußenegger
http://talk-on-tech.blogspot.com // looking for a nicer domain ;)
-- 
View this message in context: http://www.nabble.com/Multiple-%3Cwicket%3Achild--%3E-tags-on-a-single-base-page--tf4738673.html#a13629154
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: Multiple tags on a single base page?

Posted by Johan Compagner <jc...@gmail.com>.

i do see your point, but it is not that much different, its just another way
of doing stuff.

Markup inheritance does come from the border stuff. i think i was the one
that proposes it when
we had a meeting here now a few years ago here in Holland so that that we
could border pages.
Then Juergen did implement it..

The thing that the multiply child's solve is that you can have the markup in
the sub page itself
instead of in panels. You can currently have the markup in the sub page (as
fragments), but
then you also have to define <extend> <child>. Else the sub page would
override the complete
base page markup.

But we can see for 1.4 if we can incorporate it into the core. But do make
sure that we don't
create a lot more tags, which is not the case as far as i see. So just just
that name attribute tag tags the specific parts.

1 thing that does bother me a bit (but maybe i have to do a deeper look into
the patch) how do you separate
the components in the constructor of the sub page.. i guess you just add all
the components over all the child fragments
in the page itself. That's not a nice separation... That can lead to big a
big mess.. Because what component belong to what child part.

And the previewability is a bit of mess if you would have 5 childs in your
sub page.
That are then just "random" blocks of html.


johan


On 11/7/07, Stefan Fußenegger <st...@gmx.at> wrote:
>
>
> Well, if naming is your only concern, the attribute's name can easily be
> replaced with something else than id ... e.g. name
>
> <wicket:abstract name="foo" />
>
> <wicket:implement name="foo">
> some text
> </wicket:implement>
>
> and remember that they can be optional as well:
>
> <wicket:abstract />
>
> <wicket:implement>
> some text
> </wicket:implement>
>
> This way, its completely compatible with child/extend (which can be
> proofed
> with the existing junit test for markup inheritance)
>
> just a question: do i start to convince you? ;)
>
> best regards
>
>
> Bruno Borges wrote:
> >
> > Let me paste what I commented in WICKET-1134:
> >
> > *I think this improvement is just more of a way to "override" components
>
> > declared in markups of a super class. Because this is what really
> happens.
> > Let's check your example:
> >
> > In the BasePage, there are two fragments:
> > - subNavigation
> > - content
> >
> > What about if I want to have a fragment in SectionPage with id
> "content",
> > but not related with that content from BasePage? You see, the concept of
> > extend/child, is the same as in OOP's inheritance. What goes in child,
> is
> > from the subclass. Period.
> >
> > In Java, if you declare:
> > class BasePage ... {
> >     protected Object someProperty;
> > }
> >
> > class SectionPage extends BasePage {
> >     protected Object someProperty;
> > }
> >
> > What happens here is that SectionPage.someProperty does NOT
> > override/implement/whatever-you-wanna-call, BasePage.someProperty. What
> > you
> > want to do in HTML would be this in Java.
> >
> > I'm worry about people trying to subclass some WebMarkupContainer, and
> > having to be carefully with components ids, just to _not_ match
> something
> > that would generate strange output.
> >
> > If in SectionPage I add some component (like Label) with "content" id,
> > what
> > would happen? Throw a message: "You cannot use this id because there's
> an
> > abstract 'content' markup in BasePage.html". This would lead to code in
> > HTML
> > that has NO reference within it's Java class.
> >
> > This means that: what you don't see in Java, it *might* be possible to
> > exist
> > in the HTML.
> >
> > And what I like most of Wicket, is its ability to let me take control of
> > everything, just from one source: Java. But if I'm going to be obligated
> > of
> > taking care of what people declare in HTML files that I can't see in
> some
> > Java source code, then I will reconsider my framework's choice.
> >
> > Regards*
> >
> > Now, Stefan, let me reply your last comment in the issue:
> > *No, ids used with abstract/implement are completely different from
> > wicket:ids ... they are only used to construct (i.e. merge ... or link)
> > the
> > markup, so it is perfectly legal to use <div wicket:id="foo"> when there
> > is
> > a <wicket:abstract id="foo"> somewhere, as they won't be related.
> > Therefore,
> > no of the concerns you mention would apply, as ...
> >
> > The concept of abstract/implement is the same as in OOP's inheritance.
> > What
> > goes in child, is from the subclass! Exclamation mark! ;)*
> >
> > Ok, you propose a new attribute for extend/abstract, child/implement
> pair
> > tags. And you say that this id attribute will NOT have any relationship
> > with
> > wicket:id. Well, isn't this something... scary? The documentation will
> > have
> > to take care of this, because it will _not_ be intuitive.
> >
> > Regards,
> >
> >
> > On Nov 7, 2007 10:15 AM, Stefan Fußenegger <stefan_fussenegger@gmx.at >
> > wrote:
> >
> >>
> >> Hi Mats, let me try to explain what Chris and I see here that others
> >> don't
> >> -
> >> may it be there or not ;)
> >>
> >> You can of course do everything with panels that could be done with
> >> multiple
> >> abstract sections (may they be named wicket:child or wicket:abstract).
> >> However, if this is the only argument, you wouldn't need markup
> >> inheritance
> >> at all! The proposed change is just an extension of exactly this markup
>
> >> inheritance concept (that everybody loves) to make it even more
> powerful
> >> than it already is.
> >>
> >> I was quite new to wicket (which I still am) and came across a
> situation
> >> where I wanted to use two abstract sections: one for a sub-navigation
> >> that
> >> was common for several pages in a section and one for the actual
> content.
> >> For me, as a wicket newbie, it would have been most natural to use
> markup
> >> inheritance to solve this problem. Using abstract methods, while being
> a
> >> nice solution (workaround?), didn't come to my mind at once, nor did I
> >> find
> >> it somewhere in the docs.
> >>
> >> imho, there are two possible solution to this problem:
> >> 1. promote using abstract methods for this in the docs as the
> wicket-way
> >> of
> >> doing it
> >> 2. extend the current markup inheritance mechanism (which I tried to do
> >> with
> >> my patch/prototype)
> >>
> >> -- stefan
> >>
> >>
> >> Mats Norén-2 wrote:
> >> >
> >> > On Nov 7, 2007 11:31 AM, Mats Norén < mats.noren@gmail.com> wrote:
> >> >> Hmm...I'm interested in seeing the difference as well. I would love
> to
> >> >> get it but right now I don't.
> >> >>
> >> >> Chris Colman wrote:
> >> >> "This new feature, or extension of the exiting feature, allows more
> >> than
> >> >> one section of markup to be "specialized" by derived (extended)
> >> markups
> >> >> whereas currently wicket only supports the deferred
> >> >> definition/implementation of a single markup section in any page. In
> >> >> other words we want to make a powerful feature even more powerful."
> >> >>
> >> >> Is the above statement really true considering that by adding
> abstract
> >> >> methods to your page you defer the creation of the markup in just
> the
> >> >> same way as the new proposed solution?
> >> >>
> >> >> BasePage.java
> >> >>
> >> >> public BasePage() {
> >> >>     addAbstract1("abstractId1");
> >> >>     addAbstract2("abstractId2);
> >> >> }
> >> >>
> >> >> public abstract addAbstract1(String abstractId1);
> >> >> public abstract addAbstract2(String abstractId2);
> >> >
> >> > A little typo here..I meant:
> >> >
> >> > public BasePage() {
> >> >     add(addAbstract1("abstractId1"));
> >> >     add(addAbstract2("abstractId2));
> >> >  }
> >> >
> >> > public abstract Component addAbstract1(String abstractId1);
> >> > public abstract Component addAbstract2(String abstractId2);
> >> >
> >> > /Mats
> >> >
> >> > ---------------------------------------------------------------------
>
> >> > 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/Multiple-%3Cwicket%3Achild--%3E-tags-on-a-single-base-page--tf4738673.html#a13626055
> >> Sent from the Wicket - User mailing list archive at Nabble.com<http://nabble.com/>
> .
> >>
> >>
> >> ---------------------------------------------------------------------
> >> 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/Multiple-%3Cwicket%3Achild--%3E-tags-on-a-single-base-page--tf4738673.html#a13627156
>
> Sent from the Wicket - User mailing list archive at Nabble.com<http://nabble.com/>
> .
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>

Re: Multiple tags on a single base page?

Posted by Bruno Borges <br...@gmail.com>.

>
> just a question: do i start to convince you? ;)
>
No... you are not... :D far far away from that

But don't take it personal, my opinion is technical... only!

On Nov 7, 2007 11:29 AM, Stefan Fußenegger <st...@gmx.at>
wrote:

>
> Well, if naming is your only concern, the attribute's name can easily be
> replaced with something else than id ... e.g. name
>
> <wicket:abstract name="foo" />
>
> <wicket:implement name="foo">
> some text
> </wicket:implement>
>
> and remember that they can be optional as well:
>
> <wicket:abstract />
>
> <wicket:implement>
> some text
> </wicket:implement>
>
> This way, its completely compatible with child/extend (which can be
> proofed
> with the existing junit test for markup inheritance)
>
> just a question: do i start to convince you? ;)
>
> best regards
>
>
> Bruno Borges wrote:
> >
> > Let me paste what I commented in WICKET-1134:
> >
> > *I think this improvement is just more of a way to "override" components
> > declared in markups of a super class. Because this is what really
> happens.
> > Let's check your example:
> >
> > In the BasePage, there are two fragments:
> > - subNavigation
> > - content
> >
> > What about if I want to have a fragment in SectionPage with id
> "content",
> > but not related with that content from BasePage? You see, the concept of
> > extend/child, is the same as in OOP's inheritance. What goes in child,
> is
> > from the subclass. Period.
> >
> > In Java, if you declare:
> > class BasePage ... {
> >     protected Object someProperty;
> > }
> >
> > class SectionPage extends BasePage {
> >     protected Object someProperty;
> > }
> >
> > What happens here is that SectionPage.someProperty does NOT
> > override/implement/whatever-you-wanna-call, BasePage.someProperty. What
> > you
> > want to do in HTML would be this in Java.
> >
> > I'm worry about people trying to subclass some WebMarkupContainer, and
> > having to be carefully with components ids, just to _not_ match
> something
> > that would generate strange output.
> >
> > If in SectionPage I add some component (like Label) with "content" id,
> > what
> > would happen? Throw a message: "You cannot use this id because there's
> an
> > abstract 'content' markup in BasePage.html". This would lead to code in
> > HTML
> > that has NO reference within it's Java class.
> >
> > This means that: what you don't see in Java, it *might* be possible to
> > exist
> > in the HTML.
> >
> > And what I like most of Wicket, is its ability to let me take control of
> > everything, just from one source: Java. But if I'm going to be obligated
> > of
> > taking care of what people declare in HTML files that I can't see in
> some
> > Java source code, then I will reconsider my framework's choice.
> >
> > Regards*
> >
> > Now, Stefan, let me reply your last comment in the issue:
> > *No, ids used with abstract/implement are completely different from
> > wicket:ids ... they are only used to construct (i.e. merge ... or link)
> > the
> > markup, so it is perfectly legal to use <div wicket:id="foo"> when there
> > is
> > a <wicket:abstract id="foo"> somewhere, as they won't be related.
> > Therefore,
> > no of the concerns you mention would apply, as ...
> >
> > The concept of abstract/implement is the same as in OOP's inheritance.
> > What
> > goes in child, is from the subclass! Exclamation mark! ;)*
> >
> > Ok, you propose a new attribute for extend/abstract, child/implement
> pair
> > tags. And you say that this id attribute will NOT have any relationship
> > with
> > wicket:id. Well, isn't this something... scary? The documentation will
> > have
> > to take care of this, because it will _not_ be intuitive.
> >
> > Regards,
> >
> >
> > On Nov 7, 2007 10:15 AM, Stefan Fußenegger <st...@gmx.at>
> > wrote:
> >
> >>
> >> Hi Mats, let me try to explain what Chris and I see here that others
> >> don't
> >> -
> >> may it be there or not ;)
> >>
> >> You can of course do everything with panels that could be done with
> >> multiple
> >> abstract sections (may they be named wicket:child or wicket:abstract).
> >> However, if this is the only argument, you wouldn't need markup
> >> inheritance
> >> at all! The proposed change is just an extension of exactly this markup
> >> inheritance concept (that everybody loves) to make it even more
> powerful
> >> than it already is.
> >>
> >> I was quite new to wicket (which I still am) and came across a
> situation
> >> where I wanted to use two abstract sections: one for a sub-navigation
> >> that
> >> was common for several pages in a section and one for the actual
> content.
> >> For me, as a wicket newbie, it would have been most natural to use
> markup
> >> inheritance to solve this problem. Using abstract methods, while being
> a
> >> nice solution (workaround?), didn't come to my mind at once, nor did I
> >> find
> >> it somewhere in the docs.
> >>
> >> imho, there are two possible solution to this problem:
> >> 1. promote using abstract methods for this in the docs as the
> wicket-way
> >> of
> >> doing it
> >> 2. extend the current markup inheritance mechanism (which I tried to do
> >> with
> >> my patch/prototype)
> >>
> >> -- stefan
> >>
> >>
> >> Mats Norén-2 wrote:
> >> >
> >> > On Nov 7, 2007 11:31 AM, Mats Norén <ma...@gmail.com> wrote:
> >> >> Hmm...I'm interested in seeing the difference as well. I would love
> to
> >> >> get it but right now I don't.
> >> >>
> >> >> Chris Colman wrote:
> >> >> "This new feature, or extension of the exiting feature, allows more
> >> than
> >> >> one section of markup to be "specialized" by derived (extended)
> >> markups
> >> >> whereas currently wicket only supports the deferred
> >> >> definition/implementation of a single markup section in any page. In
> >> >> other words we want to make a powerful feature even more powerful."
> >> >>
> >> >> Is the above statement really true considering that by adding
> abstract
> >> >> methods to your page you defer the creation of the markup in just
> the
> >> >> same way as the new proposed solution?
> >> >>
> >> >> BasePage.java
> >> >>
> >> >> public BasePage() {
> >> >>     addAbstract1("abstractId1");
> >> >>     addAbstract2("abstractId2);
> >> >> }
> >> >>
> >> >> public abstract addAbstract1(String abstractId1);
> >> >> public abstract addAbstract2(String abstractId2);
> >> >
> >> > A little typo here..I meant:
> >> >
> >> > public BasePage() {
> >> >     add(addAbstract1("abstractId1"));
> >> >     add(addAbstract2("abstractId2));
> >> >  }
> >> >
> >> > public abstract Component addAbstract1(String abstractId1);
> >> > public abstract Component addAbstract2(String abstractId2);
> >> >
> >> > /Mats
> >> >
> >> > ---------------------------------------------------------------------
> >> > 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/Multiple-%3Cwicket%3Achild--%3E-tags-on-a-single-base-page--tf4738673.html#a13626055
> >> 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
> >>
> >>
> >
> >
> > --
> > 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/Multiple-%3Cwicket%3Achild--%3E-tags-on-a-single-base-page--tf4738673.html#a13627156
> 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
>
>


-- 
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: Multiple tags on a single base page?

Posted by Stefan Fußenegger <st...@gmx.at>.

Well, if naming is your only concern, the attribute's name can easily be
replaced with something else than id ... e.g. name

<wicket:abstract name="foo" />

<wicket:implement name="foo">
some text
</wicket:implement>

and remember that they can be optional as well:

<wicket:abstract />

<wicket:implement>
some text
</wicket:implement>

This way, its completely compatible with child/extend (which can be proofed
with the existing junit test for markup inheritance)

just a question: do i start to convince you? ;)

best regards


Bruno Borges wrote:
> 
> Let me paste what I commented in WICKET-1134:
> 
> *I think this improvement is just more of a way to "override" components
> declared in markups of a super class. Because this is what really happens.
> Let's check your example:
> 
> In the BasePage, there are two fragments:
> - subNavigation
> - content
> 
> What about if I want to have a fragment in SectionPage with id "content",
> but not related with that content from BasePage? You see, the concept of
> extend/child, is the same as in OOP's inheritance. What goes in child, is
> from the subclass. Period.
> 
> In Java, if you declare:
> class BasePage ... {
>     protected Object someProperty;
> }
> 
> class SectionPage extends BasePage {
>     protected Object someProperty;
> }
> 
> What happens here is that SectionPage.someProperty does NOT
> override/implement/whatever-you-wanna-call, BasePage.someProperty. What
> you
> want to do in HTML would be this in Java.
> 
> I'm worry about people trying to subclass some WebMarkupContainer, and
> having to be carefully with components ids, just to _not_ match something
> that would generate strange output.
> 
> If in SectionPage I add some component (like Label) with "content" id,
> what
> would happen? Throw a message: "You cannot use this id because there's an
> abstract 'content' markup in BasePage.html". This would lead to code in
> HTML
> that has NO reference within it's Java class.
> 
> This means that: what you don't see in Java, it *might* be possible to
> exist
> in the HTML.
> 
> And what I like most of Wicket, is its ability to let me take control of
> everything, just from one source: Java. But if I'm going to be obligated
> of
> taking care of what people declare in HTML files that I can't see in some
> Java source code, then I will reconsider my framework's choice.
> 
> Regards*
> 
> Now, Stefan, let me reply your last comment in the issue:
> *No, ids used with abstract/implement are completely different from
> wicket:ids ... they are only used to construct (i.e. merge ... or link)
> the
> markup, so it is perfectly legal to use <div wicket:id="foo"> when there
> is
> a <wicket:abstract id="foo"> somewhere, as they won't be related.
> Therefore,
> no of the concerns you mention would apply, as ...
> 
> The concept of abstract/implement is the same as in OOP's inheritance.
> What
> goes in child, is from the subclass! Exclamation mark! ;)*
> 
> Ok, you propose a new attribute for extend/abstract, child/implement pair
> tags. And you say that this id attribute will NOT have any relationship
> with
> wicket:id. Well, isn't this something... scary? The documentation will
> have
> to take care of this, because it will _not_ be intuitive.
> 
> Regards,
> 
> 
> On Nov 7, 2007 10:15 AM, Stefan Fußenegger <st...@gmx.at>
> wrote:
> 
>>
>> Hi Mats, let me try to explain what Chris and I see here that others
>> don't
>> -
>> may it be there or not ;)
>>
>> You can of course do everything with panels that could be done with
>> multiple
>> abstract sections (may they be named wicket:child or wicket:abstract).
>> However, if this is the only argument, you wouldn't need markup
>> inheritance
>> at all! The proposed change is just an extension of exactly this markup
>> inheritance concept (that everybody loves) to make it even more powerful
>> than it already is.
>>
>> I was quite new to wicket (which I still am) and came across a situation
>> where I wanted to use two abstract sections: one for a sub-navigation
>> that
>> was common for several pages in a section and one for the actual content.
>> For me, as a wicket newbie, it would have been most natural to use markup
>> inheritance to solve this problem. Using abstract methods, while being a
>> nice solution (workaround?), didn't come to my mind at once, nor did I
>> find
>> it somewhere in the docs.
>>
>> imho, there are two possible solution to this problem:
>> 1. promote using abstract methods for this in the docs as the wicket-way
>> of
>> doing it
>> 2. extend the current markup inheritance mechanism (which I tried to do
>> with
>> my patch/prototype)
>>
>> -- stefan
>>
>>
>> Mats Norén-2 wrote:
>> >
>> > On Nov 7, 2007 11:31 AM, Mats Norén <ma...@gmail.com> wrote:
>> >> Hmm...I'm interested in seeing the difference as well. I would love to
>> >> get it but right now I don't.
>> >>
>> >> Chris Colman wrote:
>> >> "This new feature, or extension of the exiting feature, allows more
>> than
>> >> one section of markup to be "specialized" by derived (extended)
>> markups
>> >> whereas currently wicket only supports the deferred
>> >> definition/implementation of a single markup section in any page. In
>> >> other words we want to make a powerful feature even more powerful."
>> >>
>> >> Is the above statement really true considering that by adding abstract
>> >> methods to your page you defer the creation of the markup in just the
>> >> same way as the new proposed solution?
>> >>
>> >> BasePage.java
>> >>
>> >> public BasePage() {
>> >>     addAbstract1("abstractId1");
>> >>     addAbstract2("abstractId2);
>> >> }
>> >>
>> >> public abstract addAbstract1(String abstractId1);
>> >> public abstract addAbstract2(String abstractId2);
>> >
>> > A little typo here..I meant:
>> >
>> > public BasePage() {
>> >     add(addAbstract1("abstractId1"));
>> >     add(addAbstract2("abstractId2));
>> >  }
>> >
>> > public abstract Component addAbstract1(String abstractId1);
>> > public abstract Component addAbstract2(String abstractId2);
>> >
>> > /Mats
>> >
>> > ---------------------------------------------------------------------
>> > 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/Multiple-%3Cwicket%3Achild--%3E-tags-on-a-single-base-page--tf4738673.html#a13626055
>> 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
>>
>>
> 
> 
> -- 
> 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/Multiple-%3Cwicket%3Achild--%3E-tags-on-a-single-base-page--tf4738673.html#a13627156
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: Multiple tags on a single base page?

Posted by Bruno Borges <br...@gmail.com>.

Let me paste what I commented in WICKET-1134:

*I think this improvement is just more of a way to "override" components
declared in markups of a super class. Because this is what really happens.
Let's check your example:

In the BasePage, there are two fragments:
- subNavigation
- content

What about if I want to have a fragment in SectionPage with id "content",
but not related with that content from BasePage? You see, the concept of
extend/child, is the same as in OOP's inheritance. What goes in child, is
from the subclass. Period.

In Java, if you declare:
class BasePage ... {
    protected Object someProperty;
}

class SectionPage extends BasePage {
    protected Object someProperty;
}

What happens here is that SectionPage.someProperty does NOT
override/implement/whatever-you-wanna-call, BasePage.someProperty. What you
want to do in HTML would be this in Java.

I'm worry about people trying to subclass some WebMarkupContainer, and
having to be carefully with components ids, just to _not_ match something
that would generate strange output.

If in SectionPage I add some component (like Label) with "content" id, what
would happen? Throw a message: "You cannot use this id because there's an
abstract 'content' markup in BasePage.html". This would lead to code in HTML
that has NO reference within it's Java class.

This means that: what you don't see in Java, it *might* be possible to exist
in the HTML.

And what I like most of Wicket, is its ability to let me take control of
everything, just from one source: Java. But if I'm going to be obligated of
taking care of what people declare in HTML files that I can't see in some
Java source code, then I will reconsider my framework's choice.

Regards*

Now, Stefan, let me reply your last comment in the issue:
*No, ids used with abstract/implement are completely different from
wicket:ids ... they are only used to construct (i.e. merge ... or link) the
markup, so it is perfectly legal to use <div wicket:id="foo"> when there is
a <wicket:abstract id="foo"> somewhere, as they won't be related. Therefore,
no of the concerns you mention would apply, as ...

The concept of abstract/implement is the same as in OOP's inheritance. What
goes in child, is from the subclass! Exclamation mark! ;)*

Ok, you propose a new attribute for extend/abstract, child/implement pair
tags. And you say that this id attribute will NOT have any relationship with
wicket:id. Well, isn't this something... scary? The documentation will have
to take care of this, because it will _not_ be intuitive.

Regards,

On Nov 7, 2007 10:15 AM, Stefan Fußenegger <st...@gmx.at>
wrote:

>
> Hi Mats, let me try to explain what Chris and I see here that others don't
> -
> may it be there or not ;)
>
> You can of course do everything with panels that could be done with
> multiple
> abstract sections (may they be named wicket:child or wicket:abstract).
> However, if this is the only argument, you wouldn't need markup
> inheritance
> at all! The proposed change is just an extension of exactly this markup
> inheritance concept (that everybody loves) to make it even more powerful
> than it already is.
>
> I was quite new to wicket (which I still am) and came across a situation
> where I wanted to use two abstract sections: one for a sub-navigation that
> was common for several pages in a section and one for the actual content.
> For me, as a wicket newbie, it would have been most natural to use markup
> inheritance to solve this problem. Using abstract methods, while being a
> nice solution (workaround?), didn't come to my mind at once, nor did I
> find
> it somewhere in the docs.
>
> imho, there are two possible solution to this problem:
> 1. promote using abstract methods for this in the docs as the wicket-way
> of
> doing it
> 2. extend the current markup inheritance mechanism (which I tried to do
> with
> my patch/prototype)
>
> -- stefan
>
>
> Mats Norén-2 wrote:
> >
> > On Nov 7, 2007 11:31 AM, Mats Norén <ma...@gmail.com> wrote:
> >> Hmm...I'm interested in seeing the difference as well. I would love to
> >> get it but right now I don't.
> >>
> >> Chris Colman wrote:
> >> "This new feature, or extension of the exiting feature, allows more
> than
> >> one section of markup to be "specialized" by derived (extended) markups
> >> whereas currently wicket only supports the deferred
> >> definition/implementation of a single markup section in any page. In
> >> other words we want to make a powerful feature even more powerful."
> >>
> >> Is the above statement really true considering that by adding abstract
> >> methods to your page you defer the creation of the markup in just the
> >> same way as the new proposed solution?
> >>
> >> BasePage.java
> >>
> >> public BasePage() {
> >>     addAbstract1("abstractId1");
> >>     addAbstract2("abstractId2);
> >> }
> >>
> >> public abstract addAbstract1(String abstractId1);
> >> public abstract addAbstract2(String abstractId2);
> >
> > A little typo here..I meant:
> >
> > public BasePage() {
> >     add(addAbstract1("abstractId1"));
> >     add(addAbstract2("abstractId2));
> >  }
> >
> > public abstract Component addAbstract1(String abstractId1);
> > public abstract Component addAbstract2(String abstractId2);
> >
> > /Mats
> >
> > ---------------------------------------------------------------------
> > 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/Multiple-%3Cwicket%3Achild--%3E-tags-on-a-single-base-page--tf4738673.html#a13626055
> 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
>
>

-- 
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: Multiple tags on a single base page?

Posted by Chris Colman <ch...@stepaheadsoftware.com>.

> Korbinian Bachl wrote:
> > you missed solution3:
> > the real-wicket-way(tm) for multiple content-places in a tied
page-area:
> 
> Whaaa, I seriously hope this is not the real-wicket-way! My brain
hurts!
> 
> A framework is supposed to make things easy and readable! The code
below
> is just way too complicated to achieve something that should be
easy...
> 
> Preferably when doing simple stuff like this, I don't want to be
> confronted with things like rendering (and adding render hooks), or
with
> keeping extra state about components being or not being initalized.
Also
> I don't want to have to copy this boiler plate for every time I want
to
> place some kind of component "hole" in a base page!
> 

Well said! I agree wholeheartedly. I suppose the reason I'm so
passionate about this new multiple child/extends support is that it
helps preserve simplicity for the wicket developer instead of making our
more complex.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org

Re: Multiple tags on a single base page?

Posted by Korbinian Bachl <ko...@whiskyworld.de>.

Sebastiaan van Erk schrieb:
> Korbinian Bachl wrote:
>> you missed solution3:
>> the real-wicket-way(tm) for multiple content-places in a tied page-area:
> 
> Whaaa, I seriously hope this is not the real-wicket-way! My brain hurts!

maybe you should go to a doctor then?...

> 
> A framework is supposed to make things easy and readable! The code below 
> is just way too complicated to achieve something that should be easy...

whats difficult here? it gives you maximum flexibility and was just a 
example(tm) which can be further simplified if you use other container 
types - this was showed to me by Igor some time ago and it has proven 
its success for me...

> 
> Preferably when doing simple stuff like this, I don't want to be 
> confronted with things like rendering (and adding render hooks), or with 
> keeping extra state about components being or not being initalized. Also 
> I don't want to have to copy this boiler plate for every time I want to 
> place some kind of component "hole" in a base page!

usually this kind of code is present at 1 place within a project, not in 
every class, just the raw baseclass (maybe in 2 baseclasses if you have 
a designer who wants to have 2 completely different markups for 1 
project) - compared to other existing poblems of webdeveloping (like 
security and authorization) these 2-minutes i spend on this at all is 
not really mattering...

Best,

Korbinian

> 
> Regards,
> Sebastiaan
> 
>> eg: html:
>> ...
>> <div wicket:id="anything">Place to put anything</div>
-zip-

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org

Re: Multiple tags on a single base page?

Posted by Sebastiaan van Erk <se...@sebster.com>.

Korbinian Bachl wrote:
> you missed solution3:
> the real-wicket-way(tm) for multiple content-places in a tied page-area:

Whaaa, I seriously hope this is not the real-wicket-way! My brain hurts!

A framework is supposed to make things easy and readable! The code below 
is just way too complicated to achieve something that should be easy...

Preferably when doing simple stuff like this, I don't want to be 
confronted with things like rendering (and adding render hooks), or with 
keeping extra state about components being or not being initalized. Also 
I don't want to have to copy this boiler plate for every time I want to 
place some kind of component "hole" in a base page!

Regards,
Sebastiaan

> eg: html:
> ...
> <div wicket:id="anything">Place to put anything</div>
> ...
> 
> java:
> 
> public abstract MyPage extends AnyPageExtendingWicketsWebPage {
> 
>     private boolean initialized = false;
>     private final RepeatingView anything;
> 
>     MyPage() {
>     super();
>         anything = new RepeatingView("anything");
>         add(anything);
>     }
> 
>  /**
>      * Abstract place to add content to the containers
>      */
>     protected abstract void initialize();
> 
>     @Override
>     protected void onBeforeRender() {
>         super.onBeforeRender();
>         if(!initialized) {
>             initialize();
>             initialized = true;
>         }
>     }
> 
>     /**
>     * Adds the content-Component c to Column A
>     * (the smaller one on the left)
>     *
>     * @return
>     */
>     public void addToAnthing(Component c) {
>         c.setRenderBodyOnly(true);
>         getAnything().addOrReplace(c);
>     }
>     
>     public RepeatingView getAything() {
>         return anything;
>     }
> 
> }
> 
> 
> and in extending classes you can easily do this:
> 
>  protected void initialize() {
> 
>           addToAnything(new AnyPanel("id"));
>      addToAnything(new AnyPanel2("id2"));
> }
> 
> etc.
> 
> this is maximum flexible, fast implemented, beeing checked by the IDE 
> and nice OO behaviour as it allows you to chain this over several 
> levels, plus it aids you when it comes to security-limitations as you 
> have a logic hirarchy where you can use each step for more restricted 
> access-rules
> e.g: BasePage -> SecureBasePage -> HighlySecuredBasePage -> MyPage
> 
> if you then need a panel manipulating other areas this is easily done by:
> e.g:
> (MyPage getPage()).getAnything().doWhatYouWantToDo(WhatYouWant)
> 
> (you could also make this final thing abstract and then only override it 
> in the page you place it in wich gives even more control and makes it 
> reusable over projects)
> 
> and this is sth. that happens more often than you expect IMHO
> 
> plus the biggest advancement: the HTML tied to the classes stays clean 
> and is not poluted with some fancy tags (wich is the bigest plague in 
> the Javaworld IMHO... i never understood how they could invent things 
> like JSP or JSF that are worse to even PHP code in a page)
> 
> Best
> 
> Korbinian
> 
> Stefan Fußenegger schrieb:
>> Hi Mats, let me try to explain what Chris and I see here that others 
>> don't -
>> may it be there or not ;)
>>
>> You can of course do everything with panels that could be done with 
>> multiple
>> abstract sections (may they be named wicket:child or wicket:abstract).
>> However, if this is the only argument, you wouldn't need markup 
>> inheritance
>> at all! The proposed change is just an extension of exactly this markup
>> inheritance concept (that everybody loves) to make it even more powerful
>> than it already is.
>>
>> I was quite new to wicket (which I still am) and came across a situation
>> where I wanted to use two abstract sections: one for a sub-navigation 
>> that
>> was common for several pages in a section and one for the actual content.
>> For me, as a wicket newbie, it would have been most natural to use markup
>> inheritance to solve this problem. Using abstract methods, while being a
>> nice solution (workaround?), didn't come to my mind at once, nor did I 
>> find
>> it somewhere in the docs.
>>
>> imho, there are two possible solution to this problem:
>> 1. promote using abstract methods for this in the docs as the 
>> wicket-way of
>> doing it
>> 2. extend the current markup inheritance mechanism (which I tried to 
>> do with
>> my patch/prototype)
>>
>> -- stefan
>>
>>
>> Mats Norén-2 wrote:
>>> On Nov 7, 2007 11:31 AM, Mats Norén <ma...@gmail.com> wrote:
>>>> Hmm...I'm interested in seeing the difference as well. I would love to
>>>> get it but right now I don't.
>>>>
>>>> Chris Colman wrote:
>>>> "This new feature, or extension of the exiting feature, allows more 
>>>> than
>>>> one section of markup to be "specialized" by derived (extended) markups
>>>> whereas currently wicket only supports the deferred
>>>> definition/implementation of a single markup section in any page. In
>>>> other words we want to make a powerful feature even more powerful."
>>>>
>>>> Is the above statement really true considering that by adding abstract
>>>> methods to your page you defer the creation of the markup in just the
>>>> same way as the new proposed solution?
>>>>
>>>> BasePage.java
>>>>
>>>> public BasePage() {
>>>>     addAbstract1("abstractId1");
>>>>     addAbstract2("abstractId2);
>>>> }
>>>>
>>>> public abstract addAbstract1(String abstractId1);
>>>> public abstract addAbstract2(String abstractId2);
>>> A little typo here..I meant:
>>>
>>> public BasePage() {
>>>     add(addAbstract1("abstractId1"));
>>>     add(addAbstract2("abstractId2));
>>>  }
>>>
>>> public abstract Component addAbstract1(String abstractId1);
>>> public abstract Component addAbstract2(String abstractId2);
>>>
>>> /Mats
>>>
>>> ---------------------------------------------------------------------
>>> 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 ;)
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>

Re: Multiple tags on a single base page?

Posted by Johan Compagner <jc...@gmail.com>.

huh why would java code define the layout in this example?
you still have the html of the page that does the layout of those panels
and the content of those panels are layout with the markup of those panels.

Layout in java would be something like:

component.setSize()
component.setLayout()

johan



On 11/7/07, Chris Colman <ch...@stepaheadsoftware.com> wrote:
>
> > and in extending classes you can easily do this:
> >
> >   protected void initialize() {
> >
> >               addToAnything(new AnyPanel("id"));
> >       addToAnything(new AnyPanel2("id2"));
> > }
>
> So now you're proposing the Java code is defining the layout of
> components? That's what the markup's job is I thought.
>
> What I, and probably many others, like about wicket is that the Java
> code is just a "slave" to the markup - not the other way around. The
> graphic designers are free to control where everything goes in markup
> and so long as I have implemented a Java class for each panel that they
> want to use then everything just works. They can rearrange the whole
> look and layout of the side without me touching my Java code.
>
> Your solution is starting to look very much like the Echo2 solution -
> where layout is controlled entirely in Java.
>
> Also: Does your addToAnything method assume a regular, repeating pattern
> - like panels in a column or row? What if the panels I want to
> specialize in derived pages are not laid out in a grid or array
> structure: eg., a sub header that spans the entire page width plus a
> side menu on the left plus a body section in the middle - all separately
> implemented at various levels in the page hierarchy but with the
> structural HTML that lays them out specified in one place in the base
> page?
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>

RE: Multiple tags on a single base page?

Posted by Chris Colman <ch...@stepaheadsoftware.com>.

> and in extending classes you can easily do this:
> 
>   protected void initialize() {
> 
>        	addToAnything(new AnyPanel("id"));
>   	addToAnything(new AnyPanel2("id2"));
> }

So now you're proposing the Java code is defining the layout of
components? That's what the markup's job is I thought.

What I, and probably many others, like about wicket is that the Java
code is just a "slave" to the markup - not the other way around. The
graphic designers are free to control where everything goes in markup
and so long as I have implemented a Java class for each panel that they
want to use then everything just works. They can rearrange the whole
look and layout of the side without me touching my Java code.

Your solution is starting to look very much like the Echo2 solution -
where layout is controlled entirely in Java.

Also: Does your addToAnything method assume a regular, repeating pattern
- like panels in a column or row? What if the panels I want to
specialize in derived pages are not laid out in a grid or array
structure: eg., a sub header that spans the entire page width plus a
side menu on the left plus a body section in the middle - all separately
implemented at various levels in the page hierarchy but with the
structural HTML that lays them out specified in one place in the base
page?

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org

Re: Multiple tags on a single base page?

Posted by Korbinian Bachl <ko...@whiskyworld.de>.

you missed solution3:
the real-wicket-way(tm) for multiple content-places in a tied page-area:

eg: html:
...
<div wicket:id="anything">Place to put anything</div>
...

java:

public abstract MyPage extends AnyPageExtendingWicketsWebPage {

	private boolean initialized = false;
	private final RepeatingView anything;

	MyPage() {
	super();
         anything = new RepeatingView("anything");
         add(anything);
	}

  /**
      * Abstract place to add content to the containers
      */
     protected abstract void initialize();

     @Override
     protected void onBeforeRender() {
         super.onBeforeRender();
         if(!initialized) {
             initialize();
             initialized = true;
         }
     }

     /**
     * Adds the content-Component c to Column A
     * (the smaller one on the left)
     *
     * @return
     */
     public void addToAnthing(Component c) {
         c.setRenderBodyOnly(true);
         getAnything().addOrReplace(c);
     }
	
     public RepeatingView getAything() {
         return anything;
     }

}


and in extending classes you can easily do this:

  protected void initialize() {

       	addToAnything(new AnyPanel("id"));
  	addToAnything(new AnyPanel2("id2"));
}

etc.

this is maximum flexible, fast implemented, beeing checked by the IDE 
and nice OO behaviour as it allows you to chain this over several 
levels, plus it aids you when it comes to security-limitations as you 
have a logic hirarchy where you can use each step for more restricted 
access-rules
e.g: BasePage -> SecureBasePage -> HighlySecuredBasePage -> MyPage

if you then need a panel manipulating other areas this is easily done by:
e.g:
(MyPage getPage()).getAnything().doWhatYouWantToDo(WhatYouWant)

(you could also make this final thing abstract and then only override it 
in the page you place it in wich gives even more control and makes it 
reusable over projects)

and this is sth. that happens more often than you expect IMHO

plus the biggest advancement: the HTML tied to the classes stays clean 
and is not poluted with some fancy tags (wich is the bigest plague in 
the Javaworld IMHO... i never understood how they could invent things 
like JSP or JSF that are worse to even PHP code in a page)

Best

Korbinian

Stefan Fußenegger schrieb:
> Hi Mats, let me try to explain what Chris and I see here that others don't -
> may it be there or not ;)
> 
> You can of course do everything with panels that could be done with multiple
> abstract sections (may they be named wicket:child or wicket:abstract).
> However, if this is the only argument, you wouldn't need markup inheritance
> at all! The proposed change is just an extension of exactly this markup
> inheritance concept (that everybody loves) to make it even more powerful
> than it already is.
> 
> I was quite new to wicket (which I still am) and came across a situation
> where I wanted to use two abstract sections: one for a sub-navigation that
> was common for several pages in a section and one for the actual content.
> For me, as a wicket newbie, it would have been most natural to use markup
> inheritance to solve this problem. Using abstract methods, while being a
> nice solution (workaround?), didn't come to my mind at once, nor did I find
> it somewhere in the docs.
> 
> imho, there are two possible solution to this problem:
> 1. promote using abstract methods for this in the docs as the wicket-way of
> doing it
> 2. extend the current markup inheritance mechanism (which I tried to do with
> my patch/prototype)
> 
> -- stefan
> 
> 
> Mats Norén-2 wrote:
>> On Nov 7, 2007 11:31 AM, Mats Norén <ma...@gmail.com> wrote:
>>> Hmm...I'm interested in seeing the difference as well. I would love to
>>> get it but right now I don't.
>>>
>>> Chris Colman wrote:
>>> "This new feature, or extension of the exiting feature, allows more than
>>> one section of markup to be "specialized" by derived (extended) markups
>>> whereas currently wicket only supports the deferred
>>> definition/implementation of a single markup section in any page. In
>>> other words we want to make a powerful feature even more powerful."
>>>
>>> Is the above statement really true considering that by adding abstract
>>> methods to your page you defer the creation of the markup in just the
>>> same way as the new proposed solution?
>>>
>>> BasePage.java
>>>
>>> public BasePage() {
>>>     addAbstract1("abstractId1");
>>>     addAbstract2("abstractId2);
>>> }
>>>
>>> public abstract addAbstract1(String abstractId1);
>>> public abstract addAbstract2(String abstractId2);
>> A little typo here..I meant:
>>
>> public BasePage() {
>>     add(addAbstract1("abstractId1"));
>>     add(addAbstract2("abstractId2));
>>  }
>>
>> public abstract Component addAbstract1(String abstractId1);
>> public abstract Component addAbstract2(String abstractId2);
>>
>> /Mats
>>
>> ---------------------------------------------------------------------
>> 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 ;)

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org

Re: Multiple tags on a single base page?

Posted by Stefan Fußenegger <st...@gmx.at>.

Hi Mats, let me try to explain what Chris and I see here that others don't -
may it be there or not ;)

You can of course do everything with panels that could be done with multiple
abstract sections (may they be named wicket:child or wicket:abstract).
However, if this is the only argument, you wouldn't need markup inheritance
at all! The proposed change is just an extension of exactly this markup
inheritance concept (that everybody loves) to make it even more powerful
than it already is.

I was quite new to wicket (which I still am) and came across a situation
where I wanted to use two abstract sections: one for a sub-navigation that
was common for several pages in a section and one for the actual content.
For me, as a wicket newbie, it would have been most natural to use markup
inheritance to solve this problem. Using abstract methods, while being a
nice solution (workaround?), didn't come to my mind at once, nor did I find
it somewhere in the docs.

imho, there are two possible solution to this problem:
1. promote using abstract methods for this in the docs as the wicket-way of
doing it
2. extend the current markup inheritance mechanism (which I tried to do with
my patch/prototype)

-- stefan

Mats Norén-2 wrote:
> 
> On Nov 7, 2007 11:31 AM, Mats Norén <ma...@gmail.com> wrote:
>> Hmm...I'm interested in seeing the difference as well. I would love to
>> get it but right now I don't.
>>
>> Chris Colman wrote:
>> "This new feature, or extension of the exiting feature, allows more than
>> one section of markup to be "specialized" by derived (extended) markups
>> whereas currently wicket only supports the deferred
>> definition/implementation of a single markup section in any page. In
>> other words we want to make a powerful feature even more powerful."
>>
>> Is the above statement really true considering that by adding abstract
>> methods to your page you defer the creation of the markup in just the
>> same way as the new proposed solution?
>>
>> BasePage.java
>>
>> public BasePage() {
>>     addAbstract1("abstractId1");
>>     addAbstract2("abstractId2);
>> }
>>
>> public abstract addAbstract1(String abstractId1);
>> public abstract addAbstract2(String abstractId2);
> 
> A little typo here..I meant:
> 
> public BasePage() {
>     add(addAbstract1("abstractId1"));
>     add(addAbstract2("abstractId2));
>  }
> 
> public abstract Component addAbstract1(String abstractId1);
> public abstract Component addAbstract2(String abstractId2);
> 
> /Mats
> 
> ---------------------------------------------------------------------
> 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/Multiple-%3Cwicket%3Achild--%3E-tags-on-a-single-base-page--tf4738673.html#a13626055
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: Multiple tags on a single base page?

Posted by Mats Norén <ma...@gmail.com>.

On Nov 7, 2007 11:31 AM, Mats Norén <ma...@gmail.com> wrote:
> Hmm...I'm interested in seeing the difference as well. I would love to
> get it but right now I don't.
>
> Chris Colman wrote:
> "This new feature, or extension of the exiting feature, allows more than
> one section of markup to be "specialized" by derived (extended) markups
> whereas currently wicket only supports the deferred
> definition/implementation of a single markup section in any page. In
> other words we want to make a powerful feature even more powerful."
>
> Is the above statement really true considering that by adding abstract
> methods to your page you defer the creation of the markup in just the
> same way as the new proposed solution?
>
> BasePage.java
>
> public BasePage() {
>     addAbstract1("abstractId1");
>     addAbstract2("abstractId2);
> }
>
> public abstract addAbstract1(String abstractId1);
> public abstract addAbstract2(String abstractId2);

A little typo here..I meant:

public BasePage() {
    add(addAbstract1("abstractId1"));
    add(addAbstract2("abstractId2));
 }

public abstract Component addAbstract1(String abstractId1);
public abstract Component addAbstract2(String abstractId2);

/Mats

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org

Re: Multiple tags on a single base page?

Posted by John Krasnay <jo...@krasnay.ca>.

On Wed, Nov 07, 2007 at 07:14:01PM +0100, Korbinian Bachl wrote:
> > Given these subtle problems with this approach, I admit I'm warming to
> > the multiple extend/child idea.
> 
> im oposite - if i have X extends in a page, whose extend should be 
> preferred (e.g: manipulating the head or a part outside of itself) ?

Perhaps I don't understand your argument, but it sounds like you're
interpreting this as some sort of multiple inheritance thing. I like to
look at it this way:

- a Wicket page is a Java class and some markup.
- there are three ways a page can acquire its markup
    - it can have its own
    - it can inherit it from a base class
    - it can *mostly* inherit it from a base class, but inject some
      additional markup into the parent markup at a place specified by
      the parent markup

All the current proposal does is allow the parent markup to advertise
multiple places where children can inject their markup. Yes, there are
difficulties with this. Child pages have to be careful about component
ID collisions, the framework has to sort out multiple header
contributions from children and grandchildren, etc., but these problems
are present in the current single extend/child approach. I can't see any
additional ambiguities introduced by allowing additional markup
injection sites.

> my override of onBeforeRender is secure from your point and IMHO more 
> easy...

I suggest it's not so easy for average Java developers starting out with
Wicket. In my experience, many Java developers are unaware of the "don't
call non-private, non-final methods from constructors" rule. Further,
once you've been bitten by that problem, it's not clear that using
onBeforeRender is the answer. And once you've figured *that* out, it's
not clear that you have to protect against multiple invocations.

jk

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org

Re: Multiple tags on a single base page?

Posted by Mats Norén <ma...@gmail.com>.

On Nov 7, 2007 5:13 PM, John Krasnay <jo...@krasnay.ca> wrote:
> You've just illustrated one of the major problems with the
> panel-from-a-subclass approach: it's easy to get it wrong. In your
> example, addAbstract1 and addAbstract2 will be called in a class whose
> constructor has not yet been called. Consider:
>
> public DerivedPage extends BasePage {
>
>     private String name;
>
>     public DerivedPage(String name) {
>         super();
>         this.name = name;
>     }
>
>     public abstract addAbstract1(String abstractId1) {
>         add(new NamePanel(abstractId1, name));
>     }
> }
>
> This code is broken, since you're constructing NamePanel before name has
> been initialized. Someone later in this thread shows a better way to do
> this, by calling the overridable methods from onBeforeRender. But this
> is also tricky; because onBeforeRender can be called multiple times you
> must maintain a flag to ensure you only add your panels once.
>
> Given these subtle problems with this approach, I admit I'm warming to
> the multiple extend/child idea.

I stand corrected! :)

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org

Re: Multiple tags on a single base page?

Posted by Sebastiaan van Erk <se...@sebster.com>.

John Krasnay wrote:

> You've just illustrated one of the major problems with the
> panel-from-a-subclass approach: it's easy to get it wrong. In your
> example, addAbstract1 and addAbstract2 will be called in a class whose
> constructor has not yet been called. Consider:
> 
> public DerivedPage extends BasePage {
> 
>     private String name;
> 
>     public DerivedPage(String name) {
>         super();
>         this.name = name;
>     }
> 
>     public abstract addAbstract1(String abstractId1) {
>         add(new NamePanel(abstractId1, name));
>     }
> }
> 
> This code is broken, since you're constructing NamePanel before name has
> been initialized. Someone later in this thread shows a better way to do
> this, by calling the overridable methods from onBeforeRender. But this
> is also tricky; because onBeforeRender can be called multiple times you
> must maintain a flag to ensure you only add your panels once.

In fact, almost all official sources consider this an antipattern (e.g. 
Effective Java #15), and specifically state that you should never call 
overridable methods from a constructor at all. So either the method 
called from the constructor should be private or it should be final.

I wonder what the "official" Wicket policy is on this? Careful 
documentation?

Regards,
Sebastiaan

> Given these subtle problems with this approach, I admit I'm warming to
> the multiple extend/child idea.
> 
> jk
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>

RE: Multiple tags on a single base page?

Posted by Chris Colman <ch...@stepaheadsoftware.com>.

>  > Given these subtle problems with this approach, I admit I'm warming
to
>  > the multiple extend/child idea.
> 
> im oposite - if i have X extends in a page, whose extend should be
> preferred (e.g: manipulating the head or a part outside of itself) ?

I'm not sure I understand the issue you raise but so please forgive me
if I've misunderstood:

Presumably you don't have an issue with multiple abstract methods in
Java classes? As Java and Wicket only support single inheritance there
is no issue as to which base class/page child section is being extended
in a derived class/page (that only ever happens in a multiple
inheritance paradigm and no one is proposing we go down that path!) -
the identifier of an implements in a derived page will only ever resolve
to a single abstract tag in a base page. There's no confusion here I
don't believe.

In Java you name methods carefully and appropriately and the compiler
warns you if you have duplicated a function signature. Same would happen
in wicket.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org

Re: Multiple tags on a single base page?

Posted by Korbinian Bachl <ko...@whiskyworld.de>.

 > Given these subtle problems with this approach, I admit I'm warming to
 > the multiple extend/child idea.

im oposite - if i have X extends in a page, whose extend should be 
preferred (e.g: manipulating the head or a part outside of itself) ?

my override of onBeforeRender is secure from your point and IMHO more 
easy...

John Krasnay schrieb:
> On Wed, Nov 07, 2007 at 11:31:12AM +0100, Mats Norén wrote:
>> Is the above statement really true considering that by adding abstract
>> methods to your page you defer the creation of the markup in just the
>> same way as the new proposed solution?
>>
>> BasePage.java
>>
>> public BasePage() {
>>     addAbstract1("abstractId1");
>>     addAbstract2("abstractId2);
>> }
>>
>> public abstract addAbstract1(String abstractId1);
>> public abstract addAbstract2(String abstractId2);
>>
>>
>> BasePage.html
>>
>> <span wicket:id="abstractId1"/>
>> <span wicket:id="abstractId2"/>
>>
>> What is the difference between that and doing abstract / implements?
> 
> You've just illustrated one of the major problems with the
> panel-from-a-subclass approach: it's easy to get it wrong. In your
> example, addAbstract1 and addAbstract2 will be called in a class whose
> constructor has not yet been called. Consider:
> 
> public DerivedPage extends BasePage {
> 
>     private String name;
> 
>     public DerivedPage(String name) {
>         super();
>         this.name = name;
>     }
> 
>     public abstract addAbstract1(String abstractId1) {
>         add(new NamePanel(abstractId1, name));
>     }
> }
> 
> This code is broken, since you're constructing NamePanel before name has
> been initialized. Someone later in this thread shows a better way to do
> this, by calling the overridable methods from onBeforeRender. But this
> is also tricky; because onBeforeRender can be called multiple times you
> must maintain a flag to ensure you only add your panels once.
> 
> Given these subtle problems with this approach, I admit I'm warming to
> the multiple extend/child idea.
> 
> jk
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
> 
> 
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org

Re: Multiple tags on a single base page?

Posted by Korbinian Bachl <ko...@whiskyworld.de>.

Hi Chris,

i rewinded some part of your idea and the thread and now see bit clearer 
what you want - perhaps you shouldnt call i multiple extend/child but 
more precisely "inheritance with multiple areas" as you go:

html-basepage:

...
<extend id="foo" />
....
<extend id="faa" />
....
<wicket:child/>
....

while each those areas are then subsidarily taken over by 1 single 
extended specialised class - so you somehow do nearly the same what I 
did but put the abstract part into the HTML part... is this right?

If im right with this then its IMHO a bit shorter as my way, but on the 
tradeoff that you may get bitten by an HTML-java binding error at 
runtime as well as I still dont know how you want to solve the trouble 
with the name-space (the thing Igor mentioned)

However, i know how hard the first steps in these directions are as i 
went through them by my own... now, after im not more so focused on a 
traditional way of doing webapps i often see things a different way - 
e.g.: I even like Model's now, which also caused me much headache at the 
first time

Best,

Korbinian

Chris Colman schrieb:
>> Chris Colman schrieb:
>>> The beauty of the multiple extend/child idea is that it's not a
>>> completely new concept we're talking about here - it's merely an
> issue
>>> of supporting n>1 instead of arbitrarily fixing n=1 like it is now.
>> 1 Question: Who dominates Who and Why?
>>
>> If you extend 1 class by class you create specialisations that
> dominate
>> each other, but here you just mess together some classes - so why
> should
>> which class dominate? If we manipulate a headertag? If we have same
>> namespace? If we have different securitylevels? Wich class is
>> responsible for all this? Why?
> 
> Dunno what you mean by "dominate" or "mess together some classes". No
> one is talking about mess - the whole point of this feature is avoidance
> of mess - in the same way OO brings about reduced complexity in code the
> same thing can happen with markup.
> 
> We're not proposing multiple inheritance - which indeed causes mess.
> We're talking single inheritance which means single lineage. Each page
> only has a single base page. It's easy for Wicket to perform the
> resolutions and merge markup from base and derived pages.
> 
> I know this because it already does it and it works fine. We're just
> proposing to remove the restriction that it can only do it for just one
> section of your base page - that's all, nothing revolutionary - just
> evolutionary.
> 
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org

RE: Multiple tags on a single base page?

Posted by Chris Colman <ch...@stepaheadsoftware.com>.

> Chris Colman schrieb:
> > The beauty of the multiple extend/child idea is that it's not a
> > completely new concept we're talking about here - it's merely an
issue
> > of supporting n>1 instead of arbitrarily fixing n=1 like it is now.
> 
> 1 Question: Who dominates Who and Why?
> 
> If you extend 1 class by class you create specialisations that
dominate
> each other, but here you just mess together some classes - so why
should
> which class dominate? If we manipulate a headertag? If we have same
> namespace? If we have different securitylevels? Wich class is
> responsible for all this? Why?

Dunno what you mean by "dominate" or "mess together some classes". No
one is talking about mess - the whole point of this feature is avoidance
of mess - in the same way OO brings about reduced complexity in code the
same thing can happen with markup.

We're not proposing multiple inheritance - which indeed causes mess.
We're talking single inheritance which means single lineage. Each page
only has a single base page. It's easy for Wicket to perform the
resolutions and merge markup from base and derived pages.

I know this because it already does it and it works fine. We're just
proposing to remove the restriction that it can only do it for just one
section of your base page - that's all, nothing revolutionary - just
evolutionary.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org

Re: Multiple tags on a single base page?

Posted by Korbinian Bachl <ko...@whiskyworld.de>.


Chris Colman schrieb:
> The beauty of the multiple extend/child idea is that it's not a
> completely new concept we're talking about here - it's merely an issue
> of supporting n>1 instead of arbitrarily fixing n=1 like it is now.

1 Question: Who dominates Who and Why?

If you extend 1 class by class you create specialisations that dominate 
each other, but here you just mess together some classes - so why should 
which class dominate? If we manipulate a headertag? If we have same 
namespace? If we have different securitylevels? Wich class is 
responsible for all this? Why?


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org

RE: Multiple tags on a single base page?

Posted by Chris Colman <ch...@stepaheadsoftware.com>.

> public DerivedPage extends BasePage {
> 
>     private String name;
> 
>     public DerivedPage(String name) {
>         super();
>         this.name = name;
>     }
> 
>     public abstract addAbstract1(String abstractId1) {
>         add(new NamePanel(abstractId1, name));
>     }
> }
> 
> This code is broken, since you're constructing NamePanel before name
has
> been initialized. Someone later in this thread shows a better way to
do
> this, by calling the overridable methods from onBeforeRender. But this
> is also tricky; because onBeforeRender can be called multiple times
you
> must maintain a flag to ensure you only add your panels once.
> 
> Given these subtle problems with this approach, I admit I'm warming to
> the multiple extend/child idea.

Good to hear!! Multiple abstract/implements (child/extends) lets us
avoid the ugly plumbing code suggested in previous posts as an
alternative. I'd rather extend an elegant existing feature with
multiplicity than have to add low level plumbing code to my apps that
assumes a knowledge of the lifecycle methods (eg., onBeforeRender -
never needed to override that method for anything else before now) and
requires me to hook in to the lifecycle at various obscure places like
suggested. I think this goes against the wicket's simplicity motto way
more than supporting multiple child/extends sections does.

The beauty of the multiple extend/child idea is that it's not a
completely new concept we're talking about here - it's merely an issue
of supporting n>1 instead of arbitrarily fixing n=1 like it is now.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org

Re: Multiple tags on a single base page?

Posted by John Krasnay <jo...@krasnay.ca>.

On Wed, Nov 07, 2007 at 11:31:12AM +0100, Mats Norén wrote:
> 
> Is the above statement really true considering that by adding abstract
> methods to your page you defer the creation of the markup in just the
> same way as the new proposed solution?
> 
> BasePage.java
> 
> public BasePage() {
>     addAbstract1("abstractId1");
>     addAbstract2("abstractId2);
> }
> 
> public abstract addAbstract1(String abstractId1);
> public abstract addAbstract2(String abstractId2);
> 
> 
> BasePage.html
> 
> <span wicket:id="abstractId1"/>
> <span wicket:id="abstractId2"/>
> 
> What is the difference between that and doing abstract / implements?

You've just illustrated one of the major problems with the
panel-from-a-subclass approach: it's easy to get it wrong. In your
example, addAbstract1 and addAbstract2 will be called in a class whose
constructor has not yet been called. Consider:

public DerivedPage extends BasePage {

    private String name;

    public DerivedPage(String name) {
        super();
        this.name = name;
    }

    public abstract addAbstract1(String abstractId1) {
        add(new NamePanel(abstractId1, name));
    }
}

This code is broken, since you're constructing NamePanel before name has
been initialized. Someone later in this thread shows a better way to do
this, by calling the overridable methods from onBeforeRender. But this
is also tricky; because onBeforeRender can be called multiple times you
must maintain a flag to ensure you only add your panels once.

Given these subtle problems with this approach, I admit I'm warming to
the multiple extend/child idea.

jk

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org

Re: Multiple tags on a single base page?

Posted by Mats Norén <ma...@gmail.com>.

Hmm...I'm interested in seeing the difference as well. I would love to
get it but right now I don't.

Chris Colman wrote:
"This new feature, or extension of the exiting feature, allows more than
one section of markup to be "specialized" by derived (extended) markups
whereas currently wicket only supports the deferred
definition/implementation of a single markup section in any page. In
other words we want to make a powerful feature even more powerful."

Is the above statement really true considering that by adding abstract
methods to your page you defer the creation of the markup in just the
same way as the new proposed solution?

BasePage.java

public BasePage() {
    addAbstract1("abstractId1");
    addAbstract2("abstractId2);
}

public abstract addAbstract1(String abstractId1);
public abstract addAbstract2(String abstractId2);

BasePage.html

<span wicket:id="abstractId1"/>
<span wicket:id="abstractId2"/>

What is the difference between that and doing abstract / implements?

Each page inheriting from BasePage can choose to be as abstract or as
concrete as it wants.
Chris, I feel like I'm missing something vital here....can you try to
explain it just one more time?

/Regards Mats

On Nov 7, 2007 11:11 AM, Johan Compagner <jc...@gmail.com> wrote:
> ok tell me with 2 examples what is soo different about having 2 panels (or
> fragments)
> in a page and implement that in a sub page or having 2 wicket childs in a
> page
> and implement those in a sub page.
>
> A basepage can also have ofcourse an extend area and 2 panels..
>
> johan
>
>
>
>
> On 11/7/07, Chris Colman <ch...@stepaheadsoftware.com> wrote:
> >
> > > > Wouldn't this essentially be the same as using <wicket:panel
> > > > id="header"/> and using WebMarkupContainers on the java side?
> > >
> > >
> > > yes it would be exactly the same thing.
> >
> > If you think that these are the same then you've missed some vital plot
> > points of the movie that it child/extend.
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > For additional commands, e-mail: users-help@wicket.apache.org
> >
> >
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org

Re: Multiple tags on a single base page?

Posted by Stefan Fußenegger <st...@gmx.at>.

The proposed extension would just lead to more convenience, as it saves us
from having to create child pages as page/panel pairs when their are 2
panels needed (assuming no inheritance at all)




John Krasnay wrote:
> 
> On Tue, Nov 06, 2007 at 10:23:26PM +1100, Chris Colman wrote:
>> 
>> In the panel example you give you must still provide all of the
>> structural markup surrounding your panel tags in EVERY page's markup in
>> your system and if you decide to make a system wide change of this
>> structural markup you must edit every page's markup to reflect that
>> change. In an OO markup world you provide the structural markup in as
> 
> Huh? Why wouldn't the structural markup be inherited by child pages?
> 
> To my mind, wicket:extend/wicket:child is just a convenience feature, to
> save us from having to create child pages as page/panel pairs.
> 
> jk
> 
> ---------------------------------------------------------------------
> 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/Multiple-%3Cwicket%3Achild--%3E-tags-on-a-single-base-page--tf4738673.html#a13609607
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: Multiple tags on a single base page?

Posted by John Krasnay <jo...@krasnay.ca>.

On Tue, Nov 06, 2007 at 10:23:26PM +1100, Chris Colman wrote:
> 
> In the panel example you give you must still provide all of the
> structural markup surrounding your panel tags in EVERY page's markup in
> your system and if you decide to make a system wide change of this
> structural markup you must edit every page's markup to reflect that
> change. In an OO markup world you provide the structural markup in as

Huh? Why wouldn't the structural markup be inherited by child pages?

To my mind, wicket:extend/wicket:child is just a convenience feature, to
save us from having to create child pages as page/panel pairs.

jk

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org

RE: Multiple tags on a single base page?

Posted by Chris Colman <ch...@stepaheadsoftware.com>.

> ok tell me with 2 examples what is soo different about having 2 panels
(or
> fragments)
> in a page and implement that in a sub page or having 2 wicket childs
in a
> page and implement those in a sub page.

Ok, here we go... (well one example at least - it's getting late here ;)
) 

I'm not sure what angle you're coming from: there seems to be two things
to argue about here:

1) the value of markup inheritance as facilitated by the ability to
"override" or "defer implementation" of a single section of a base page,
via the existing child/extends tags, to a sub page's markup.

2) the multiplicity of overridden sections (ie., allowing more than one)

The first point is easy to argue for - if you don't have an <extends>
tag in a page then that page, when rendered, uses ALL of the markup of
that page - it does not merge any markup with a base page. In other
words, you need to set up the structural markup around your panels etc.,
identically in every page if you want to have the same look and feel
across your whole site. If you change the structure of your page you
need to edit EVERY page... nasty!

If you do have a <child> tag in your base page and <extend> in sub pages
then wicket works in a much more clever and powerful way: the whole of
the base page markup, except for the <child> section is "merged in" when
rendering the sub page. In other words - all subpages share the same
structural markup surrounding the <child> section. This is very powerful
and it's exactly the same concept that's been used in OO languages for
the last 20 years. The sub pages have a chance to "specialize" the
appearance of the page, albeit (currently) in only one section.

No OO language limits the number of methods that can be "specialized" in
a sub class to just one method - it would be very restrictive, would
make no sense and there would be no logic in such a limitation.

In the same way there is no logical reason why the number of
"specialized" sections in sub pages in wicket should be limited to just
one.

What Stefan has brilliantly done is created a wicket patch that does
away with this unnecessary limitation of only one specialized section
per page.
 
So if you already use and see the value in the child/extend take then
support for Multiple "specialized" sections per page is just a simple
multiplicity argument. Do you ever find yourself creating more than one
overridden method in a Java class? Well then you'll probably feel the
urge to do the same in markup now once you grasp the power of markup
inheritance.

For those wanting an example I'm not a graphic artist, but a developer,
so naturally I used a software modeling/coding tool to illustrate an
example of how such multiplicity is useful:

The picture is a .vcm model (3kb zipped) and is downloaded from: 

http://www.stepaheadsoftware.com/products/javelin/examples/multipleSpeci
alizedSections.zip

You can use freeware version (1.3MB) of the Javelin modeling tool to
view it, which can be downloaded from:

http://www.stepaheadsoftware.com/products/javelin/javelind.htm


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org

Re: Multiple tags on a single base page?

Posted by Johan Compagner <jc...@gmail.com>.

ok tell me with 2 examples what is soo different about having 2 panels (or
fragments)
in a page and implement that in a sub page or having 2 wicket childs in a
page
and implement those in a sub page.

A basepage can also have ofcourse an extend area and 2 panels..

johan

On 11/7/07, Chris Colman <ch...@stepaheadsoftware.com> wrote:
>
> > > Wouldn't this essentially be the same as using <wicket:panel
> > > id="header"/> and using WebMarkupContainers on the java side?
> >
> >
> > yes it would be exactly the same thing.
>
> If you think that these are the same then you've missed some vital plot
> points of the movie that it child/extend.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>

RE: Multiple tags on a single base page?

Posted by Chris Colman <ch...@stepaheadsoftware.com>.

> > Wouldn't this essentially be the same as using <wicket:panel
> > id="header"/> and using WebMarkupContainers on the java side?
> 
> 
> yes it would be exactly the same thing.

If you think that these are the same then you've missed some vital plot
points of the movie that it child/extend.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org

Re: Multiple tags on a single base page?

Posted by Johan Compagner <jc...@gmail.com>.

>
> Wouldn't this essentially be the same as using <wicket:panel
> id="header"/> and using WebMarkupContainers on the java side?



yes it would be exactly the same thing.

RE: Multiple tags on a single base page?

Posted by Stefan Fußenegger <st...@gmx.at>.

thanks!

I think people become accustomed to how they used wicket up to now.
Therefore, they don't see this "weakness" as they worked around it countless
times. However, "never change a running system" isn't an argument to me ...
and it wasn't to the first guy who said that the wheel should be round ;)


Chris Colman wrote:
> 
>> Hey Chris, I would need some lobbying here! ;)
>> 
>> -- stefan
> 
> You're doing a great job Stefan - especially now I see that you've
> implemented it - excellent job!
> 
> Are we both seeing something here that other people can't see? It wouldn't
> be the first time in my life I was in that position - only years later do
> people go "oh yeah" what a great idea...
> 
> I can only guess that most people haven't actually discovered the power
> and reuse facilitated by the child/extend tag because if they had then
> it's not such a great stretch to see the power of supporting more than one
> extendible section - we're just arguing over multiplicity, not the
> extendible section concept itself.
> 
> Most of the "panels can do that" arguments, in my mind, disparage the
> existing child/extend concept as much as they do the proposed support for
> multiple single extendible sections.
> 
> The, "I can do that with panels" argument sounds like C programmers back
> in the early 90s saying, "I don't need C++ I can do everything in C with
> function pointers". Well you probably could but by embarking on a short
> learning curve you could be 1000x times more productive.
> 
> Someone asked for another explanation of the difference so I'll do that
> again in a following post.
> 
>> 
>> 
>> 
>> Chris Colman wrote:
>> >
>> >> Wouldn't this essentially be the same as using <wicket:panel
>> >> id="header"/> and using WebMarkupContainers on the java side?
>> >> I.e.:
>> >>
>> >> Base
>> >> ----
>> >
>> > Structural markup goes here (see below for explanation of this)
>> >
>> >> <wicket:panel id=header />
>> >
>> > More structural markup goes here
>> >
>> >> <wicket:panel id=body />
>> >
>> > And again more structural markup goes here too
>> >
>> >>
>> >> PumpsBase
>> >> ---------
>> >> <wicket:panel id=header>
>> >>     A header for all pages to do with pumps
>> >> </wicket:panel>
>> >>
>> >> Note: no body implemented here - deferred until a more specialized
>> >> class/markups: WaterPumpsBase and OilPumpsBase
>> >>
>> >> WaterPumpBase
>> >> -------------
>> >> Note: no header implemented here - the general PumpsBase one suffices
>> >> for all pumps pages
>> >>
>> >> <wicket:panel id=body>
>> >>     A body discussing water pumps
>> >> </wicket:panel>
>> >>
>> > ...
>> >
>> >>
>> >> On the java side you'd have to addOrReplace(new
>> >> WebMarkupContainer("header")) but it's essentially the same. Or am I
>> >> missing some point?
>> >
>> > This is indeed very different. If it were not so then the wicket
>> > developers would never have conceived the need for the current
>> > child/extend tag pair.
>> >
>> > The power of inheritance at the markup level is that you can define
>> > markup once in a base markup file that is inherited by all derived
>> > markup files. The derived markup files only supply sections that
>> provide
>> > "specialized sections of markup - the rest, at render time, comes from
>> > the base class.
>> >
>> > You would typically use components (panels) within these specialized
>> > sections but using the panel mechanism as you describe above as a
>> > replacement for the powerful markup inheritance feature of wicket is
>> not
>> > possible.
>> >
>> > In the panel example you give you must still provide all of the
>> > structural markup surrounding your panel tags in EVERY page's markup in
>> > your system and if you decide to make a system wide change of this
>> > structural markup you must edit every page's markup to reflect that
>> > change. In an OO markup world you provide the structural markup in as
>> > many pages as you want but at render time the only structural markup
>> > used is that provided in the base base - which is very powerful because
>> > you can make system wide changes by modifying only that single base
>> > page's markup. Wicket is the first framework I've seen that allows
>> > proper OO reuse concepts at the markup level.
>> >
>> > This is what many people wicket developers with an OO wiring in their
>> > brain are doing right now with the existing child/extend feature - and
>> > to great benefit.
>> >
>> > This new feature, or extension of the exiting feature, allows more than
>> > one section of markup to be "specialized" by derived (extended) markups
>> > whereas currently wicket only supports the deferred
>> > definition/implementation of a single markup section in any page. In
>> > other words we want to make a powerful feature even more powerful.
>> >
>> > It must be stated again (for the benefit of those who have just
>> recently
>> > joined this thread) that supporting multiple sections whose
>> > implementation can be deferred to extended markups does not equate to
>> > multiple inheritance (a big "no no" in the OO world). Multiple
>> > overridden sections is analogous to the support of multiple abstract
>> > methods whose implementations are provided in classes that extend the
>> > base class - which is supported in all good OO languages, including
>> > Java.
>> >
>> > ---------------------------------------------------------------------
>> > 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/Multiple-
>> %3Cwicket%3Achild--%3E-tags-on-a-single-base-page--
>> tf4738673.html#a13623108
>> 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
> 
> 
> ---------------------------------------------------------------------
> 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/Multiple-%3Cwicket%3Achild--%3E-tags-on-a-single-base-page--tf4738673.html#a13626128
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: Multiple tags on a single base page?

Posted by Chris Colman <ch...@stepaheadsoftware.com>.

> Hey Chris, I would need some lobbying here! ;)
> 
> -- stefan

You're doing a great job Stefan - especially now I see that you've implemented it - excellent job!

Are we both seeing something here that other people can't see? It wouldn't be the first time in my life I was in that position - only years later do people go "oh yeah" what a great idea...

I can only guess that most people haven't actually discovered the power and reuse facilitated by the child/extend tag because if they had then it's not such a great stretch to see the power of supporting more than one extendible section - we're just arguing over multiplicity, not the extendible section concept itself.

Most of the "panels can do that" arguments, in my mind, disparage the existing child/extend concept as much as they do the proposed support for multiple single extendible sections.

The, "I can do that with panels" argument sounds like C programmers back in the early 90s saying, "I don't need C++ I can do everything in C with function pointers". Well you probably could but by embarking on a short learning curve you could be 1000x times more productive.

Someone asked for another explanation of the difference so I'll do that again in a following post.

> 
> 
> 
> Chris Colman wrote:
> >
> >> Wouldn't this essentially be the same as using <wicket:panel
> >> id="header"/> and using WebMarkupContainers on the java side?
> >> I.e.:
> >>
> >> Base
> >> ----
> >
> > Structural markup goes here (see below for explanation of this)
> >
> >> <wicket:panel id=header />
> >
> > More structural markup goes here
> >
> >> <wicket:panel id=body />
> >
> > And again more structural markup goes here too
> >
> >>
> >> PumpsBase
> >> ---------
> >> <wicket:panel id=header>
> >>     A header for all pages to do with pumps
> >> </wicket:panel>
> >>
> >> Note: no body implemented here - deferred until a more specialized
> >> class/markups: WaterPumpsBase and OilPumpsBase
> >>
> >> WaterPumpBase
> >> -------------
> >> Note: no header implemented here - the general PumpsBase one suffices
> >> for all pumps pages
> >>
> >> <wicket:panel id=body>
> >>     A body discussing water pumps
> >> </wicket:panel>
> >>
> > ...
> >
> >>
> >> On the java side you'd have to addOrReplace(new
> >> WebMarkupContainer("header")) but it's essentially the same. Or am I
> >> missing some point?
> >
> > This is indeed very different. If it were not so then the wicket
> > developers would never have conceived the need for the current
> > child/extend tag pair.
> >
> > The power of inheritance at the markup level is that you can define
> > markup once in a base markup file that is inherited by all derived
> > markup files. The derived markup files only supply sections that provide
> > "specialized sections of markup - the rest, at render time, comes from
> > the base class.
> >
> > You would typically use components (panels) within these specialized
> > sections but using the panel mechanism as you describe above as a
> > replacement for the powerful markup inheritance feature of wicket is not
> > possible.
> >
> > In the panel example you give you must still provide all of the
> > structural markup surrounding your panel tags in EVERY page's markup in
> > your system and if you decide to make a system wide change of this
> > structural markup you must edit every page's markup to reflect that
> > change. In an OO markup world you provide the structural markup in as
> > many pages as you want but at render time the only structural markup
> > used is that provided in the base base - which is very powerful because
> > you can make system wide changes by modifying only that single base
> > page's markup. Wicket is the first framework I've seen that allows
> > proper OO reuse concepts at the markup level.
> >
> > This is what many people wicket developers with an OO wiring in their
> > brain are doing right now with the existing child/extend feature - and
> > to great benefit.
> >
> > This new feature, or extension of the exiting feature, allows more than
> > one section of markup to be "specialized" by derived (extended) markups
> > whereas currently wicket only supports the deferred
> > definition/implementation of a single markup section in any page. In
> > other words we want to make a powerful feature even more powerful.
> >
> > It must be stated again (for the benefit of those who have just recently
> > joined this thread) that supporting multiple sections whose
> > implementation can be deferred to extended markups does not equate to
> > multiple inheritance (a big "no no" in the OO world). Multiple
> > overridden sections is analogous to the support of multiple abstract
> > methods whose implementations are provided in classes that extend the
> > base class - which is supported in all good OO languages, including
> > Java.
> >
> > ---------------------------------------------------------------------
> > 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/Multiple-
> %3Cwicket%3Achild--%3E-tags-on-a-single-base-page--
> tf4738673.html#a13623108
> 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


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org

RE: Multiple tags on a single base page?

Posted by Stefan Fußenegger <st...@gmx.at>.

Hey Chris, I would need some lobbying here! ;)

-- stefan



Chris Colman wrote:
> 
>> Wouldn't this essentially be the same as using <wicket:panel
>> id="header"/> and using WebMarkupContainers on the java side?
>> I.e.:
>> 
>> Base
>> ----
> 
> Structural markup goes here (see below for explanation of this)
> 
>> <wicket:panel id=header />
> 
> More structural markup goes here
> 
>> <wicket:panel id=body />
> 
> And again more structural markup goes here too
> 
>> 
>> PumpsBase
>> ---------
>> <wicket:panel id=header>
>>     A header for all pages to do with pumps
>> </wicket:panel>
>> 
>> Note: no body implemented here - deferred until a more specialized
>> class/markups: WaterPumpsBase and OilPumpsBase
>> 
>> WaterPumpBase
>> -------------
>> Note: no header implemented here - the general PumpsBase one suffices
>> for all pumps pages
>> 
>> <wicket:panel id=body>
>>     A body discussing water pumps
>> </wicket:panel>
>> 
> ...
> 
>> 
>> On the java side you'd have to addOrReplace(new
>> WebMarkupContainer("header")) but it's essentially the same. Or am I
>> missing some point?
> 
> This is indeed very different. If it were not so then the wicket
> developers would never have conceived the need for the current
> child/extend tag pair.
> 
> The power of inheritance at the markup level is that you can define
> markup once in a base markup file that is inherited by all derived
> markup files. The derived markup files only supply sections that provide
> "specialized sections of markup - the rest, at render time, comes from
> the base class.
> 
> You would typically use components (panels) within these specialized
> sections but using the panel mechanism as you describe above as a
> replacement for the powerful markup inheritance feature of wicket is not
> possible.
> 
> In the panel example you give you must still provide all of the
> structural markup surrounding your panel tags in EVERY page's markup in
> your system and if you decide to make a system wide change of this
> structural markup you must edit every page's markup to reflect that
> change. In an OO markup world you provide the structural markup in as
> many pages as you want but at render time the only structural markup
> used is that provided in the base base - which is very powerful because
> you can make system wide changes by modifying only that single base
> page's markup. Wicket is the first framework I've seen that allows
> proper OO reuse concepts at the markup level.
> 
> This is what many people wicket developers with an OO wiring in their
> brain are doing right now with the existing child/extend feature - and
> to great benefit.
> 
> This new feature, or extension of the exiting feature, allows more than
> one section of markup to be "specialized" by derived (extended) markups
> whereas currently wicket only supports the deferred
> definition/implementation of a single markup section in any page. In
> other words we want to make a powerful feature even more powerful. 
> 
> It must be stated again (for the benefit of those who have just recently
> joined this thread) that supporting multiple sections whose
> implementation can be deferred to extended markups does not equate to
> multiple inheritance (a big "no no" in the OO world). Multiple
> overridden sections is analogous to the support of multiple abstract
> methods whose implementations are provided in classes that extend the
> base class - which is supported in all good OO languages, including
> Java.
> 
> ---------------------------------------------------------------------
> 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/Multiple-%3Cwicket%3Achild--%3E-tags-on-a-single-base-page--tf4738673.html#a13623108
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: Multiple tags on a single base page?

Posted by Chris Colman <ch...@stepaheadsoftware.com>.

> Wouldn't this essentially be the same as using <wicket:panel
> id="header"/> and using WebMarkupContainers on the java side?
> I.e.:
> 
> Base
> ----

Structural markup goes here (see below for explanation of this)

> <wicket:panel id=header />

More structural markup goes here

> <wicket:panel id=body />

And again more structural markup goes here too

> 
> PumpsBase
> ---------
> <wicket:panel id=header>
>     A header for all pages to do with pumps
> </wicket:panel>
> 
> Note: no body implemented here - deferred until a more specialized
> class/markups: WaterPumpsBase and OilPumpsBase
> 
> WaterPumpBase
> -------------
> Note: no header implemented here - the general PumpsBase one suffices
> for all pumps pages
> 
> <wicket:panel id=body>
>     A body discussing water pumps
> </wicket:panel>
> 
...

> 
> On the java side you'd have to addOrReplace(new
> WebMarkupContainer("header")) but it's essentially the same. Or am I
> missing some point?

This is indeed very different. If it were not so then the wicket
developers would never have conceived the need for the current
child/extend tag pair.

The power of inheritance at the markup level is that you can define
markup once in a base markup file that is inherited by all derived
markup files. The derived markup files only supply sections that provide
"specialized sections of markup - the rest, at render time, comes from
the base class.

You would typically use components (panels) within these specialized
sections but using the panel mechanism as you describe above as a
replacement for the powerful markup inheritance feature of wicket is not
possible.

In the panel example you give you must still provide all of the
structural markup surrounding your panel tags in EVERY page's markup in
your system and if you decide to make a system wide change of this
structural markup you must edit every page's markup to reflect that
change. In an OO markup world you provide the structural markup in as
many pages as you want but at render time the only structural markup
used is that provided in the base base - which is very powerful because
you can make system wide changes by modifying only that single base
page's markup. Wicket is the first framework I've seen that allows
proper OO reuse concepts at the markup level.

This is what many people wicket developers with an OO wiring in their
brain are doing right now with the existing child/extend feature - and
to great benefit.

This new feature, or extension of the exiting feature, allows more than
one section of markup to be "specialized" by derived (extended) markups
whereas currently wicket only supports the deferred
definition/implementation of a single markup section in any page. In
other words we want to make a powerful feature even more powerful. 

It must be stated again (for the benefit of those who have just recently
joined this thread) that supporting multiple sections whose
implementation can be deferred to extended markups does not equate to
multiple inheritance (a big "no no" in the OO world). Multiple
overridden sections is analogous to the support of multiple abstract
methods whose implementations are provided in classes that extend the
base class - which is supported in all good OO languages, including
Java.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org

Re: Multiple tags on a single base page?

Posted by Matthijs Wensveen <m....@func.nl>.

> Yes Stefan, I would think that would be a better approach to use a new set of tags. It also allows you to choose more correct naming (because inheritance isn't actually a parent/child relationship so the word child just confuses the issue).
>
> Maybe wicket:abstract in the base and wicket:implements (nice - thanks to whoever suggested that) or wicket:override in the derived (extended) markup.
>
> I think using IDs up front would also be great, if not necessary, because in Java as would probably occur in wicket mark up, you can have intermediate classes that don't implement all abstract methods in a base class. Without IDs you won't know exactly which abstract method an intermediate class is implementing.
>
> This example hopefully demonstrates what I mean:
>
> Base
> ----
> <wicket:abstract id=header />
> <wicket:abstract id=body />
>
> PumpsBase
> ---------
> <wicket:implements id=header>
> 	A header for all pages to do with pumps
> </wicket:implements>
>
> Note: no body implemented here - deferred until a more specialized class/markups: WaterPumpsBase and OilPumpsBase
>
> WaterPumpBase
> -------------
> Note: no header implemented here - the general PumpsBase one suffices for all pumps pages
>
> <wicket:implements id=body>
> 	A body discussing water pumps
> </wicket:implements>
>
>
> OilPumpBase
> -----------
> Note: no header implemented here - the general PumpsBase one suffices for all pumps pages
>
> <wicket:implements id=body>
> 	A body discussing oil pumps
> </wicket:implements>
>
>
> I think the tag pairs abstract/implements flow much better from an OO perspective than child/extends. It hurts my brain way to much to think of a base class as a child.
>
>   
Wouldn't this essentially be the same as using <wicket:panel 
id="header"/> and using WebMarkupContainers on the java side?
I.e.:

Base
----
<wicket:panel id=header />
<wicket:panel id=body />

PumpsBase
---------
<wicket:panel id=header>
    A header for all pages to do with pumps
</wicket:panel>

Note: no body implemented here - deferred until a more specialized 
class/markups: WaterPumpsBase and OilPumpsBase

WaterPumpBase
-------------
Note: no header implemented here - the general PumpsBase one suffices 
for all pumps pages

<wicket:panel id=body>
    A body discussing water pumps
</wicket:panel>


OilPumpBase
-----------
Note: no header implemented here - the general PumpsBase one suffices 
for all pumps pages

<wicket:panel id=body>
    A body discussing oil pumps
</wicket:panel>

On the java side you'd have to addOrReplace(new 
WebMarkupContainer("header")) but it's essentially the same. Or am I 
missing some point?

I think the power of wicket lies in its component-based approach and not 
(necessarily) in its OO features.

Matthijs

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org

RE: Multiple tags on a single base page?

Posted by Stefan Fußenegger <st...@gmx.at>.

Don't worry, I won't change the old stuff. I just wanted to say that it would
have been nice to just override some methods of the old class to change its
behaviour. Now, I ended up duplicating most of the old 270-line method into
a bunch of smaller methods for better extensibility.

I won't use child as an alias, as this would probably change too much of the
old implementation. But yes, it is possible to just rename child to abstract
and extend to implement without giving any IDs as null is a valid one (so
using it as an alias would be possible if needed/wanted).

To give a short progress report: I am halfway there ;)



Chris Colman wrote:
> 
>> I totally agree with you, having named extension points would be perfect.
>> However, I am trying to do a quick proof of concept that can be discussed
>> before I implement all those nice and shiny features. Hopefully this
>> prototype convinces some of those sceptics out there ;)
> 
> I think the anyone who understands how Java supports multiple abstract
> methods without supporting multiple inheritance should be convinced. If it
> makes sense for OO languages to support multiple overriddable abstract
> methods why should wicket be limited to only a single overridable markup
> section?
> 
>> I already figured out how to implement this change. Basically, it's only
>> a
>> single method (MergedMarkup.merge(...)) to change ... but this method has
>> 275 lines and needs *major* refactoring ... damn.
> 
> Doh! I reckon you'll have more success adding a completely new tag set
> because touching the old one get people worried that it might break. If
> you have a new tag set you are free to define the syntax and behaviour -
> and you have no chance of breaking how the old tag set works. There's
> nothing wrong with two tag sets - especially as the new one can be named
> correctly and will have to support named extension points, eventually.
>  
>> 
>> However, changing the name of the tag (while it would make perfect sense)
>> seems to be more complicated. You would have to make sure, that tags are
>> not
>> mixed up and decide between two different markup-merging-implementations,
>> although one implementation is capable of doing the same as the other one
>> -
>> and more.
> 
> Maybe make 'child' an alias for 'abstract' and 'extends' an alias for
> 'implements' and then use your funky new markup-merging-implementation to
> handle both multiple (if names are provided) and fallback to single (if no
> names are provided) - single is then just an ordinary case of multiple
> where n=1.
> 
>> 
>> However, I'll consider using a different name and separate implementation
>> for the prototype.
>> 
>> -- Stefan
>> 
>> 
>> 
>> Chris Colman wrote:
>> >
>> >> if i were you i would use tags other then extend and child just so you
>> >> dont conflict.
>> >
>> > Yes Stefan, I would think that would be a better approach to use a new
>> set
>> > of tags. It also allows you to choose more correct naming (because
>> > inheritance isn't actually a parent/child relationship so the word
>> child
>> > just confuses the issue).
>> >
>> > Maybe wicket:abstract in the base and wicket:implements (nice - thanks
>> to
>> > whoever suggested that) or wicket:override in the derived (extended)
>> > markup.
>> >
>> > I think using IDs up front would also be great, if not necessary,
>> because
>> > in Java as would probably occur in wicket mark up, you can have
>> > intermediate classes that don't implement all abstract methods in a
>> base
>> > class. Without IDs you won't know exactly which abstract method an
>> > intermediate class is implementing.
>> >
>> > This example hopefully demonstrates what I mean:
>> >
>> > Base
>> > ----
>> > <wicket:abstract id=header />
>> > <wicket:abstract id=body />
>> >
>> > PumpsBase
>> > ---------
>> > <wicket:implements id=header>
>> > 	A header for all pages to do with pumps
>> > </wicket:implements>
>> >
>> > Note: no body implemented here - deferred until a more specialized
>> > class/markups: WaterPumpsBase and OilPumpsBase
>> >
>> > WaterPumpBase
>> > -------------
>> > Note: no header implemented here - the general PumpsBase one suffices
>> for
>> > all pumps pages
>> >
>> > <wicket:implements id=body>
>> > 	A body discussing water pumps
>> > </wicket:implements>
>> >
>> >
>> > OilPumpBase
>> > -----------
>> > Note: no header implemented here - the general PumpsBase one suffices
>> for
>> > all pumps pages
>> >
>> > <wicket:implements id=body>
>> > 	A body discussing oil pumps
>> > </wicket:implements>
>> >
>> >
>> > I think the tag pairs abstract/implements flow much better from an OO
>> > perspective than child/extends. It hurts my brain way to much to think
>> of
>> > a base class as a child.
>> >
>> >>
>> >> -igor
>> >>
>> >>
>> >> On 11/5/07, Stefan Fußenegger <st...@gmx.at> wrote:
>> >> >
>> >> > Well, what I'd like to do is what I explained in my first post. One
>> >> would
>> >> > still have a one-one-relationship if it comes to files (Base.html,
>> >> Base.java
>> >> > - Sub.html, Sub.java). However, a Base.html might contain more than
>> one
>> >> > <wicket:extend />. So this no longer an exact duplicate of the
>> parent-
>> >> child
>> >> > relationship that is already specified by the java class hierarchy.
>> It
>> >> now
>> >> > would be similar to abstract method, where the abstract class
>> specifies
>> >> one
>> >> > or more extension points that are implemented by its subcasses ...
>> >> abstract
>> >> > methods. There isn't a restriction, that there is only one abstract
>> >> method
>> >> > per class!
>> >> >
>> >> > My proof of concept would go the probably easiest way and just link
>> the
>> >> > first extend with the first child, the second extend with the second
>> >> child,
>> >> > the third ... you got the idea ;) At a later point it might be
>> useful
>> >> to
>> >> > link them using ids (like the names of abstract methods).
>> >> >
>> >> > You could than for instance do some hierarchies like this:
>> >> >
>> >> > BaseClass - Application base class. Navigation on top, two columns
>> with
>> >> > wicket:extend
>> >> > SectionOneBaseClass extends BaseClass - Sub-navigation in left
>> column
>> >> > SectionOneIndex extends SectionOneBaseClass - Navigation on top,
>> >> > sub-navigation in left column and some fancy content in right column
>> >> >
>> >> > I totally agree to anybody who argues that this is already possible
>> by
>> >> other
>> >> > means. However, to me it seems to be the most natural and elegant
>> way
>> >> to
>> >> do
>> >> > this.
>> >> >
>> >> > As I mentioned before, I don't know Wicket's inner workings too
>> much,
>> >> so
>> >> I
>> >> > will definitely need some pointers to the right directions.
>> >> >
>> >> > My naive guess is that Wicket parses BasePage.html and looks for
>> >> > SecionOneBaseClass.html and the first <wicket:child /> as soon as it
>> >> finds a
>> >> > <wicket:extend />. The idea would know be to just add a counter to
>> this
>> >> > call, asking for the second <wicket:child />, rather than the first
>> (I
>> >> doubt
>> >> > that it's really going to be that easy though).
>> >> >
>> >> >
>> >> >
>> >> >
>> >> > Bruno Borges wrote:
>> >> > >
>> >> > > Stefan, try first giving us an example of what would you like to
>> do.
>> >> What
>> >> > > I
>> >> > > can see is that you want this:
>> >> > >
>> >> > > BasePage.html
>> >> > > <html>
>> >> > >   <body>
>> >> > >     <h1>BasePage</h1>
>> >> > >     <hr/>
>> >> > >     <h3>This is my child:</h3>
>> >> > >     <wicket:child />
>> >> > >     <hr/>
>> >> > >     <h3>This is my OTHER child:</h3>
>> >> > >     <wicket:child />
>> >> > >   </body>
>> >> > > </html>
>> >> > >
>> >> > > ** Example of a child page:*
>> >> > > ChildPage.html
>> >> > > <html>
>> >> > >   <body>
>> >> > >     <wicket:extend>
>> >> > >       <h4>ChildPage</h4>
>> >> > >       <h5>I'm your child</h5>
>> >> > >     </wicket:extend>
>> >> > >   </body>
>> >> > > </html>
>> >> > >
>> >> > > Now, given this html, how do you see the Java code structured?
>> What's
>> >> your
>> >> > > vision?
>> >> > >
>> >> > > On Nov 5, 2007 11:28 AM, Stefan Fußenegger
>> >> <st...@gmx.at>
>> >> > > wrote:
>> >> > >
>> >> > >>
>> >> > >>
>> >> > >> Eelco Hillenius wrote:
>> >> > >> >
>> >> > >> >> It would be quite feasible to add support for multiple
>> overridden
>> >> > >> >> sections using the above tag names while remaining backwards
>> >> > >> compatible
>> >> > >> >> with existing markup by continuing to support the old
>> >> <child/extends>
>> >> > >> >> tags working the way they always have.
>> >> > >> >
>> >> > >> > It's kind of a predictable answer, but the best way to push new
>> >> ideas
>> >> > >> > forward is to supply us with a patch, so that we can discuss
>> some
>> >> > >> > working code. The current committers don't see much in the
>> idea,
>> >> but
>> >> > >> > that doesn't mean they wouldn't want to support at least the
>> >> option
>> >> of
>> >> > >> > plugging this in. And hey, maybe some working code convinces us
>> >> :-)
>> >> > >> >
>> >> > >> > Eelco
>> >> > >> >
>> >> > >> >
>> >> -------------------------------------------------------------------
>> >> --
>> >> > >> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> >> > >> > For additional commands, e-mail: users-help@wicket.apache.org
>> >> > >> >
>> >> > >> >
>> >> > >> >
>> >> > >>
>> >> > >> Hi eelco,
>> >> > >>
>> >> > >> I'd love to do a proof of concept here. Admittedly, I don't know
>> >> wicket's
>> >> > >> inner workings very well. But if I get some support, I'd try
>> >> implementing
>> >> > >> this. I am currently looking through the code, but can't find
>> where
>> >> the
>> >> > >> transition between parent and child takes place (in other words:
>> the
>> >> line
>> >> > >> of
>> >> > >> code that recognizes the wicket:extend tag and takes the
>> appropriate
>> >> > >> action). If somebody could point me to that line I would try to
>> >> implement
>> >> > >> this possible new feature ... well, I'll first estimate the time
>> >> > >> necessary
>> >> > >> to do so and see if I can afford it ;)
>> >> > >>
>> >> > >> Regards
>> >> > >>
>> >> > >>
>> >> > >>
>> >> > >> -----
>> >> > >> -------
>> >> > >> Stefan Fußenegger
>> >> > >> http://talk-on-tech.blogspot.com // looking for a nicer domain ;)
>> >> > >> --
>> >> > >> View this message in context:
>> >> > >> http://www.nabble.com/Multiple-%3Cwicket%3Achild--%3E-tags-on-a-
>> >> single-base-page--tf4738673.html#a13586814
>> >> > >> 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
>> >> > >>
>> >> > >>
>> >> > >
>> >> > >
>> >> > > --
>> >> > > 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/Multiple-
>> >> %3Cwicket%3Achild--%3E-tags-on-a-single-base-page--
>> >> tf4738673.html#a13587701
>> >> > 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
>> >> >
>> >> >
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> >> For additional commands, e-mail: users-help@wicket.apache.org
>> >
>> >
>> > ---------------------------------------------------------------------
>> > 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/Multiple-
>> %3Cwicket%3Achild--%3E-tags-on-a-single-base-page--
>> tf4738673.html#a13597619
>> 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
> 
> 
> ---------------------------------------------------------------------
> 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/Multiple-%3Cwicket%3Achild--%3E-tags-on-a-single-base-page--tf4738673.html#a13605970
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: Multiple tags on a single base page?

Posted by Chris Colman <ch...@stepaheadsoftware.com>.

> Hmmm... more tags? I thought you guys liked Wicket because it's plain
html
> support. Now looks like there's a big interest in having more tags. If
> this is true, why don't we go back a few years, or move to JSF? Let's
give
> Wicket support to Tag Libraries too :)
> 

These aren't just like other tags - not having these is like removing
the abstract keyword from the Java language.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org

Re: Multiple tags on a single base page?

Posted by Bruno Borges <br...@gmail.com>.

Hmmm... more tags? I thought you guys liked Wicket because it's plain html
support. Now looks like there's a big interest in having more tags. If this
is true, why don't we go back a few years, or move to JSF? Let's give Wicket
support to Tag Libraries too :)

For the record, I don't like wicket:enclosure, neither wicket:fragment and
you guys want to put more?
Instead, I prefer new attributes to keep my html plain.

<div wicket:fragment="fragment-id"></div>

Regards,

On Nov 6, 2007 9:35 AM, Chris Colman <ch...@stepaheadsoftware.com> wrote:

> > I totally agree with you, having named extension points would be
> perfect.
> > However, I am trying to do a quick proof of concept that can be
> discussed
> > before I implement all those nice and shiny features. Hopefully this
> > prototype convinces some of those sceptics out there ;)
>
> I think the anyone who understands how Java supports multiple abstract
> methods without supporting multiple inheritance should be convinced. If it
> makes sense for OO languages to support multiple overriddable abstract
> methods why should wicket be limited to only a single overridable markup
> section?
>
> > I already figured out how to implement this change. Basically, it's only
> a
> > single method (MergedMarkup.merge(...)) to change ... but this method
> has
> > 275 lines and needs *major* refactoring ... damn.
>
> Doh! I reckon you'll have more success adding a completely new tag set
> because touching the old one get people worried that it might break. If you
> have a new tag set you are free to define the syntax and behaviour - and you
> have no chance of breaking how the old tag set works. There's nothing wrong
> with two tag sets - especially as the new one can be named correctly and
> will have to support named extension points, eventually.
>
> >
> > However, changing the name of the tag (while it would make perfect
> sense)
> > seems to be more complicated. You would have to make sure, that tags are
> > not
> > mixed up and decide between two different
> markup-merging-implementations,
> > although one implementation is capable of doing the same as the other
> one
> > -
> > and more.
>
> Maybe make 'child' an alias for 'abstract' and 'extends' an alias for
> 'implements' and then use your funky new markup-merging-implementation to
> handle both multiple (if names are provided) and fallback to single (if no
> names are provided) - single is then just an ordinary case of multiple where
> n=1.
>
> >
> > However, I'll consider using a different name and separate
> implementation
> > for the prototype.
> >
> > -- Stefan
> >
> >
> >
> > Chris Colman wrote:
> > >
> > >> if i were you i would use tags other then extend and child just so
> you
> > >> dont conflict.
> > >
> > > Yes Stefan, I would think that would be a better approach to use a new
> > set
> > > of tags. It also allows you to choose more correct naming (because
> > > inheritance isn't actually a parent/child relationship so the word
> child
> > > just confuses the issue).
> > >
> > > Maybe wicket:abstract in the base and wicket:implements (nice - thanks
> > to
> > > whoever suggested that) or wicket:override in the derived (extended)
> > > markup.
> > >
> > > I think using IDs up front would also be great, if not necessary,
> > because
> > > in Java as would probably occur in wicket mark up, you can have
> > > intermediate classes that don't implement all abstract methods in a
> base
> > > class. Without IDs you won't know exactly which abstract method an
> > > intermediate class is implementing.
> > >
> > > This example hopefully demonstrates what I mean:
> > >
> > > Base
> > > ----
> > > <wicket:abstract id=header />
> > > <wicket:abstract id=body />
> > >
> > > PumpsBase
> > > ---------
> > > <wicket:implements id=header>
> > >     A header for all pages to do with pumps
> > > </wicket:implements>
> > >
> > > Note: no body implemented here - deferred until a more specialized
> > > class/markups: WaterPumpsBase and OilPumpsBase
> > >
> > > WaterPumpBase
> > > -------------
> > > Note: no header implemented here - the general PumpsBase one suffices
> > for
> > > all pumps pages
> > >
> > > <wicket:implements id=body>
> > >     A body discussing water pumps
> > > </wicket:implements>
> > >
> > >
> > > OilPumpBase
> > > -----------
> > > Note: no header implemented here - the general PumpsBase one suffices
> > for
> > > all pumps pages
> > >
> > > <wicket:implements id=body>
> > >     A body discussing oil pumps
> > > </wicket:implements>
> > >
> > >
> > > I think the tag pairs abstract/implements flow much better from an OO
> > > perspective than child/extends. It hurts my brain way to much to think
> > of
> > > a base class as a child.
> > >
> > >>
> > >> -igor
> > >>
> > >>
> > >> On 11/5/07, Stefan Fußenegger <st...@gmx.at> wrote:
> > >> >
> > >> > Well, what I'd like to do is what I explained in my first post. One
> > >> would
> > >> > still have a one-one-relationship if it comes to files (Base.html,
> > >> Base.java
> > >> > - Sub.html, Sub.java). However, a Base.html might contain more than
> > one
> > >> > <wicket:extend />. So this no longer an exact duplicate of the
> > parent-
> > >> child
> > >> > relationship that is already specified by the java class hierarchy.
> > It
> > >> now
> > >> > would be similar to abstract method, where the abstract class
> > specifies
> > >> one
> > >> > or more extension points that are implemented by its subcasses ...
> > >> abstract
> > >> > methods. There isn't a restriction, that there is only one abstract
> > >> method
> > >> > per class!
> > >> >
> > >> > My proof of concept would go the probably easiest way and just link
> > the
> > >> > first extend with the first child, the second extend with the
> second
> > >> child,
> > >> > the third ... you got the idea ;) At a later point it might be
> useful
> > >> to
> > >> > link them using ids (like the names of abstract methods).
> > >> >
> > >> > You could than for instance do some hierarchies like this:
> > >> >
> > >> > BaseClass - Application base class. Navigation on top, two columns
> > with
> > >> > wicket:extend
> > >> > SectionOneBaseClass extends BaseClass - Sub-navigation in left
> column
> > >> > SectionOneIndex extends SectionOneBaseClass - Navigation on top,
> > >> > sub-navigation in left column and some fancy content in right
> column
> > >> >
> > >> > I totally agree to anybody who argues that this is already possible
> > by
> > >> other
> > >> > means. However, to me it seems to be the most natural and elegant
> way
> > >> to
> > >> do
> > >> > this.
> > >> >
> > >> > As I mentioned before, I don't know Wicket's inner workings too
> much,
> > >> so
> > >> I
> > >> > will definitely need some pointers to the right directions.
> > >> >
> > >> > My naive guess is that Wicket parses BasePage.html and looks for
> > >> > SecionOneBaseClass.html and the first <wicket:child /> as soon as
> it
> > >> finds a
> > >> > <wicket:extend />. The idea would know be to just add a counter to
> > this
> > >> > call, asking for the second <wicket:child />, rather than the first
> > (I
> > >> doubt
> > >> > that it's really going to be that easy though).
> > >> >
> > >> >
> > >> >
> > >> >
> > >> > Bruno Borges wrote:
> > >> > >
> > >> > > Stefan, try first giving us an example of what would you like to
> > do.
> > >> What
> > >> > > I
> > >> > > can see is that you want this:
> > >> > >
> > >> > > BasePage.html
> > >> > > <html>
> > >> > >   <body>
> > >> > >     <h1>BasePage</h1>
> > >> > >     <hr/>
> > >> > >     <h3>This is my child:</h3>
> > >> > >     <wicket:child />
> > >> > >     <hr/>
> > >> > >     <h3>This is my OTHER child:</h3>
> > >> > >     <wicket:child />
> > >> > >   </body>
> > >> > > </html>
> > >> > >
> > >> > > ** Example of a child page:*
> > >> > > ChildPage.html
> > >> > > <html>
> > >> > >   <body>
> > >> > >     <wicket:extend>
> > >> > >       <h4>ChildPage</h4>
> > >> > >       <h5>I'm your child</h5>
> > >> > >     </wicket:extend>
> > >> > >   </body>
> > >> > > </html>
> > >> > >
> > >> > > Now, given this html, how do you see the Java code structured?
> > What's
> > >> your
> > >> > > vision?
> > >> > >
> > >> > > On Nov 5, 2007 11:28 AM, Stefan Fußenegger
> > >> <st...@gmx.at>
> > >> > > wrote:
> > >> > >
> > >> > >>
> > >> > >>
> > >> > >> Eelco Hillenius wrote:
> > >> > >> >
> > >> > >> >> It would be quite feasible to add support for multiple
> > overridden
> > >> > >> >> sections using the above tag names while remaining backwards
> > >> > >> compatible
> > >> > >> >> with existing markup by continuing to support the old
> > >> <child/extends>
> > >> > >> >> tags working the way they always have.
> > >> > >> >
> > >> > >> > It's kind of a predictable answer, but the best way to push
> new
> > >> ideas
> > >> > >> > forward is to supply us with a patch, so that we can discuss
> > some
> > >> > >> > working code. The current committers don't see much in the
> idea,
> > >> but
> > >> > >> > that doesn't mean they wouldn't want to support at least the
> > >> option
> > >> of
> > >> > >> > plugging this in. And hey, maybe some working code convinces
> us
> > >> :-)
> > >> > >> >
> > >> > >> > Eelco
> > >> > >> >
> > >> > >> >
> > >> -------------------------------------------------------------------
> > >> --
> > >> > >> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > >> > >> > For additional commands, e-mail: users-help@wicket.apache.org
> > >> > >> >
> > >> > >> >
> > >> > >> >
> > >> > >>
> > >> > >> Hi eelco,
> > >> > >>
> > >> > >> I'd love to do a proof of concept here. Admittedly, I don't know
> > >> wicket's
> > >> > >> inner workings very well. But if I get some support, I'd try
> > >> implementing
> > >> > >> this. I am currently looking through the code, but can't find
> > where
> > >> the
> > >> > >> transition between parent and child takes place (in other words:
> > the
> > >> line
> > >> > >> of
> > >> > >> code that recognizes the wicket:extend tag and takes the
> > appropriate
> > >> > >> action). If somebody could point me to that line I would try to
> > >> implement
> > >> > >> this possible new feature ... well, I'll first estimate the time
> > >> > >> necessary
> > >> > >> to do so and see if I can afford it ;)
> > >> > >>
> > >> > >> Regards
> > >> > >>
> > >> > >>
> > >> > >>
> > >> > >> -----
> > >> > >> -------
> > >> > >> Stefan Fußenegger
> > >> > >> http://talk-on-tech.blogspot.com // looking for a nicer domain
> ;)
> > >> > >> --
> > >> > >> View this message in context:
> > >> > >> http://www.nabble.com/Multiple-%3Cwicket%3Achild--%3E-tags-on-a-
> > >> single-base-page--tf4738673.html#a13586814
> > >> > >> 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
> > >> > >>
> > >> > >>
> > >> > >
> > >> > >
> > >> > > --
> > >> > > 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/Multiple-
> > >> %3Cwicket%3Achild--%3E-tags-on-a-single-base-page--
> > >> tf4738673.html#a13587701
> > >> > 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
> > >> >
> > >> >
> > >>
> > >> ---------------------------------------------------------------------
> > >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > >> For additional commands, e-mail: users-help@wicket.apache.org
> > >
> > >
> > > ---------------------------------------------------------------------
> > > 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/Multiple-
> > %3Cwicket%3Achild--%3E-tags-on-a-single-base-page--
> > tf4738673.html#a13597619
> > 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
>
>
> ---------------------------------------------------------------------
> 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: Multiple tags on a single base page?

Posted by Chris Colman <ch...@stepaheadsoftware.com>.

> I totally agree with you, having named extension points would be perfect.
> However, I am trying to do a quick proof of concept that can be discussed
> before I implement all those nice and shiny features. Hopefully this
> prototype convinces some of those sceptics out there ;)

I think the anyone who understands how Java supports multiple abstract methods without supporting multiple inheritance should be convinced. If it makes sense for OO languages to support multiple overriddable abstract methods why should wicket be limited to only a single overridable markup section?

> I already figured out how to implement this change. Basically, it's only a
> single method (MergedMarkup.merge(...)) to change ... but this method has
> 275 lines and needs *major* refactoring ... damn.

Doh! I reckon you'll have more success adding a completely new tag set because touching the old one get people worried that it might break. If you have a new tag set you are free to define the syntax and behaviour - and you have no chance of breaking how the old tag set works. There's nothing wrong with two tag sets - especially as the new one can be named correctly and will have to support named extension points, eventually.
 
> 
> However, changing the name of the tag (while it would make perfect sense)
> seems to be more complicated. You would have to make sure, that tags are
> not
> mixed up and decide between two different markup-merging-implementations,
> although one implementation is capable of doing the same as the other one
> -
> and more.

Maybe make 'child' an alias for 'abstract' and 'extends' an alias for 'implements' and then use your funky new markup-merging-implementation to handle both multiple (if names are provided) and fallback to single (if no names are provided) - single is then just an ordinary case of multiple where n=1.

> 
> However, I'll consider using a different name and separate implementation
> for the prototype.
> 
> -- Stefan
> 
> 
> 
> Chris Colman wrote:
> >
> >> if i were you i would use tags other then extend and child just so you
> >> dont conflict.
> >
> > Yes Stefan, I would think that would be a better approach to use a new
> set
> > of tags. It also allows you to choose more correct naming (because
> > inheritance isn't actually a parent/child relationship so the word child
> > just confuses the issue).
> >
> > Maybe wicket:abstract in the base and wicket:implements (nice - thanks
> to
> > whoever suggested that) or wicket:override in the derived (extended)
> > markup.
> >
> > I think using IDs up front would also be great, if not necessary,
> because
> > in Java as would probably occur in wicket mark up, you can have
> > intermediate classes that don't implement all abstract methods in a base
> > class. Without IDs you won't know exactly which abstract method an
> > intermediate class is implementing.
> >
> > This example hopefully demonstrates what I mean:
> >
> > Base
> > ----
> > <wicket:abstract id=header />
> > <wicket:abstract id=body />
> >
> > PumpsBase
> > ---------
> > <wicket:implements id=header>
> > 	A header for all pages to do with pumps
> > </wicket:implements>
> >
> > Note: no body implemented here - deferred until a more specialized
> > class/markups: WaterPumpsBase and OilPumpsBase
> >
> > WaterPumpBase
> > -------------
> > Note: no header implemented here - the general PumpsBase one suffices
> for
> > all pumps pages
> >
> > <wicket:implements id=body>
> > 	A body discussing water pumps
> > </wicket:implements>
> >
> >
> > OilPumpBase
> > -----------
> > Note: no header implemented here - the general PumpsBase one suffices
> for
> > all pumps pages
> >
> > <wicket:implements id=body>
> > 	A body discussing oil pumps
> > </wicket:implements>
> >
> >
> > I think the tag pairs abstract/implements flow much better from an OO
> > perspective than child/extends. It hurts my brain way to much to think
> of
> > a base class as a child.
> >
> >>
> >> -igor
> >>
> >>
> >> On 11/5/07, Stefan Fußenegger <st...@gmx.at> wrote:
> >> >
> >> > Well, what I'd like to do is what I explained in my first post. One
> >> would
> >> > still have a one-one-relationship if it comes to files (Base.html,
> >> Base.java
> >> > - Sub.html, Sub.java). However, a Base.html might contain more than
> one
> >> > <wicket:extend />. So this no longer an exact duplicate of the
> parent-
> >> child
> >> > relationship that is already specified by the java class hierarchy.
> It
> >> now
> >> > would be similar to abstract method, where the abstract class
> specifies
> >> one
> >> > or more extension points that are implemented by its subcasses ...
> >> abstract
> >> > methods. There isn't a restriction, that there is only one abstract
> >> method
> >> > per class!
> >> >
> >> > My proof of concept would go the probably easiest way and just link
> the
> >> > first extend with the first child, the second extend with the second
> >> child,
> >> > the third ... you got the idea ;) At a later point it might be useful
> >> to
> >> > link them using ids (like the names of abstract methods).
> >> >
> >> > You could than for instance do some hierarchies like this:
> >> >
> >> > BaseClass - Application base class. Navigation on top, two columns
> with
> >> > wicket:extend
> >> > SectionOneBaseClass extends BaseClass - Sub-navigation in left column
> >> > SectionOneIndex extends SectionOneBaseClass - Navigation on top,
> >> > sub-navigation in left column and some fancy content in right column
> >> >
> >> > I totally agree to anybody who argues that this is already possible
> by
> >> other
> >> > means. However, to me it seems to be the most natural and elegant way
> >> to
> >> do
> >> > this.
> >> >
> >> > As I mentioned before, I don't know Wicket's inner workings too much,
> >> so
> >> I
> >> > will definitely need some pointers to the right directions.
> >> >
> >> > My naive guess is that Wicket parses BasePage.html and looks for
> >> > SecionOneBaseClass.html and the first <wicket:child /> as soon as it
> >> finds a
> >> > <wicket:extend />. The idea would know be to just add a counter to
> this
> >> > call, asking for the second <wicket:child />, rather than the first
> (I
> >> doubt
> >> > that it's really going to be that easy though).
> >> >
> >> >
> >> >
> >> >
> >> > Bruno Borges wrote:
> >> > >
> >> > > Stefan, try first giving us an example of what would you like to
> do.
> >> What
> >> > > I
> >> > > can see is that you want this:
> >> > >
> >> > > BasePage.html
> >> > > <html>
> >> > >   <body>
> >> > >     <h1>BasePage</h1>
> >> > >     <hr/>
> >> > >     <h3>This is my child:</h3>
> >> > >     <wicket:child />
> >> > >     <hr/>
> >> > >     <h3>This is my OTHER child:</h3>
> >> > >     <wicket:child />
> >> > >   </body>
> >> > > </html>
> >> > >
> >> > > ** Example of a child page:*
> >> > > ChildPage.html
> >> > > <html>
> >> > >   <body>
> >> > >     <wicket:extend>
> >> > >       <h4>ChildPage</h4>
> >> > >       <h5>I'm your child</h5>
> >> > >     </wicket:extend>
> >> > >   </body>
> >> > > </html>
> >> > >
> >> > > Now, given this html, how do you see the Java code structured?
> What's
> >> your
> >> > > vision?
> >> > >
> >> > > On Nov 5, 2007 11:28 AM, Stefan Fußenegger
> >> <st...@gmx.at>
> >> > > wrote:
> >> > >
> >> > >>
> >> > >>
> >> > >> Eelco Hillenius wrote:
> >> > >> >
> >> > >> >> It would be quite feasible to add support for multiple
> overridden
> >> > >> >> sections using the above tag names while remaining backwards
> >> > >> compatible
> >> > >> >> with existing markup by continuing to support the old
> >> <child/extends>
> >> > >> >> tags working the way they always have.
> >> > >> >
> >> > >> > It's kind of a predictable answer, but the best way to push new
> >> ideas
> >> > >> > forward is to supply us with a patch, so that we can discuss
> some
> >> > >> > working code. The current committers don't see much in the idea,
> >> but
> >> > >> > that doesn't mean they wouldn't want to support at least the
> >> option
> >> of
> >> > >> > plugging this in. And hey, maybe some working code convinces us
> >> :-)
> >> > >> >
> >> > >> > Eelco
> >> > >> >
> >> > >> >
> >> -------------------------------------------------------------------
> >> --
> >> > >> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >> > >> > For additional commands, e-mail: users-help@wicket.apache.org
> >> > >> >
> >> > >> >
> >> > >> >
> >> > >>
> >> > >> Hi eelco,
> >> > >>
> >> > >> I'd love to do a proof of concept here. Admittedly, I don't know
> >> wicket's
> >> > >> inner workings very well. But if I get some support, I'd try
> >> implementing
> >> > >> this. I am currently looking through the code, but can't find
> where
> >> the
> >> > >> transition between parent and child takes place (in other words:
> the
> >> line
> >> > >> of
> >> > >> code that recognizes the wicket:extend tag and takes the
> appropriate
> >> > >> action). If somebody could point me to that line I would try to
> >> implement
> >> > >> this possible new feature ... well, I'll first estimate the time
> >> > >> necessary
> >> > >> to do so and see if I can afford it ;)
> >> > >>
> >> > >> Regards
> >> > >>
> >> > >>
> >> > >>
> >> > >> -----
> >> > >> -------
> >> > >> Stefan Fußenegger
> >> > >> http://talk-on-tech.blogspot.com // looking for a nicer domain ;)
> >> > >> --
> >> > >> View this message in context:
> >> > >> http://www.nabble.com/Multiple-%3Cwicket%3Achild--%3E-tags-on-a-
> >> single-base-page--tf4738673.html#a13586814
> >> > >> 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
> >> > >>
> >> > >>
> >> > >
> >> > >
> >> > > --
> >> > > 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/Multiple-
> >> %3Cwicket%3Achild--%3E-tags-on-a-single-base-page--
> >> tf4738673.html#a13587701
> >> > 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
> >> >
> >> >
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >> For additional commands, e-mail: users-help@wicket.apache.org
> >
> >
> > ---------------------------------------------------------------------
> > 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/Multiple-
> %3Cwicket%3Achild--%3E-tags-on-a-single-base-page--
> tf4738673.html#a13597619
> 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


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org

RE: Multiple tags on a single base page?

Posted by Stefan Fußenegger <st...@gmx.at>.

I totally agree with you, having named extension points would be perfect.
However, I am trying to do a quick proof of concept that can be discussed
before I implement all those nice and shiny features. Hopefully this
prototype convinces some of those sceptics out there ;)

I already figured out how to implement this change. Basically, it's only a
single method (MergedMarkup.merge(...)) to change ... but this method has
275 lines and needs *major* refactoring ... damn.

However, changing the name of the tag (while it would make perfect sense)
seems to be more complicated. You would have to make sure, that tags are not
mixed up and decide between two different markup-merging-implementations,
although one implementation is capable of doing the same as the other one -
and more.

However, I'll consider using a different name and separate implementation
for the prototype.

-- Stefan



Chris Colman wrote:
> 
>> if i were you i would use tags other then extend and child just so you
>> dont conflict.
> 
> Yes Stefan, I would think that would be a better approach to use a new set
> of tags. It also allows you to choose more correct naming (because
> inheritance isn't actually a parent/child relationship so the word child
> just confuses the issue).
> 
> Maybe wicket:abstract in the base and wicket:implements (nice - thanks to
> whoever suggested that) or wicket:override in the derived (extended)
> markup.
> 
> I think using IDs up front would also be great, if not necessary, because
> in Java as would probably occur in wicket mark up, you can have
> intermediate classes that don't implement all abstract methods in a base
> class. Without IDs you won't know exactly which abstract method an
> intermediate class is implementing.
> 
> This example hopefully demonstrates what I mean:
> 
> Base
> ----
> <wicket:abstract id=header />
> <wicket:abstract id=body />
> 
> PumpsBase
> ---------
> <wicket:implements id=header>
> 	A header for all pages to do with pumps
> </wicket:implements>
> 
> Note: no body implemented here - deferred until a more specialized
> class/markups: WaterPumpsBase and OilPumpsBase
> 
> WaterPumpBase
> -------------
> Note: no header implemented here - the general PumpsBase one suffices for
> all pumps pages
> 
> <wicket:implements id=body>
> 	A body discussing water pumps
> </wicket:implements>
> 
> 
> OilPumpBase
> -----------
> Note: no header implemented here - the general PumpsBase one suffices for
> all pumps pages
> 
> <wicket:implements id=body>
> 	A body discussing oil pumps
> </wicket:implements>
> 
> 
> I think the tag pairs abstract/implements flow much better from an OO
> perspective than child/extends. It hurts my brain way to much to think of
> a base class as a child.
> 
>> 
>> -igor
>> 
>> 
>> On 11/5/07, Stefan Fußenegger <st...@gmx.at> wrote:
>> >
>> > Well, what I'd like to do is what I explained in my first post. One
>> would
>> > still have a one-one-relationship if it comes to files (Base.html,
>> Base.java
>> > - Sub.html, Sub.java). However, a Base.html might contain more than one
>> > <wicket:extend />. So this no longer an exact duplicate of the parent-
>> child
>> > relationship that is already specified by the java class hierarchy. It
>> now
>> > would be similar to abstract method, where the abstract class specifies
>> one
>> > or more extension points that are implemented by its subcasses ...
>> abstract
>> > methods. There isn't a restriction, that there is only one abstract
>> method
>> > per class!
>> >
>> > My proof of concept would go the probably easiest way and just link the
>> > first extend with the first child, the second extend with the second
>> child,
>> > the third ... you got the idea ;) At a later point it might be useful
>> to
>> > link them using ids (like the names of abstract methods).
>> >
>> > You could than for instance do some hierarchies like this:
>> >
>> > BaseClass - Application base class. Navigation on top, two columns with
>> > wicket:extend
>> > SectionOneBaseClass extends BaseClass - Sub-navigation in left column
>> > SectionOneIndex extends SectionOneBaseClass - Navigation on top,
>> > sub-navigation in left column and some fancy content in right column
>> >
>> > I totally agree to anybody who argues that this is already possible by
>> other
>> > means. However, to me it seems to be the most natural and elegant way
>> to
>> do
>> > this.
>> >
>> > As I mentioned before, I don't know Wicket's inner workings too much,
>> so
>> I
>> > will definitely need some pointers to the right directions.
>> >
>> > My naive guess is that Wicket parses BasePage.html and looks for
>> > SecionOneBaseClass.html and the first <wicket:child /> as soon as it
>> finds a
>> > <wicket:extend />. The idea would know be to just add a counter to this
>> > call, asking for the second <wicket:child />, rather than the first (I
>> doubt
>> > that it's really going to be that easy though).
>> >
>> >
>> >
>> >
>> > Bruno Borges wrote:
>> > >
>> > > Stefan, try first giving us an example of what would you like to do.
>> What
>> > > I
>> > > can see is that you want this:
>> > >
>> > > BasePage.html
>> > > <html>
>> > >   <body>
>> > >     <h1>BasePage</h1>
>> > >     <hr/>
>> > >     <h3>This is my child:</h3>
>> > >     <wicket:child />
>> > >     <hr/>
>> > >     <h3>This is my OTHER child:</h3>
>> > >     <wicket:child />
>> > >   </body>
>> > > </html>
>> > >
>> > > ** Example of a child page:*
>> > > ChildPage.html
>> > > <html>
>> > >   <body>
>> > >     <wicket:extend>
>> > >       <h4>ChildPage</h4>
>> > >       <h5>I'm your child</h5>
>> > >     </wicket:extend>
>> > >   </body>
>> > > </html>
>> > >
>> > > Now, given this html, how do you see the Java code structured? What's
>> your
>> > > vision?
>> > >
>> > > On Nov 5, 2007 11:28 AM, Stefan Fußenegger
>> <st...@gmx.at>
>> > > wrote:
>> > >
>> > >>
>> > >>
>> > >> Eelco Hillenius wrote:
>> > >> >
>> > >> >> It would be quite feasible to add support for multiple overridden
>> > >> >> sections using the above tag names while remaining backwards
>> > >> compatible
>> > >> >> with existing markup by continuing to support the old
>> <child/extends>
>> > >> >> tags working the way they always have.
>> > >> >
>> > >> > It's kind of a predictable answer, but the best way to push new
>> ideas
>> > >> > forward is to supply us with a patch, so that we can discuss some
>> > >> > working code. The current committers don't see much in the idea,
>> but
>> > >> > that doesn't mean they wouldn't want to support at least the
>> option
>> of
>> > >> > plugging this in. And hey, maybe some working code convinces us
>> :-)
>> > >> >
>> > >> > Eelco
>> > >> >
>> > >> >
>> -------------------------------------------------------------------
>> --
>> > >> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> > >> > For additional commands, e-mail: users-help@wicket.apache.org
>> > >> >
>> > >> >
>> > >> >
>> > >>
>> > >> Hi eelco,
>> > >>
>> > >> I'd love to do a proof of concept here. Admittedly, I don't know
>> wicket's
>> > >> inner workings very well. But if I get some support, I'd try
>> implementing
>> > >> this. I am currently looking through the code, but can't find where
>> the
>> > >> transition between parent and child takes place (in other words: the
>> line
>> > >> of
>> > >> code that recognizes the wicket:extend tag and takes the appropriate
>> > >> action). If somebody could point me to that line I would try to
>> implement
>> > >> this possible new feature ... well, I'll first estimate the time
>> > >> necessary
>> > >> to do so and see if I can afford it ;)
>> > >>
>> > >> Regards
>> > >>
>> > >>
>> > >>
>> > >> -----
>> > >> -------
>> > >> Stefan Fußenegger
>> > >> http://talk-on-tech.blogspot.com // looking for a nicer domain ;)
>> > >> --
>> > >> View this message in context:
>> > >> http://www.nabble.com/Multiple-%3Cwicket%3Achild--%3E-tags-on-a-
>> single-base-page--tf4738673.html#a13586814
>> > >> 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
>> > >>
>> > >>
>> > >
>> > >
>> > > --
>> > > 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/Multiple-
>> %3Cwicket%3Achild--%3E-tags-on-a-single-base-page--
>> tf4738673.html#a13587701
>> > 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
>> >
>> >
>> 
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
> 
> 
> ---------------------------------------------------------------------
> 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/Multiple-%3Cwicket%3Achild--%3E-tags-on-a-single-base-page--tf4738673.html#a13597619
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: Multiple tags on a single base page?

Posted by Chris Colman <ch...@stepaheadsoftware.com>.

> if i were you i would use tags other then extend and child just so you
> dont conflict.

Yes Stefan, I would think that would be a better approach to use a new set of tags. It also allows you to choose more correct naming (because inheritance isn't actually a parent/child relationship so the word child just confuses the issue).

Maybe wicket:abstract in the base and wicket:implements (nice - thanks to whoever suggested that) or wicket:override in the derived (extended) markup.

I think using IDs up front would also be great, if not necessary, because in Java as would probably occur in wicket mark up, you can have intermediate classes that don't implement all abstract methods in a base class. Without IDs you won't know exactly which abstract method an intermediate class is implementing.

This example hopefully demonstrates what I mean:

Base
----
<wicket:abstract id=header />
<wicket:abstract id=body />

PumpsBase
---------
<wicket:implements id=header>
	A header for all pages to do with pumps
</wicket:implements>

Note: no body implemented here - deferred until a more specialized class/markups: WaterPumpsBase and OilPumpsBase

WaterPumpBase
-------------
Note: no header implemented here - the general PumpsBase one suffices for all pumps pages

<wicket:implements id=body>
	A body discussing water pumps
</wicket:implements>


OilPumpBase
-----------
Note: no header implemented here - the general PumpsBase one suffices for all pumps pages

<wicket:implements id=body>
	A body discussing oil pumps
</wicket:implements>


I think the tag pairs abstract/implements flow much better from an OO perspective than child/extends. It hurts my brain way to much to think of a base class as a child.

> 
> -igor
> 
> 
> On 11/5/07, Stefan Fußenegger <st...@gmx.at> wrote:
> >
> > Well, what I'd like to do is what I explained in my first post. One
> would
> > still have a one-one-relationship if it comes to files (Base.html,
> Base.java
> > - Sub.html, Sub.java). However, a Base.html might contain more than one
> > <wicket:extend />. So this no longer an exact duplicate of the parent-
> child
> > relationship that is already specified by the java class hierarchy. It
> now
> > would be similar to abstract method, where the abstract class specifies
> one
> > or more extension points that are implemented by its subcasses ...
> abstract
> > methods. There isn't a restriction, that there is only one abstract
> method
> > per class!
> >
> > My proof of concept would go the probably easiest way and just link the
> > first extend with the first child, the second extend with the second
> child,
> > the third ... you got the idea ;) At a later point it might be useful to
> > link them using ids (like the names of abstract methods).
> >
> > You could than for instance do some hierarchies like this:
> >
> > BaseClass - Application base class. Navigation on top, two columns with
> > wicket:extend
> > SectionOneBaseClass extends BaseClass - Sub-navigation in left column
> > SectionOneIndex extends SectionOneBaseClass - Navigation on top,
> > sub-navigation in left column and some fancy content in right column
> >
> > I totally agree to anybody who argues that this is already possible by
> other
> > means. However, to me it seems to be the most natural and elegant way to
> do
> > this.
> >
> > As I mentioned before, I don't know Wicket's inner workings too much, so
> I
> > will definitely need some pointers to the right directions.
> >
> > My naive guess is that Wicket parses BasePage.html and looks for
> > SecionOneBaseClass.html and the first <wicket:child /> as soon as it
> finds a
> > <wicket:extend />. The idea would know be to just add a counter to this
> > call, asking for the second <wicket:child />, rather than the first (I
> doubt
> > that it's really going to be that easy though).
> >
> >
> >
> >
> > Bruno Borges wrote:
> > >
> > > Stefan, try first giving us an example of what would you like to do.
> What
> > > I
> > > can see is that you want this:
> > >
> > > BasePage.html
> > > <html>
> > >   <body>
> > >     <h1>BasePage</h1>
> > >     <hr/>
> > >     <h3>This is my child:</h3>
> > >     <wicket:child />
> > >     <hr/>
> > >     <h3>This is my OTHER child:</h3>
> > >     <wicket:child />
> > >   </body>
> > > </html>
> > >
> > > ** Example of a child page:*
> > > ChildPage.html
> > > <html>
> > >   <body>
> > >     <wicket:extend>
> > >       <h4>ChildPage</h4>
> > >       <h5>I'm your child</h5>
> > >     </wicket:extend>
> > >   </body>
> > > </html>
> > >
> > > Now, given this html, how do you see the Java code structured? What's
> your
> > > vision?
> > >
> > > On Nov 5, 2007 11:28 AM, Stefan Fußenegger <st...@gmx.at>
> > > wrote:
> > >
> > >>
> > >>
> > >> Eelco Hillenius wrote:
> > >> >
> > >> >> It would be quite feasible to add support for multiple overridden
> > >> >> sections using the above tag names while remaining backwards
> > >> compatible
> > >> >> with existing markup by continuing to support the old
> <child/extends>
> > >> >> tags working the way they always have.
> > >> >
> > >> > It's kind of a predictable answer, but the best way to push new
> ideas
> > >> > forward is to supply us with a patch, so that we can discuss some
> > >> > working code. The current committers don't see much in the idea,
> but
> > >> > that doesn't mean they wouldn't want to support at least the option
> of
> > >> > plugging this in. And hey, maybe some working code convinces us :-)
> > >> >
> > >> > Eelco
> > >> >
> > >> > -------------------------------------------------------------------
> --
> > >> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > >> > For additional commands, e-mail: users-help@wicket.apache.org
> > >> >
> > >> >
> > >> >
> > >>
> > >> Hi eelco,
> > >>
> > >> I'd love to do a proof of concept here. Admittedly, I don't know
> wicket's
> > >> inner workings very well. But if I get some support, I'd try
> implementing
> > >> this. I am currently looking through the code, but can't find where
> the
> > >> transition between parent and child takes place (in other words: the
> line
> > >> of
> > >> code that recognizes the wicket:extend tag and takes the appropriate
> > >> action). If somebody could point me to that line I would try to
> implement
> > >> this possible new feature ... well, I'll first estimate the time
> > >> necessary
> > >> to do so and see if I can afford it ;)
> > >>
> > >> Regards
> > >>
> > >>
> > >>
> > >> -----
> > >> -------
> > >> Stefan Fußenegger
> > >> http://talk-on-tech.blogspot.com // looking for a nicer domain ;)
> > >> --
> > >> View this message in context:
> > >> http://www.nabble.com/Multiple-%3Cwicket%3Achild--%3E-tags-on-a-
> single-base-page--tf4738673.html#a13586814
> > >> 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
> > >>
> > >>
> > >
> > >
> > > --
> > > 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/Multiple-
> %3Cwicket%3Achild--%3E-tags-on-a-single-base-page--
> tf4738673.html#a13587701
> > 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
> >
> >
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org

Re: Multiple tags on a single base page?

Posted by Stefan Fußenegger <st...@gmx.at>.

but why choose another name? as long as there is only one pair of however
named tags, the behaviour wouldn't change at all. It would only extend the
current functionality for those who place a second extension point in there
html files. 

But I am not in the core team, but curious to look under the hood. While I
would love to see this extension becoming part of wicket, I don't care too
much what happens with it as long as I have fun implementing it. ;)

And as numerous times mentioned before: This extension still aligns with how
class inheritance works in java, you only have to see html files as classes
and extension points as (abstract) methods. That's the only conceptual
change.

But there is still some time left to argue while I am hacking ;) 

Regards

igor.vaynberg wrote:
> 
> On 11/5/07, Stefan Fußenegger <st...@gmx.at> wrote:
>>
>> well, i thought chris' suggestion to use abstract and override in order
>> to
>> align it with the java keyword/annotation. I don't care whether it is
>> implement or override (but yes, names are important). i think i'll go for
>> implement though ... but if it finally becomes part of wicket, it will
>> become extend/child anyway, wouldn't it?
> 
> no it would not.
> 
> as mentioned numerous times before, we like how it currently works
> because it aligns with how class inheritance works in java and thus is
> easy to understand.
> 
> this would be an in-addion-to feature that people may choose to use.
> 
> -igor
> 
> ---------------------------------------------------------------------
> 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/Multiple-%3Cwicket%3Achild--%3E-tags-on-a-single-base-page--tf4738673.html#a13590818
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: Multiple tags on a single base page?

Posted by Igor Vaynberg <ig...@gmail.com>.

On 11/5/07, Stefan Fußenegger <st...@gmx.at> wrote:
>
> well, i thought chris' suggestion to use abstract and override in order to
> align it with the java keyword/annotation. I don't care whether it is
> implement or override (but yes, names are important). i think i'll go for
> implement though ... but if it finally becomes part of wicket, it will
> become extend/child anyway, wouldn't it?

no it would not.

as mentioned numerous times before, we like how it currently works
because it aligns with how class inheritance works in java and thus is
easy to understand.

this would be an in-addion-to feature that people may choose to use.

-igor

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org

Re: Multiple tags on a single base page?

Posted by Stefan Fußenegger <st...@gmx.at>.

well, i thought chris' suggestion to use abstract and override in order to
align it with the java keyword/annotation. I don't care whether it is
implement or override (but yes, names are important). i think i'll go for
implement though ... but if it finally becomes part of wicket, it will
become extend/child anyway, wouldn't it? but let's see what i can do here
first.



igor.vaynberg wrote:
> 
> the complement to abstract is implement not override... names are
> important.
> 
> -igor
> 
> 
> On 11/5/07, Stefan Fußenegger <st...@gmx.at> wrote:
>>
>> thanks for that advise.
>>
>> hey chris, keep your fingers crossed. finally you could get your
>> wicket:abstract-wicket:override ;)
>>
>> stefan
>>
>>
>>
>> igor.vaynberg wrote:
>> >
>> > if i were you i would use tags other then extend and child just so you
>> > dont conflict.
>> >
>> > -igor
>> >
>> >
>> > On 11/5/07, Stefan Fußenegger <st...@gmx.at> wrote:
>> >>
>> >> Well, what I'd like to do is what I explained in my first post. One
>> would
>> >> still have a one-one-relationship if it comes to files (Base.html,
>> >> Base.java
>> >> - Sub.html, Sub.java). However, a Base.html might contain more than
>> one
>> >> <wicket:extend />. So this no longer an exact duplicate of the
>> >> parent-child
>> >> relationship that is already specified by the java class hierarchy. It
>> >> now
>> >> would be similar to abstract method, where the abstract class
>> specifies
>> >> one
>> >> or more extension points that are implemented by its subcasses ...
>> >> abstract
>> >> methods. There isn't a restriction, that there is only one abstract
>> >> method
>> >> per class!
>> >>
>> >> My proof of concept would go the probably easiest way and just link
>> the
>> >> first extend with the first child, the second extend with the second
>> >> child,
>> >> the third ... you got the idea ;) At a later point it might be useful
>> to
>> >> link them using ids (like the names of abstract methods).
>> >>
>> >> You could than for instance do some hierarchies like this:
>> >>
>> >> BaseClass - Application base class. Navigation on top, two columns
>> with
>> >> wicket:extend
>> >> SectionOneBaseClass extends BaseClass - Sub-navigation in left column
>> >> SectionOneIndex extends SectionOneBaseClass - Navigation on top,
>> >> sub-navigation in left column and some fancy content in right column
>> >>
>> >> I totally agree to anybody who argues that this is already possible by
>> >> other
>> >> means. However, to me it seems to be the most natural and elegant way
>> to
>> >> do
>> >> this.
>> >>
>> >> As I mentioned before, I don't know Wicket's inner workings too much,
>> so
>> >> I
>> >> will definitely need some pointers to the right directions.
>> >>
>> >> My naive guess is that Wicket parses BasePage.html and looks for
>> >> SecionOneBaseClass.html and the first <wicket:child /> as soon as it
>> >> finds a
>> >> <wicket:extend />. The idea would know be to just add a counter to
>> this
>> >> call, asking for the second <wicket:child />, rather than the first (I
>> >> doubt
>> >> that it's really going to be that easy though).
>> >>
>> >>
>> >>
>> >>
>> >> Bruno Borges wrote:
>> >> >
>> >> > Stefan, try first giving us an example of what would you like to do.
>> >> What
>> >> > I
>> >> > can see is that you want this:
>> >> >
>> >> > BasePage.html
>> >> > <html>
>> >> >   <body>
>> >> >     <h1>BasePage</h1>
>> >> >     <hr/>
>> >> >     <h3>This is my child:</h3>
>> >> >     <wicket:child />
>> >> >     <hr/>
>> >> >     <h3>This is my OTHER child:</h3>
>> >> >     <wicket:child />
>> >> >   </body>
>> >> > </html>
>> >> >
>> >> > ** Example of a child page:*
>> >> > ChildPage.html
>> >> > <html>
>> >> >   <body>
>> >> >     <wicket:extend>
>> >> >       <h4>ChildPage</h4>
>> >> >       <h5>I'm your child</h5>
>> >> >     </wicket:extend>
>> >> >   </body>
>> >> > </html>
>> >> >
>> >> > Now, given this html, how do you see the Java code structured?
>> What's
>> >> your
>> >> > vision?
>> >> >
>> >> > On Nov 5, 2007 11:28 AM, Stefan Fußenegger
>> <st...@gmx.at>
>> >> > wrote:
>> >> >
>> >> >>
>> >> >>
>> >> >> Eelco Hillenius wrote:
>> >> >> >
>> >> >> >> It would be quite feasible to add support for multiple
>> overridden
>> >> >> >> sections using the above tag names while remaining backwards
>> >> >> compatible
>> >> >> >> with existing markup by continuing to support the old
>> >> <child/extends>
>> >> >> >> tags working the way they always have.
>> >> >> >
>> >> >> > It's kind of a predictable answer, but the best way to push new
>> >> ideas
>> >> >> > forward is to supply us with a patch, so that we can discuss some
>> >> >> > working code. The current committers don't see much in the idea,
>> but
>> >> >> > that doesn't mean they wouldn't want to support at least the
>> option
>> >> of
>> >> >> > plugging this in. And hey, maybe some working code convinces us
>> :-)
>> >> >> >
>> >> >> > Eelco
>> >> >> >
>> >> >> >
>> >> ---------------------------------------------------------------------
>> >> >> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> >> >> > For additional commands, e-mail: users-help@wicket.apache.org
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >>
>> >> >> Hi eelco,
>> >> >>
>> >> >> I'd love to do a proof of concept here. Admittedly, I don't know
>> >> wicket's
>> >> >> inner workings very well. But if I get some support, I'd try
>> >> implementing
>> >> >> this. I am currently looking through the code, but can't find where
>> >> the
>> >> >> transition between parent and child takes place (in other words:
>> the
>> >> line
>> >> >> of
>> >> >> code that recognizes the wicket:extend tag and takes the
>> appropriate
>> >> >> action). If somebody could point me to that line I would try to
>> >> implement
>> >> >> this possible new feature ... well, I'll first estimate the time
>> >> >> necessary
>> >> >> to do so and see if I can afford it ;)
>> >> >>
>> >> >> Regards
>> >> >>
>> >> >>
>> >> >>
>> >> >> -----
>> >> >> -------
>> >> >> Stefan Fußenegger
>> >> >> http://talk-on-tech.blogspot.com // looking for a nicer domain ;)
>> >> >> --
>> >> >> View this message in context:
>> >> >>
>> >>
>> http://www.nabble.com/Multiple-%3Cwicket%3Achild--%3E-tags-on-a-single-base-page--tf4738673.html#a13586814
>> >> >> 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
>> >> >>
>> >> >>
>> >> >
>> >> >
>> >> > --
>> >> > 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/Multiple-%3Cwicket%3Achild--%3E-tags-on-a-single-base-page--tf4738673.html#a13587701
>> >> 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
>> >>
>> >>
>> >
>> > ---------------------------------------------------------------------
>> > 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/Multiple-%3Cwicket%3Achild--%3E-tags-on-a-single-base-page--tf4738673.html#a13589908
>> 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
>>
>>
> 
> ---------------------------------------------------------------------
> 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/Multiple-%3Cwicket%3Achild--%3E-tags-on-a-single-base-page--tf4738673.html#a13590337
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: Multiple tags on a single base page?

Posted by Chris Colman <ch...@stepaheadsoftware.com>.

> the complement to abstract is implement not override... names are
> important.

Arh, sorry, I made my last post before reading yours Igor. Yes, I agree
abstract/implement make a great complimentary pair.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org

Re: Multiple tags on a single base page?

Posted by Igor Vaynberg <ig...@gmail.com>.

the complement to abstract is implement not override... names are important.

-igor


On 11/5/07, Stefan Fußenegger <st...@gmx.at> wrote:
>
> thanks for that advise.
>
> hey chris, keep your fingers crossed. finally you could get your
> wicket:abstract-wicket:override ;)
>
> stefan
>
>
>
> igor.vaynberg wrote:
> >
> > if i were you i would use tags other then extend and child just so you
> > dont conflict.
> >
> > -igor
> >
> >
> > On 11/5/07, Stefan Fußenegger <st...@gmx.at> wrote:
> >>
> >> Well, what I'd like to do is what I explained in my first post. One would
> >> still have a one-one-relationship if it comes to files (Base.html,
> >> Base.java
> >> - Sub.html, Sub.java). However, a Base.html might contain more than one
> >> <wicket:extend />. So this no longer an exact duplicate of the
> >> parent-child
> >> relationship that is already specified by the java class hierarchy. It
> >> now
> >> would be similar to abstract method, where the abstract class specifies
> >> one
> >> or more extension points that are implemented by its subcasses ...
> >> abstract
> >> methods. There isn't a restriction, that there is only one abstract
> >> method
> >> per class!
> >>
> >> My proof of concept would go the probably easiest way and just link the
> >> first extend with the first child, the second extend with the second
> >> child,
> >> the third ... you got the idea ;) At a later point it might be useful to
> >> link them using ids (like the names of abstract methods).
> >>
> >> You could than for instance do some hierarchies like this:
> >>
> >> BaseClass - Application base class. Navigation on top, two columns with
> >> wicket:extend
> >> SectionOneBaseClass extends BaseClass - Sub-navigation in left column
> >> SectionOneIndex extends SectionOneBaseClass - Navigation on top,
> >> sub-navigation in left column and some fancy content in right column
> >>
> >> I totally agree to anybody who argues that this is already possible by
> >> other
> >> means. However, to me it seems to be the most natural and elegant way to
> >> do
> >> this.
> >>
> >> As I mentioned before, I don't know Wicket's inner workings too much, so
> >> I
> >> will definitely need some pointers to the right directions.
> >>
> >> My naive guess is that Wicket parses BasePage.html and looks for
> >> SecionOneBaseClass.html and the first <wicket:child /> as soon as it
> >> finds a
> >> <wicket:extend />. The idea would know be to just add a counter to this
> >> call, asking for the second <wicket:child />, rather than the first (I
> >> doubt
> >> that it's really going to be that easy though).
> >>
> >>
> >>
> >>
> >> Bruno Borges wrote:
> >> >
> >> > Stefan, try first giving us an example of what would you like to do.
> >> What
> >> > I
> >> > can see is that you want this:
> >> >
> >> > BasePage.html
> >> > <html>
> >> >   <body>
> >> >     <h1>BasePage</h1>
> >> >     <hr/>
> >> >     <h3>This is my child:</h3>
> >> >     <wicket:child />
> >> >     <hr/>
> >> >     <h3>This is my OTHER child:</h3>
> >> >     <wicket:child />
> >> >   </body>
> >> > </html>
> >> >
> >> > ** Example of a child page:*
> >> > ChildPage.html
> >> > <html>
> >> >   <body>
> >> >     <wicket:extend>
> >> >       <h4>ChildPage</h4>
> >> >       <h5>I'm your child</h5>
> >> >     </wicket:extend>
> >> >   </body>
> >> > </html>
> >> >
> >> > Now, given this html, how do you see the Java code structured? What's
> >> your
> >> > vision?
> >> >
> >> > On Nov 5, 2007 11:28 AM, Stefan Fußenegger <st...@gmx.at>
> >> > wrote:
> >> >
> >> >>
> >> >>
> >> >> Eelco Hillenius wrote:
> >> >> >
> >> >> >> It would be quite feasible to add support for multiple overridden
> >> >> >> sections using the above tag names while remaining backwards
> >> >> compatible
> >> >> >> with existing markup by continuing to support the old
> >> <child/extends>
> >> >> >> tags working the way they always have.
> >> >> >
> >> >> > It's kind of a predictable answer, but the best way to push new
> >> ideas
> >> >> > forward is to supply us with a patch, so that we can discuss some
> >> >> > working code. The current committers don't see much in the idea, but
> >> >> > that doesn't mean they wouldn't want to support at least the option
> >> of
> >> >> > plugging this in. And hey, maybe some working code convinces us :-)
> >> >> >
> >> >> > Eelco
> >> >> >
> >> >> >
> >> ---------------------------------------------------------------------
> >> >> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >> >> > For additional commands, e-mail: users-help@wicket.apache.org
> >> >> >
> >> >> >
> >> >> >
> >> >>
> >> >> Hi eelco,
> >> >>
> >> >> I'd love to do a proof of concept here. Admittedly, I don't know
> >> wicket's
> >> >> inner workings very well. But if I get some support, I'd try
> >> implementing
> >> >> this. I am currently looking through the code, but can't find where
> >> the
> >> >> transition between parent and child takes place (in other words: the
> >> line
> >> >> of
> >> >> code that recognizes the wicket:extend tag and takes the appropriate
> >> >> action). If somebody could point me to that line I would try to
> >> implement
> >> >> this possible new feature ... well, I'll first estimate the time
> >> >> necessary
> >> >> to do so and see if I can afford it ;)
> >> >>
> >> >> Regards
> >> >>
> >> >>
> >> >>
> >> >> -----
> >> >> -------
> >> >> Stefan Fußenegger
> >> >> http://talk-on-tech.blogspot.com // looking for a nicer domain ;)
> >> >> --
> >> >> View this message in context:
> >> >>
> >> http://www.nabble.com/Multiple-%3Cwicket%3Achild--%3E-tags-on-a-single-base-page--tf4738673.html#a13586814
> >> >> 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
> >> >>
> >> >>
> >> >
> >> >
> >> > --
> >> > 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/Multiple-%3Cwicket%3Achild--%3E-tags-on-a-single-base-page--tf4738673.html#a13587701
> >> 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
> >>
> >>
> >
> > ---------------------------------------------------------------------
> > 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/Multiple-%3Cwicket%3Achild--%3E-tags-on-a-single-base-page--tf4738673.html#a13589908
> 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
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org

RE: Multiple tags on a single base page?

Posted by Chris Colman <ch...@stepaheadsoftware.com>.

> thanks for that advise.
> 
> hey chris, keep your fingers crossed. finally you could get your
> wicket:abstract-wicket:override ;)

That would be magic!

Though I like the suggestion that someone made that we replace 'override' with implements. 'Abstract' has no implementation. 'Implements' provides the implemention - they sound nice together do you think?

> 
> stefan
> 
> 
> 
> igor.vaynberg wrote:
> >
> > if i were you i would use tags other then extend and child just so you
> > dont conflict.
> >
> > -igor
> >
> >
> > On 11/5/07, Stefan Fußenegger <st...@gmx.at> wrote:
> >>
> >> Well, what I'd like to do is what I explained in my first post. One
> would
> >> still have a one-one-relationship if it comes to files (Base.html,
> >> Base.java
> >> - Sub.html, Sub.java). However, a Base.html might contain more than one
> >> <wicket:extend />. So this no longer an exact duplicate of the
> >> parent-child
> >> relationship that is already specified by the java class hierarchy. It
> >> now
> >> would be similar to abstract method, where the abstract class specifies
> >> one
> >> or more extension points that are implemented by its subcasses ...
> >> abstract
> >> methods. There isn't a restriction, that there is only one abstract
> >> method
> >> per class!
> >>
> >> My proof of concept would go the probably easiest way and just link the
> >> first extend with the first child, the second extend with the second
> >> child,
> >> the third ... you got the idea ;) At a later point it might be useful
> to
> >> link them using ids (like the names of abstract methods).
> >>
> >> You could than for instance do some hierarchies like this:
> >>
> >> BaseClass - Application base class. Navigation on top, two columns with
> >> wicket:extend
> >> SectionOneBaseClass extends BaseClass - Sub-navigation in left column
> >> SectionOneIndex extends SectionOneBaseClass - Navigation on top,
> >> sub-navigation in left column and some fancy content in right column
> >>
> >> I totally agree to anybody who argues that this is already possible by
> >> other
> >> means. However, to me it seems to be the most natural and elegant way
> to
> >> do
> >> this.
> >>
> >> As I mentioned before, I don't know Wicket's inner workings too much,
> so
> >> I
> >> will definitely need some pointers to the right directions.
> >>
> >> My naive guess is that Wicket parses BasePage.html and looks for
> >> SecionOneBaseClass.html and the first <wicket:child /> as soon as it
> >> finds a
> >> <wicket:extend />. The idea would know be to just add a counter to this
> >> call, asking for the second <wicket:child />, rather than the first (I
> >> doubt
> >> that it's really going to be that easy though).
> >>
> >>
> >>
> >>
> >> Bruno Borges wrote:
> >> >
> >> > Stefan, try first giving us an example of what would you like to do.
> >> What
> >> > I
> >> > can see is that you want this:
> >> >
> >> > BasePage.html
> >> > <html>
> >> >   <body>
> >> >     <h1>BasePage</h1>
> >> >     <hr/>
> >> >     <h3>This is my child:</h3>
> >> >     <wicket:child />
> >> >     <hr/>
> >> >     <h3>This is my OTHER child:</h3>
> >> >     <wicket:child />
> >> >   </body>
> >> > </html>
> >> >
> >> > ** Example of a child page:*
> >> > ChildPage.html
> >> > <html>
> >> >   <body>
> >> >     <wicket:extend>
> >> >       <h4>ChildPage</h4>
> >> >       <h5>I'm your child</h5>
> >> >     </wicket:extend>
> >> >   </body>
> >> > </html>
> >> >
> >> > Now, given this html, how do you see the Java code structured? What's
> >> your
> >> > vision?
> >> >
> >> > On Nov 5, 2007 11:28 AM, Stefan Fußenegger
> <st...@gmx.at>
> >> > wrote:
> >> >
> >> >>
> >> >>
> >> >> Eelco Hillenius wrote:
> >> >> >
> >> >> >> It would be quite feasible to add support for multiple overridden
> >> >> >> sections using the above tag names while remaining backwards
> >> >> compatible
> >> >> >> with existing markup by continuing to support the old
> >> <child/extends>
> >> >> >> tags working the way they always have.
> >> >> >
> >> >> > It's kind of a predictable answer, but the best way to push new
> >> ideas
> >> >> > forward is to supply us with a patch, so that we can discuss some
> >> >> > working code. The current committers don't see much in the idea,
> but
> >> >> > that doesn't mean they wouldn't want to support at least the
> option
> >> of
> >> >> > plugging this in. And hey, maybe some working code convinces us :-
> )
> >> >> >
> >> >> > Eelco
> >> >> >
> >> >> >
> >> ---------------------------------------------------------------------
> >> >> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >> >> > For additional commands, e-mail: users-help@wicket.apache.org
> >> >> >
> >> >> >
> >> >> >
> >> >>
> >> >> Hi eelco,
> >> >>
> >> >> I'd love to do a proof of concept here. Admittedly, I don't know
> >> wicket's
> >> >> inner workings very well. But if I get some support, I'd try
> >> implementing
> >> >> this. I am currently looking through the code, but can't find where
> >> the
> >> >> transition between parent and child takes place (in other words: the
> >> line
> >> >> of
> >> >> code that recognizes the wicket:extend tag and takes the appropriate
> >> >> action). If somebody could point me to that line I would try to
> >> implement
> >> >> this possible new feature ... well, I'll first estimate the time
> >> >> necessary
> >> >> to do so and see if I can afford it ;)
> >> >>
> >> >> Regards
> >> >>
> >> >>
> >> >>
> >> >> -----
> >> >> -------
> >> >> Stefan Fußenegger
> >> >> http://talk-on-tech.blogspot.com // looking for a nicer domain ;)
> >> >> --
> >> >> View this message in context:
> >> >>
> >> http://www.nabble.com/Multiple-%3Cwicket%3Achild--%3E-tags-on-a-single-
> base-page--tf4738673.html#a13586814
> >> >> 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
> >> >>
> >> >>
> >> >
> >> >
> >> > --
> >> > 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/Multiple-%3Cwicket%3Achild--%3E-tags-on-a-single-
> base-page--tf4738673.html#a13587701
> >> 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
> >>
> >>
> >
> > ---------------------------------------------------------------------
> > 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/Multiple-
> %3Cwicket%3Achild--%3E-tags-on-a-single-base-page--
> tf4738673.html#a13589908
> 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


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org

Re: Multiple tags on a single base page?

Posted by Stefan Fußenegger <st...@gmx.at>.

thanks for that advise.

hey chris, keep your fingers crossed. finally you could get your
wicket:abstract-wicket:override ;)

stefan



igor.vaynberg wrote:
> 
> if i were you i would use tags other then extend and child just so you
> dont conflict.
> 
> -igor
> 
> 
> On 11/5/07, Stefan Fußenegger <st...@gmx.at> wrote:
>>
>> Well, what I'd like to do is what I explained in my first post. One would
>> still have a one-one-relationship if it comes to files (Base.html,
>> Base.java
>> - Sub.html, Sub.java). However, a Base.html might contain more than one
>> <wicket:extend />. So this no longer an exact duplicate of the
>> parent-child
>> relationship that is already specified by the java class hierarchy. It
>> now
>> would be similar to abstract method, where the abstract class specifies
>> one
>> or more extension points that are implemented by its subcasses ...
>> abstract
>> methods. There isn't a restriction, that there is only one abstract
>> method
>> per class!
>>
>> My proof of concept would go the probably easiest way and just link the
>> first extend with the first child, the second extend with the second
>> child,
>> the third ... you got the idea ;) At a later point it might be useful to
>> link them using ids (like the names of abstract methods).
>>
>> You could than for instance do some hierarchies like this:
>>
>> BaseClass - Application base class. Navigation on top, two columns with
>> wicket:extend
>> SectionOneBaseClass extends BaseClass - Sub-navigation in left column
>> SectionOneIndex extends SectionOneBaseClass - Navigation on top,
>> sub-navigation in left column and some fancy content in right column
>>
>> I totally agree to anybody who argues that this is already possible by
>> other
>> means. However, to me it seems to be the most natural and elegant way to
>> do
>> this.
>>
>> As I mentioned before, I don't know Wicket's inner workings too much, so
>> I
>> will definitely need some pointers to the right directions.
>>
>> My naive guess is that Wicket parses BasePage.html and looks for
>> SecionOneBaseClass.html and the first <wicket:child /> as soon as it
>> finds a
>> <wicket:extend />. The idea would know be to just add a counter to this
>> call, asking for the second <wicket:child />, rather than the first (I
>> doubt
>> that it's really going to be that easy though).
>>
>>
>>
>>
>> Bruno Borges wrote:
>> >
>> > Stefan, try first giving us an example of what would you like to do.
>> What
>> > I
>> > can see is that you want this:
>> >
>> > BasePage.html
>> > <html>
>> >   <body>
>> >     <h1>BasePage</h1>
>> >     <hr/>
>> >     <h3>This is my child:</h3>
>> >     <wicket:child />
>> >     <hr/>
>> >     <h3>This is my OTHER child:</h3>
>> >     <wicket:child />
>> >   </body>
>> > </html>
>> >
>> > ** Example of a child page:*
>> > ChildPage.html
>> > <html>
>> >   <body>
>> >     <wicket:extend>
>> >       <h4>ChildPage</h4>
>> >       <h5>I'm your child</h5>
>> >     </wicket:extend>
>> >   </body>
>> > </html>
>> >
>> > Now, given this html, how do you see the Java code structured? What's
>> your
>> > vision?
>> >
>> > On Nov 5, 2007 11:28 AM, Stefan Fußenegger <st...@gmx.at>
>> > wrote:
>> >
>> >>
>> >>
>> >> Eelco Hillenius wrote:
>> >> >
>> >> >> It would be quite feasible to add support for multiple overridden
>> >> >> sections using the above tag names while remaining backwards
>> >> compatible
>> >> >> with existing markup by continuing to support the old
>> <child/extends>
>> >> >> tags working the way they always have.
>> >> >
>> >> > It's kind of a predictable answer, but the best way to push new
>> ideas
>> >> > forward is to supply us with a patch, so that we can discuss some
>> >> > working code. The current committers don't see much in the idea, but
>> >> > that doesn't mean they wouldn't want to support at least the option
>> of
>> >> > plugging this in. And hey, maybe some working code convinces us :-)
>> >> >
>> >> > Eelco
>> >> >
>> >> >
>> ---------------------------------------------------------------------
>> >> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> >> > For additional commands, e-mail: users-help@wicket.apache.org
>> >> >
>> >> >
>> >> >
>> >>
>> >> Hi eelco,
>> >>
>> >> I'd love to do a proof of concept here. Admittedly, I don't know
>> wicket's
>> >> inner workings very well. But if I get some support, I'd try
>> implementing
>> >> this. I am currently looking through the code, but can't find where
>> the
>> >> transition between parent and child takes place (in other words: the
>> line
>> >> of
>> >> code that recognizes the wicket:extend tag and takes the appropriate
>> >> action). If somebody could point me to that line I would try to
>> implement
>> >> this possible new feature ... well, I'll first estimate the time
>> >> necessary
>> >> to do so and see if I can afford it ;)
>> >>
>> >> Regards
>> >>
>> >>
>> >>
>> >> -----
>> >> -------
>> >> Stefan Fußenegger
>> >> http://talk-on-tech.blogspot.com // looking for a nicer domain ;)
>> >> --
>> >> View this message in context:
>> >>
>> http://www.nabble.com/Multiple-%3Cwicket%3Achild--%3E-tags-on-a-single-base-page--tf4738673.html#a13586814
>> >> 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
>> >>
>> >>
>> >
>> >
>> > --
>> > 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/Multiple-%3Cwicket%3Achild--%3E-tags-on-a-single-base-page--tf4738673.html#a13587701
>> 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
>>
>>
> 
> ---------------------------------------------------------------------
> 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/Multiple-%3Cwicket%3Achild--%3E-tags-on-a-single-base-page--tf4738673.html#a13589908
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: Multiple tags on a single base page?

Posted by Igor Vaynberg <ig...@gmail.com>.

if i were you i would use tags other then extend and child just so you
dont conflict.

-igor


On 11/5/07, Stefan Fußenegger <st...@gmx.at> wrote:
>
> Well, what I'd like to do is what I explained in my first post. One would
> still have a one-one-relationship if it comes to files (Base.html, Base.java
> - Sub.html, Sub.java). However, a Base.html might contain more than one
> <wicket:extend />. So this no longer an exact duplicate of the parent-child
> relationship that is already specified by the java class hierarchy. It now
> would be similar to abstract method, where the abstract class specifies one
> or more extension points that are implemented by its subcasses ... abstract
> methods. There isn't a restriction, that there is only one abstract method
> per class!
>
> My proof of concept would go the probably easiest way and just link the
> first extend with the first child, the second extend with the second child,
> the third ... you got the idea ;) At a later point it might be useful to
> link them using ids (like the names of abstract methods).
>
> You could than for instance do some hierarchies like this:
>
> BaseClass - Application base class. Navigation on top, two columns with
> wicket:extend
> SectionOneBaseClass extends BaseClass - Sub-navigation in left column
> SectionOneIndex extends SectionOneBaseClass - Navigation on top,
> sub-navigation in left column and some fancy content in right column
>
> I totally agree to anybody who argues that this is already possible by other
> means. However, to me it seems to be the most natural and elegant way to do
> this.
>
> As I mentioned before, I don't know Wicket's inner workings too much, so I
> will definitely need some pointers to the right directions.
>
> My naive guess is that Wicket parses BasePage.html and looks for
> SecionOneBaseClass.html and the first <wicket:child /> as soon as it finds a
> <wicket:extend />. The idea would know be to just add a counter to this
> call, asking for the second <wicket:child />, rather than the first (I doubt
> that it's really going to be that easy though).
>
>
>
>
> Bruno Borges wrote:
> >
> > Stefan, try first giving us an example of what would you like to do. What
> > I
> > can see is that you want this:
> >
> > BasePage.html
> > <html>
> >   <body>
> >     <h1>BasePage</h1>
> >     <hr/>
> >     <h3>This is my child:</h3>
> >     <wicket:child />
> >     <hr/>
> >     <h3>This is my OTHER child:</h3>
> >     <wicket:child />
> >   </body>
> > </html>
> >
> > ** Example of a child page:*
> > ChildPage.html
> > <html>
> >   <body>
> >     <wicket:extend>
> >       <h4>ChildPage</h4>
> >       <h5>I'm your child</h5>
> >     </wicket:extend>
> >   </body>
> > </html>
> >
> > Now, given this html, how do you see the Java code structured? What's your
> > vision?
> >
> > On Nov 5, 2007 11:28 AM, Stefan Fußenegger <st...@gmx.at>
> > wrote:
> >
> >>
> >>
> >> Eelco Hillenius wrote:
> >> >
> >> >> It would be quite feasible to add support for multiple overridden
> >> >> sections using the above tag names while remaining backwards
> >> compatible
> >> >> with existing markup by continuing to support the old <child/extends>
> >> >> tags working the way they always have.
> >> >
> >> > It's kind of a predictable answer, but the best way to push new ideas
> >> > forward is to supply us with a patch, so that we can discuss some
> >> > working code. The current committers don't see much in the idea, but
> >> > that doesn't mean they wouldn't want to support at least the option of
> >> > plugging this in. And hey, maybe some working code convinces us :-)
> >> >
> >> > Eelco
> >> >
> >> > ---------------------------------------------------------------------
> >> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >> > For additional commands, e-mail: users-help@wicket.apache.org
> >> >
> >> >
> >> >
> >>
> >> Hi eelco,
> >>
> >> I'd love to do a proof of concept here. Admittedly, I don't know wicket's
> >> inner workings very well. But if I get some support, I'd try implementing
> >> this. I am currently looking through the code, but can't find where the
> >> transition between parent and child takes place (in other words: the line
> >> of
> >> code that recognizes the wicket:extend tag and takes the appropriate
> >> action). If somebody could point me to that line I would try to implement
> >> this possible new feature ... well, I'll first estimate the time
> >> necessary
> >> to do so and see if I can afford it ;)
> >>
> >> Regards
> >>
> >>
> >>
> >> -----
> >> -------
> >> Stefan Fußenegger
> >> http://talk-on-tech.blogspot.com // looking for a nicer domain ;)
> >> --
> >> View this message in context:
> >> http://www.nabble.com/Multiple-%3Cwicket%3Achild--%3E-tags-on-a-single-base-page--tf4738673.html#a13586814
> >> 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
> >>
> >>
> >
> >
> > --
> > 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/Multiple-%3Cwicket%3Achild--%3E-tags-on-a-single-base-page--tf4738673.html#a13587701
> 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
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org

Re: Multiple tags on a single base page?

Posted by Stefan Fußenegger <st...@gmx.at>.

Well, what I'd like to do is what I explained in my first post. One would
still have a one-one-relationship if it comes to files (Base.html, Base.java
- Sub.html, Sub.java). However, a Base.html might contain more than one
<wicket:extend />. So this no longer an exact duplicate of the parent-child
relationship that is already specified by the java class hierarchy. It now
would be similar to abstract method, where the abstract class specifies one
or more extension points that are implemented by its subcasses ... abstract
methods. There isn't a restriction, that there is only one abstract method
per class!

My proof of concept would go the probably easiest way and just link the
first extend with the first child, the second extend with the second child,
the third ... you got the idea ;) At a later point it might be useful to
link them using ids (like the names of abstract methods).

You could than for instance do some hierarchies like this:

BaseClass - Application base class. Navigation on top, two columns with
wicket:extend
SectionOneBaseClass extends BaseClass - Sub-navigation in left column
SectionOneIndex extends SectionOneBaseClass - Navigation on top,
sub-navigation in left column and some fancy content in right column

I totally agree to anybody who argues that this is already possible by other
means. However, to me it seems to be the most natural and elegant way to do
this.

As I mentioned before, I don't know Wicket's inner workings too much, so I
will definitely need some pointers to the right directions.

My naive guess is that Wicket parses BasePage.html and looks for
SecionOneBaseClass.html and the first <wicket:child /> as soon as it finds a
<wicket:extend />. The idea would know be to just add a counter to this
call, asking for the second <wicket:child />, rather than the first (I doubt
that it's really going to be that easy though).




Bruno Borges wrote:
> 
> Stefan, try first giving us an example of what would you like to do. What
> I
> can see is that you want this:
> 
> BasePage.html
> <html>
>   <body>
>     <h1>BasePage</h1>
>     <hr/>
>     <h3>This is my child:</h3>
>     <wicket:child />
>     <hr/>
>     <h3>This is my OTHER child:</h3>
>     <wicket:child />
>   </body>
> </html>
> 
> ** Example of a child page:*
> ChildPage.html
> <html>
>   <body>
>     <wicket:extend>
>       <h4>ChildPage</h4>
>       <h5>I'm your child</h5>
>     </wicket:extend>
>   </body>
> </html>
> 
> Now, given this html, how do you see the Java code structured? What's your
> vision?
> 
> On Nov 5, 2007 11:28 AM, Stefan Fußenegger <st...@gmx.at>
> wrote:
> 
>>
>>
>> Eelco Hillenius wrote:
>> >
>> >> It would be quite feasible to add support for multiple overridden
>> >> sections using the above tag names while remaining backwards
>> compatible
>> >> with existing markup by continuing to support the old <child/extends>
>> >> tags working the way they always have.
>> >
>> > It's kind of a predictable answer, but the best way to push new ideas
>> > forward is to supply us with a patch, so that we can discuss some
>> > working code. The current committers don't see much in the idea, but
>> > that doesn't mean they wouldn't want to support at least the option of
>> > plugging this in. And hey, maybe some working code convinces us :-)
>> >
>> > Eelco
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> > For additional commands, e-mail: users-help@wicket.apache.org
>> >
>> >
>> >
>>
>> Hi eelco,
>>
>> I'd love to do a proof of concept here. Admittedly, I don't know wicket's
>> inner workings very well. But if I get some support, I'd try implementing
>> this. I am currently looking through the code, but can't find where the
>> transition between parent and child takes place (in other words: the line
>> of
>> code that recognizes the wicket:extend tag and takes the appropriate
>> action). If somebody could point me to that line I would try to implement
>> this possible new feature ... well, I'll first estimate the time
>> necessary
>> to do so and see if I can afford it ;)
>>
>> Regards
>>
>>
>>
>> -----
>> -------
>> Stefan Fußenegger
>> http://talk-on-tech.blogspot.com // looking for a nicer domain ;)
>> --
>> View this message in context:
>> http://www.nabble.com/Multiple-%3Cwicket%3Achild--%3E-tags-on-a-single-base-page--tf4738673.html#a13586814
>> 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
>>
>>
> 
> 
> -- 
> 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/Multiple-%3Cwicket%3Achild--%3E-tags-on-a-single-base-page--tf4738673.html#a13587701
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: Multiple tags on a single base page?

Posted by Bruno Borges <br...@gmail.com>.

Stefan, try first giving us an example of what would you like to do. What I
can see is that you want this:

BasePage.html
<html>
  <body>
    <h1>BasePage</h1>
    <hr/>
    <h3>This is my child:</h3>
    <wicket:child />
    <hr/>
    <h3>This is my OTHER child:</h3>
    <wicket:child />
  </body>
</html>

** Example of a child page:*
ChildPage.html
<html>
  <body>
    <wicket:extend>
      <h4>ChildPage</h4>
      <h5>I'm your child</h5>
    </wicket:extend>
  </body>
</html>

Now, given this html, how do you see the Java code structured? What's your
vision?

On Nov 5, 2007 11:28 AM, Stefan Fußenegger <st...@gmx.at>
wrote:

>
>
> Eelco Hillenius wrote:
> >
> >> It would be quite feasible to add support for multiple overridden
> >> sections using the above tag names while remaining backwards compatible
> >> with existing markup by continuing to support the old <child/extends>
> >> tags working the way they always have.
> >
> > It's kind of a predictable answer, but the best way to push new ideas
> > forward is to supply us with a patch, so that we can discuss some
> > working code. The current committers don't see much in the idea, but
> > that doesn't mean they wouldn't want to support at least the option of
> > plugging this in. And hey, maybe some working code convinces us :-)
> >
> > Eelco
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > For additional commands, e-mail: users-help@wicket.apache.org
> >
> >
> >
>
> Hi eelco,
>
> I'd love to do a proof of concept here. Admittedly, I don't know wicket's
> inner workings very well. But if I get some support, I'd try implementing
> this. I am currently looking through the code, but can't find where the
> transition between parent and child takes place (in other words: the line
> of
> code that recognizes the wicket:extend tag and takes the appropriate
> action). If somebody could point me to that line I would try to implement
> this possible new feature ... well, I'll first estimate the time necessary
> to do so and see if I can afford it ;)
>
> Regards
>
>
>
> -----
> -------
> Stefan Fußenegger
> http://talk-on-tech.blogspot.com // looking for a nicer domain ;)
> --
> View this message in context:
> http://www.nabble.com/Multiple-%3Cwicket%3Achild--%3E-tags-on-a-single-base-page--tf4738673.html#a13586814
> 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
>
>


-- 
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: Multiple tags on a single base page?

Posted by Stefan Fußenegger <st...@gmx.at>.


Eelco Hillenius wrote:
> 
>> It would be quite feasible to add support for multiple overridden
>> sections using the above tag names while remaining backwards compatible
>> with existing markup by continuing to support the old <child/extends>
>> tags working the way they always have.
> 
> It's kind of a predictable answer, but the best way to push new ideas
> forward is to supply us with a patch, so that we can discuss some
> working code. The current committers don't see much in the idea, but
> that doesn't mean they wouldn't want to support at least the option of
> plugging this in. And hey, maybe some working code convinces us :-)
> 
> Eelco
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
> 
> 
> 

Hi eelco,

I'd love to do a proof of concept here. Admittedly, I don't know wicket's
inner workings very well. But if I get some support, I'd try implementing
this. I am currently looking through the code, but can't find where the
transition between parent and child takes place (in other words: the line of
code that recognizes the wicket:extend tag and takes the appropriate
action). If somebody could point me to that line I would try to implement
this possible new feature ... well, I'll first estimate the time necessary
to do so and see if I can afford it ;)

Regards



-----
-------
Stefan Fußenegger
http://talk-on-tech.blogspot.com // looking for a nicer domain ;)
-- 
View this message in context: http://www.nabble.com/Multiple-%3Cwicket%3Achild--%3E-tags-on-a-single-base-page--tf4738673.html#a13586814
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: Multiple tags on a single base page?

Posted by Eelco Hillenius <ee...@gmail.com>.

> It would be quite feasible to add support for multiple overridden
> sections using the above tag names while remaining backwards compatible
> with existing markup by continuing to support the old <child/extends>
> tags working the way they always have.

It's kind of a predictable answer, but the best way to push new ideas
forward is to supply us with a patch, so that we can discuss some
working code. The current committers don't see much in the idea, but
that doesn't mean they wouldn't want to support at least the option of
plugging this in. And hey, maybe some working code convinces us :-)

Eelco

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org

RE: Multiple tags on a single base page?

Posted by Chris Colman <ch...@stepaheadsoftware.com>.

> I found an excellent thread in the archives that explains this topic
very
> well - I swear I searched before, but obviously with the wrong
keywords ;)
>
>
http://www.nabble.com/Multiple-wicket%3Achild-tags-in-the-same-page-tf37
75143.html
>
> Multiple child/extends pairs (where you have to see such a pair as an
> abstract method rather than a baseclass/subclass relationship) could
help
> to combine the advantages of both approaches. However, its not a
feature
> that would improve wickets functionality and probably not worth the
effort
> of implementing it ... though it might be convenient.

I was the original poster of that topic (although I made a few more
replies that must have ended up in a different topic).
I still think that viewing the child/extends pairs as abstracts methods
instead of baseclass/sublass relationships is an ultimately cool model
that Wicket will eventually support one day because now I see that I'm
not the only one who has seen its potential.

I think the belief that the concept of multiple overridden sections in a
page constitutes or is analogous to multiple inheritance is incorrect.
Looking at the overridden sections as abstract methods (of which you can
have many per class in Java) makes a lot of sense. It's a very clean
model and totally analogous to a single inheritance model as per Java:
each page or panel still only has a single page or panel (analogous to
class) from which it extends. 

The only requirement would be that if you do choose to support multiple
abstract/overridden sections you would need to provide identifiers (just
like an abstract method has a name) so that the 'compiler' (wicket)
knows which section in a superclass an extended class section is
overriding. In pages where only one section is overridden no identifiers
would be necessary and so existing markup works without change, the way
it does now.

I also made comment that I think the 'child/extends' nomenclature was
kinda wrong sounding. It doesn't seem like a natural fit. One of the
things we try to teach the OO youngsters is that inheritance is very
different to a parent/child relationship. Parent/Child is an association
relationship where as inheritance is more of an 'extension',
'derivation' or 'specialization'. 

Too late for changing this now but that's never stopped me from making a
pedantic contribution in the past so why stop now? ;-)

In wicket we already specify the superclass of particular page markup
via the 'extends' relationship between the corresponding Java classes so
there's no need to use the 'extends' term in defining the individual
overridable sections in the markup. Perhaps that tag might have been
called 'abstract' in the base page and 'override' in the extended page
and declared like:

<wicket:abstract id=sidemenubar>
	Derived pages will supply their own side bar menu.
[Abstract is a great word here because it indicates that no definition
exists here - it's just declaring a placeholder - and it's perfectly
analogous to the Java abstract keyword]

</wicket:abstract id=sidemenubar>

'Funky divider' that is common throughout the entire site goes in here

<wicket:abstract id=body>
	Derived pages will supply their own body
</wicket:abstract id=body>


In the derived (extended) page markups:


<wicket:override id=sidemenubar>
	This is the side menu bar
[A nice thing about the word override is that it is perfectly analogous
to the @Override annotation in Java]
</wicket:override id=sidemenubar>

'Funky divider' comes from the base class - this section is ignored

<wicket:override id=body>
	This is the side menu bar
</wicket:override id=body>

One reason that support for multiple overridden sections in a page is so
useful is that it is often desirable for a whole category of pages, each
with a different body section, to have a common side bar menu - that is
not common throughout the entire site - just common for that range of
pages - yet the 'Funky divider' IS common to the entire site and so I
only want to define it in one place - in the base page. I am sure there
are many other examples of its usefulness which is probably why the
topic arises from the ashes like a phoenix on a regular basis. :)


It would be quite feasible to add support for multiple overridden
sections using the above tag names while remaining backwards compatible
with existing markup by continuing to support the old <child/extends>
tags working the way they always have.

> 
> I hope I got it right.
> 

Same here!

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org

Re: Multiple tags on a single base page?

Posted by Stefan Fußenegger <st...@gmx.at>.

Thanks for that awesomely fast reply!


I found an excellent thread in the archives that explains this topic very
well - I swear I searched before, but obviously with the wrong keywords ;)

http://www.nabble.com/Multiple-wicket%3Achild-tags-in-the-same-page-tf3775143.html

To sum it up for those that came across this thread looking for the same
answer: there are two different solutions to this kind of problem:

1. without child-extends-tags using "abstract tags" like this:

BasePage() {
// maybe you want to doublecheck if the returned component has the expected
id
add(createComponent("left");
add(createComponent("right");
}
abstract Component createComponent(String id)

2. using child-extends-tags using fragments in the html of the subclass

The obvious disadvantage of the latter is its need for a html page for every
page you create. If you only want to add 2 existing panels (or components),
you will find yourself copying a template page over and over again that only
has two fragments, each with a <wicket:component />. Its advantage is, that
one can have the contents of both columns on the same page, which is
convenient if there is some JS "interaction" between both panels ... of if
your html/css designer needs to have both on the same page for proper
validation.

Multiple child/extends pairs (where you have to see such a pair as an
abstract method rather than a baseclass/subclass relationship) could help to
combine the advantages of both approaches. However, its not a feature that
would improve wickets functionality and probably not worth the effort of
implementing it ... though it might be convenient. 

I hope I got it right.

Best regards,

----
Stefan Fußenegger
http://talk-on-tech.blogspot.com // looking for a nicer domain ;)



igor.vaynberg wrote:
> 
> this has been discussed multiple times on this list, search the
> archives. the conclusion has always been that what you want can be
> accomplished by factory methods on the basepage that generate panels.
> 
> -igor
> 
> 
> On 11/2/07, Stefan Fußenegger <st...@gmx.at> wrote:
>>
>> Hi folks,
>>
>> I just stumbled on a situation where it would be useful to have two or
>> more
>> <wicket:child /> tags in a base page. Just consider a layout that
>> consists
>> of the usual footer, header, navigation, and content parts. But now, the
>> content should be arranged in two columns, e.g. two different <div />s.
>>
>> To give a short example, the BasePage.html cloud look like this
>>
>> --------
>> <body>
>>
>> <!-- some layout markup -->
>>
>> <div class="content_left">
>> <wicket:child />
>> </div>
>>
>> <!-- more layout markup -->
>>
>> <div class="content_rigt">
>> <wicket:child />
>> </div>
>>
>> <!-- even more layout markup -->
>> </body>
>> --------
>>
>> And the Child.html markup would look like this:
>>
>> --------
>> <body>
>>
>> <div class="content_left">
>> <wicket:extend>
>> <!-- content of left column (first child) goes here -->
>> </wicket:extend>
>> </div>
>>
>> <div class="content_rigt">
>> <wicket:extend>
>> <!-- content of right column (second child) goes here -->
>> </wicket:extend>
>> </div>
>> </body>
>> --------
>>
>> Wouldn't that be a desirable feature? I tried to run the above example
>> expecting to get an exception. The second wicket:child/wicket:extend pair
>> was happily ignored though.
>>
>> Best regards, Stefan
>> --
>> View this message in context:
>> http://www.nabble.com/Multiple-%3Cwicket%3Achild--%3E-tags-on-a-single-base-page--tf4738673.html#a13551448
>> 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
>>
>>
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
> 
> 
> 

-- 
View this message in context: http://www.nabble.com/Multiple-%3Cwicket%3Achild--%3E-tags-on-a-single-base-page--tf4738673.html#a13553489
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: Multiple tags on a single base page?

Posted by Igor Vaynberg <ig...@gmail.com>.

this has been discussed multiple times on this list, search the
archives. the conclusion has always been that what you want can be
accomplished by factory methods on the basepage that generate panels.

-igor


On 11/2/07, Stefan Fußenegger <st...@gmx.at> wrote:
>
> Hi folks,
>
> I just stumbled on a situation where it would be useful to have two or more
> <wicket:child /> tags in a base page. Just consider a layout that consists
> of the usual footer, header, navigation, and content parts. But now, the
> content should be arranged in two columns, e.g. two different <div />s.
>
> To give a short example, the BasePage.html cloud look like this
>
> --------
> <body>
>
> <!-- some layout markup -->
>
> <div class="content_left">
> <wicket:child />
> </div>
>
> <!-- more layout markup -->
>
> <div class="content_rigt">
> <wicket:child />
> </div>
>
> <!-- even more layout markup -->
> </body>
> --------
>
> And the Child.html markup would look like this:
>
> --------
> <body>
>
> <div class="content_left">
> <wicket:extend>
> <!-- content of left column (first child) goes here -->
> </wicket:extend>
> </div>
>
> <div class="content_rigt">
> <wicket:extend>
> <!-- content of right column (second child) goes here -->
> </wicket:extend>
> </div>
> </body>
> --------
>
> Wouldn't that be a desirable feature? I tried to run the above example
> expecting to get an exception. The second wicket:child/wicket:extend pair
> was happily ignored though.
>
> Best regards, Stefan
> --
> View this message in context: http://www.nabble.com/Multiple-%3Cwicket%3Achild--%3E-tags-on-a-single-base-page--tf4738673.html#a13551448
> 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
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org

Re: Multiple tags on a single base page?

Posted by Bruno Borges <br...@gmail.com>.

Thanks for giving the best overview of my thoughts Igor. Are you reading my
mind?



On Nov 7, 2007 3:50 PM, Igor Vaynberg <ig...@gmail.com> wrote:

> let me weigh in with my thoughts on this.
>
> a big problem with markup inheritance is the possibility of id collissions
>
> for example
>
> class basepage extends webpage {
>  public basepage() {
>    add(new label("label"));
>  }
> }
>
> class concretepage extends basepage {
>  public concretepage() {
>    add(new label("label"));
>  }
> }
>
> basepage: <body><div wicket:id="label"></div><wicket:child></body>
> concretepage: <wicket:extend><div wicket:id="label"></div></wicket:extend>
>
> now what you are proposing here makes this collission possibility
> significantly higher because essentially i CANNOT even have something
> like this:
>
> <wicket:implements id="foo1"><div wicket:id="label"></wicket:implements>
> <wicket:implements id="foo2"><div wicket:id="label"></wicket:implements>
>
> even though to me it looks like the nasting of foo1 and foo2 are
> seperate so i should be able to have a direct child with the same id
> in both....but i cannot.
>
> a lot of people are saying that this can be implemented with panels,
> and that is true. but actually implementing this with fragments will
> make it look very similar to this new strategy and does not have the
> id collission problem, because components ARE nested in two different
> containers:
>
> class basepage extends webpage {
>  Fragment templateFoo1(String id) { return new emptyfragment(id); }
>  Fragment templateFoo2(String id) { return new emptyfragment(id); }
> }
>
> <wicket:fragment wicket:id="foo1"><div
> wicket:id="label"></wicket:fragment>
> <wicket:fragment wicket:id="foo2"><div
> wicket:id="label"></wicket:fragment>
>
> thoughts?
>
> -igor
>
>
>
>
> On 11/2/07, Stefan Fußenegger <st...@gmx.at> wrote:
> >
> > Hi folks,
> >
> > I just stumbled on a situation where it would be useful to have two or
> more
> > <wicket:child /> tags in a base page. Just consider a layout that
> consists
> > of the usual footer, header, navigation, and content parts. But now, the
> > content should be arranged in two columns, e.g. two different <div />s.
> >
> > To give a short example, the BasePage.html cloud look like this
> >
> > --------
> > <body>
> >
> > <!-- some layout markup -->
> >
> > <div class="content_left">
> > <wicket:child />
> > </div>
> >
> > <!-- more layout markup -->
> >
> > <div class="content_rigt">
> > <wicket:child />
> > </div>
> >
> > <!-- even more layout markup -->
> > </body>
> > --------
> >
> > And the Child.html markup would look like this:
> >
> > --------
> > <body>
> >
> > <div class="content_left">
> > <wicket:extend>
> > <!-- content of left column (first child) goes here -->
> > </wicket:extend>
> > </div>
> >
> > <div class="content_rigt">
> > <wicket:extend>
> > <!-- content of right column (second child) goes here -->
> > </wicket:extend>
> > </div>
> > </body>
> > --------
> >
> > Wouldn't that be a desirable feature? I tried to run the above example
> > expecting to get an exception. The second wicket:child/wicket:extend
> pair
> > was happily ignored though.
> >
> > Best regards, Stefan
> > --
> > View this message in context:
> http://www.nabble.com/Multiple-%3Cwicket%3Achild--%3E-tags-on-a-single-base-page--tf4738673.html#a13551448
> > 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
> >
> >
>
> ---------------------------------------------------------------------
> 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: Multiple tags on a single base page?

Posted by Igor Vaynberg <ig...@gmail.com>.

read my previous reply more carefuly, instead of

abstract Component getTemplateOne(String id);

you can simply do: Component getTemplateOne(String id) { return new
EmptyPanel(id); }

now you have a "non-required" override of any part of markup's template...

-igor


On Nov 7, 2007 10:51 AM, Chris Colman <ch...@stepaheadsoftware.com> wrote:
> > a lot of people are saying that this can be implemented with panels,
> > and that is true. but actually implementing this with fragments will
> > make it look very similar to this new strategy and does not have the
> > id collission problem, because components ARE nested in two different
> > containers:
>
> I've never used fragments but I just read up on them...
>
> I may be wrong but it looks as if you have to define all possible
> fragments that might appear in a page to that page. It doesn't seem to
> follow the natural, organic flow of markup inheritance where a base page
> can be enhanced by substituting base a page section with markup defined
> in derived/extended pages - that only happens with the child/extends
> feature from my understanding.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org

Re: Multiple tags on a single base page?

Posted by Igor Vaynberg <ig...@gmail.com>.

or you can just use a factory that lets you create transparent borders :)

-igor


On Nov 7, 2007 12:05 PM, Chris Colman <ch...@stepaheadsoftware.com> wrote:
> Presumably the coded work arounds that don't rely on child/extends mean
> that the structural markup of each page is used instead of just that of
> the base page - and that would spell maintenance issues. Without using
> child/extend then ALL the structural markup in each page is used for
> each render - NOTHING is pulled from the base page markup (kind of makes
> me wonder why we need base page markup if not using child/extend - but
> that's another topic!).
>
> A change of layout structure would mean changing all page markups - yuck
> - or do you guys not care about your graphics designers - "arh, that's
> their problem if they want to do a site wide change!"
>
> I think the fundamental thing that most people are missing is that each
> component must be well formed XHTML, complete and self contained. If it
> starts a <div> (or <table>) then it must also end it. Divs (and tables)
> are the basic structural elements of markup.
>
> One component can't be the start of a structural span of markup, the
> next few components content sections for that span and then the last
> component ends the structural span - that is not possible because each
> component must be well formed and complete.
>
> So this infers that structural markup typically is stored in page markup
> and "wraps" markup that inserts various self contained components.
>
> Now here's the thing: without using child/extends then that structural
> markup must be carefully defined in EVERY page markup because wicket
> does not do the funky inheritance merging when you don't use the
> child/extends tag.
>
> So if you want to change a border in between two components you must
> change it in EVERY page markup. That would suck.
>
> Alternatively, if you do use the current child/extend you end up having
> to bang multiple components into the overridden section which means that
> you also bang in the border that exists between them - so now the border
> markup is duplicated many times.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org

RE: Multiple tags on a single base page?

Posted by Chris Colman <ch...@stepaheadsoftware.com>.

Presumably the coded work arounds that don't rely on child/extends mean
that the structural markup of each page is used instead of just that of
the base page - and that would spell maintenance issues. Without using
child/extend then ALL the structural markup in each page is used for
each render - NOTHING is pulled from the base page markup (kind of makes
me wonder why we need base page markup if not using child/extend - but
that's another topic!).

A change of layout structure would mean changing all page markups - yuck
- or do you guys not care about your graphics designers - "arh, that's
their problem if they want to do a site wide change!"

I think the fundamental thing that most people are missing is that each
component must be well formed XHTML, complete and self contained. If it
starts a <div> (or <table>) then it must also end it. Divs (and tables)
are the basic structural elements of markup.

One component can't be the start of a structural span of markup, the
next few components content sections for that span and then the last
component ends the structural span - that is not possible because each
component must be well formed and complete.

So this infers that structural markup typically is stored in page markup
and "wraps" markup that inserts various self contained components.

Now here's the thing: without using child/extends then that structural
markup must be carefully defined in EVERY page markup because wicket
does not do the funky inheritance merging when you don't use the
child/extends tag.

So if you want to change a border in between two components you must
change it in EVERY page markup. That would suck.

Alternatively, if you do use the current child/extend you end up having
to bang multiple components into the overridden section which means that
you also bang in the border that exists between them - so now the border
markup is duplicated many times.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org

Re: Multiple tags on a single base page?

Posted by Bruno Borges <br...@gmail.com>.

You are wrong. I have a component (Panel) that has a method to return a
Fragment. This component returns a default implementation of that Fragment,
but pages can override that Fragment.

CRUDFormPanel extends Panel {
    protected Fragment newFormFields(String id, Form form) {
        if (property == null)
            return null;

        Fragment f = new Fragment(id, "defaultFormFields",
ListFormPanel.this);
        RequiredTextField desc = new RequiredTextField("property",
                new PropertyModel(form.getModel(), property));
        desc.add(StringValidator.maximumLength(255));

        f.add(desc);
        f.add(new Label("propertyLabel", getString("propertyLabel")));

        form.add(new ObjectExistanceValidator(service, desc, property));

        return f;
    }

    .... // more code
}

Pages that want to have more fields in this form, can provide another
Fragment.

MyCustomPage extends WebPage {
    MyCustomPage() {
      add(new CRUDFormPanel("panel") {
    protected Fragment newFormFields(String id, Form form) {
            Fragment f = new Fragment(id, "customFormFields",
MyCustomPage.this);

            RequiredTextField field = new
RequiredTextField("anotherProperty",
                new PropertyModel(form.getModel(), "anotherProperty"));
            desc.add(StringValidator.maximumLength(50));

            f.add(field);

            form.add(new ObjectExistanceValidator(service, desc, property));

            return f;
        }
      });
    }
}

This is how I override tags with vanilla Wicket. Do we really need another
markup?!

On Nov 7, 2007 4:51 PM, Chris Colman <ch...@stepaheadsoftware.com> wrote:

> > a lot of people are saying that this can be implemented with panels,
> > and that is true. but actually implementing this with fragments will
> > make it look very similar to this new strategy and does not have the
> > id collission problem, because components ARE nested in two different
> > containers:
>
> I've never used fragments but I just read up on them...
>
> I may be wrong but it looks as if you have to define all possible
> fragments that might appear in a page to that page. It doesn't seem to
> follow the natural, organic flow of markup inheritance where a base page
> can be enhanced by substituting base a page section with markup defined
> in derived/extended pages - that only happens with the child/extends
> feature from my understanding.
>
> ---------------------------------------------------------------------
> 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: Multiple tags on a single base page?

Posted by Chris Colman <ch...@stepaheadsoftware.com>.

> a lot of people are saying that this can be implemented with panels,
> and that is true. but actually implementing this with fragments will
> make it look very similar to this new strategy and does not have the
> id collission problem, because components ARE nested in two different
> containers:

I've never used fragments but I just read up on them...

I may be wrong but it looks as if you have to define all possible
fragments that might appear in a page to that page. It doesn't seem to
follow the natural, organic flow of markup inheritance where a base page
can be enhanced by substituting base a page section with markup defined
in derived/extended pages - that only happens with the child/extends
feature from my understanding.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org

Re: Multiple tags on a single base page?

Posted by Al Maw <wi...@almaw.com>.

Igor Vaynberg wrote:
> ...  actually implementing this with fragments will
> make it look very similar to this new strategy and does not have the
> id collission problem, because components ARE nested in two different
> containers:
> 
> class basepage extends webpage {
>   Fragment templateFoo1(String id) { return new emptyfragment(id); }
>   Fragment templateFoo2(String id) { return new emptyfragment(id); }
> }
> 
> <wicket:fragment wicket:id="foo1"><div wicket:id="label"></wicket:fragment>
> <wicket:fragment wicket:id="foo2"><div wicket:id="label"></wicket:fragment>
> 
> thoughts?

I've finally got around to reading (most) of this insanely long thread.

My first thought was, "why don't you just use Fragments for this?"

Obviously the person who extends BasePage needs to know what fragment 
IDs they should be adding in.

But then, with the proposed extra <wicket:abstract> tag, they'd need to 
know what <wicket:inherit> IDs to be using, so I can't see much 
difference here.

The only issue is that you need to actually add some code, which you 
don't with a pure tag-based solution.

On the other hand, you probably need to add some code anyway - I can't 
think of many use-cases where you'd want to only put mark-up in one or 
more of your <wicket:inherit> blocks that isn't better handled using 
localization with <wicket:message> keys being overridden for the various 
pages.

Regards,

Al

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org

Re: Multiple tags on a single base page?

Posted by Igor Vaynberg <ig...@gmail.com>.

let me weigh in with my thoughts on this.

a big problem with markup inheritance is the possibility of id collissions

for example

class basepage extends webpage {
  public basepage() {
    add(new label("label"));
  }
}

class concretepage extends basepage {
  public concretepage() {
    add(new label("label"));
  }
}

basepage: <body><div wicket:id="label"></div><wicket:child></body>
concretepage: <wicket:extend><div wicket:id="label"></div></wicket:extend>

now what you are proposing here makes this collission possibility
significantly higher because essentially i CANNOT even have something
like this:

<wicket:implements id="foo1"><div wicket:id="label"></wicket:implements>
<wicket:implements id="foo2"><div wicket:id="label"></wicket:implements>

even though to me it looks like the nasting of foo1 and foo2 are
seperate so i should be able to have a direct child with the same id
in both....but i cannot.

a lot of people are saying that this can be implemented with panels,
and that is true. but actually implementing this with fragments will
make it look very similar to this new strategy and does not have the
id collission problem, because components ARE nested in two different
containers:

class basepage extends webpage {
  Fragment templateFoo1(String id) { return new emptyfragment(id); }
  Fragment templateFoo2(String id) { return new emptyfragment(id); }
}

<wicket:fragment wicket:id="foo1"><div wicket:id="label"></wicket:fragment>
<wicket:fragment wicket:id="foo2"><div wicket:id="label"></wicket:fragment>

thoughts?

-igor




On 11/2/07, Stefan Fußenegger <st...@gmx.at> wrote:
>
> Hi folks,
>
> I just stumbled on a situation where it would be useful to have two or more
> <wicket:child /> tags in a base page. Just consider a layout that consists
> of the usual footer, header, navigation, and content parts. But now, the
> content should be arranged in two columns, e.g. two different <div />s.
>
> To give a short example, the BasePage.html cloud look like this
>
> --------
> <body>
>
> <!-- some layout markup -->
>
> <div class="content_left">
> <wicket:child />
> </div>
>
> <!-- more layout markup -->
>
> <div class="content_rigt">
> <wicket:child />
> </div>
>
> <!-- even more layout markup -->
> </body>
> --------
>
> And the Child.html markup would look like this:
>
> --------
> <body>
>
> <div class="content_left">
> <wicket:extend>
> <!-- content of left column (first child) goes here -->
> </wicket:extend>
> </div>
>
> <div class="content_rigt">
> <wicket:extend>
> <!-- content of right column (second child) goes here -->
> </wicket:extend>
> </div>
> </body>
> --------
>
> Wouldn't that be a desirable feature? I tried to run the above example
> expecting to get an exception. The second wicket:child/wicket:extend pair
> was happily ignored though.
>
> Best regards, Stefan
> --
> View this message in context: http://www.nabble.com/Multiple-%3Cwicket%3Achild--%3E-tags-on-a-single-base-page--tf4738673.html#a13551448
> 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
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org