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 <[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]
> 
> 
> ---------------------------------------------------------------------
> 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#a13605970
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