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 <[EMAIL PROTECTED]> 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
>> <[EMAIL PROTECTED]>
>> > > 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: [EMAIL PROTECTED]
>> > >> > For additional commands, e-mail: [EMAIL PROTECTED]
>> > >> >
>> > >> >
>> > >> >
>> > >>
>> > >> 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: [EMAIL PROTECTED]
>> > >> For additional commands, e-mail: [EMAIL PROTECTED]
>> > >>
>> > >>
>> > >
>> > >
>> > > --
>> > > Bruno Borges
>> > > blog.brunoborges.com.br
>> > > +55 1185657739
>> > >
>> > > "The glory of great men should always be
>> > > measured by the means they have used to
>> > > acquire it."
>> > > - Francois de La Rochefoucauld
>> > >
>> > >
>> >
>> >
>> > -----
>> > -------
>> > 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: [EMAIL PROTECTED]
>> > For additional commands, e-mail: [EMAIL PROTECTED]
>> >
>> >
>> 
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 
> 


-----
-------
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to