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