subject:"RE\: Multiple <wicket\:child \/> tags on a single base page\?"

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

RE: Multiple wicket:child / tags on a single base page?


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: [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#a13623108
Sent from the Wicket - User mailing list archive at Nabble.com.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Multiple wicket:child / tags on a single base page?

2007-11-07 Thread Johan Compagner

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

RE: Multiple wicket:child / tags on a single base page?

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

Re: Multiple wicket:child / tags on a single base page?

2007-11-07 Thread Mats Norén

On Nov 7, 2007 11:31 AM, Mats Norén [EMAIL PROTECTED] 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Multiple wicket:child / tags on a single base page?

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

RE: Multiple wicket:child / tags on a single base page?

 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: [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-

Re: Multiple wicket:child / tags on a single base page?


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 [EMAIL PROTECTED] 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: [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#a13626055
Sent from the Wicket - User mailing list archive at Nabble.com.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Multiple wicket:child / tags on a single base page?

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 [EMAIL PROTECTED] 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: [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

RE: Multiple wicket:child / tags on a single base page?

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

RE: Multiple wicket:child / tags on a single base page?

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

Re: Multiple wicket:child / tags on a single base page?


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





-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Multiple wicket:child / tags on a single base page?


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: [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#a13631624
Sent from the Wicket - User mailing list archive at Nabble.com.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Multiple wicket:child / tags on a single base page?

2007-11-07 Thread John Krasnay

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

Re: Multiple wicket:child / tags on a single base page?

2007-11-07 Thread Johan Compagner

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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 
  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

Re: Multiple wicket:child / tags on a single base page?

2007-11-07 Thread Johan Compagner

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

Re: Multiple wicket:child / tags on a single base page?


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 [EMAIL PROTECTED]
 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 [EMAIL PROTECTED] 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

Re: Multiple wicket:child / tags on a single base page?

2007-11-07 Thread Scott Swank

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

Re: Multiple wicket:child / tags on a single base page?

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 [EMAIL PROTECTED]
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 [EMAIL PROTECTED] 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

RE: Multiple wicket:child / tags on a single base page?

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

RE: Multiple wicket:child / tags on a single base page?

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

Re: Multiple wicket:child / tags on a single base page?

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



On Nov 7, 2007 3:50 PM, Igor Vaynberg [EMAIL PROTECTED] 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: bodydiv wicket:id=label/divwicket:child/body
 concretepage: wicket:extenddiv 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=foo1div wicket:id=label/wicket:implements
 wicket:implements id=foo2div 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 bothbut 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=foo1div
 wicket:id=label/wicket:fragment
 wicket:fragment wicket:id=foo2div
 wicket:id=label/wicket:fragment

 thoughts?

 -igor




 On 11/2/07, Stefan Fußenegger [EMAIL PROTECTED] 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: [EMAIL PROTECTED]
  For additional commands, e-mail: [EMAIL PROTECTED]
 
 

 -
 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

Re: Multiple wicket:child / tags on a single base page?


 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 [EMAIL PROTECTED]
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 [EMAIL PROTECTED]
  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 [EMAIL PROTECTED] wrote:
   Hmm...I'm interested in seeing the difference as well. I would love

RE: Multiple wicket:child / tags on a single base page?

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

Re: Multiple wicket:child / tags on a single base page?

2007-11-07 Thread Sebastiaan van Erk


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=anythingPlace 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 [EMAIL PROTECTED] 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

Re: Multiple wicket:child / tags on a single base page?

2007-11-07 Thread John Krasnay

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

RE: Multiple wicket:child / tags on a single base page?


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.

RE: Multiple wicket:child / tags on a single base page?

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

Re: Multiple wicket:child / tags on a single base page?

2007-11-07 Thread Jan Kriesten


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

Re: Multiple wicket:child / tags on a single base page?

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 [EMAIL PROTECTED] 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.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Multiple wicket:child / tags on a single base page?


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

RE: Multiple wicket:child / tags on a single base page?

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

RE: Multiple wicket:child / tags on a single base page?

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

Re: Multiple wicket:child / tags on a single base page?


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

eg: html:
...
div wicket:id=anythingPlace 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 [EMAIL PROTECTED] 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]






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

Re: Multiple wicket:child / tags on a single base page?


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: [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#a13634545
Sent from the Wicket - User mailing list archive at Nabble.com.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Multiple wicket:child / tags on a single base page?

On Nov 7, 2007 11:19 AM, Scott Swank [EMAIL PROTECTED] 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Multiple wicket:child / tags on a single base page?




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

Re: Multiple wicket:child / tags on a single base page?

2007-11-07 Thread Sebastiaan van Erk


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



smime.p7s
Description: S/MIME Cryptographic Signature

Re: Multiple wicket:child / tags on a single base page?

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



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Multiple wicket:child / tags on a single base page?

On Nov 7, 2007 11:22 AM, Chris Colman [EMAIL PROTECTED] 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Multiple wicket:child / tags on a single base page?

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 [EMAIL PROTECTED] wrote:
 On Nov 7, 2007 11:19 AM, Scott Swank [EMAIL PROTECTED] 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: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Multiple wicket:child / tags on a single base page?

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

-igor


On Nov 7, 2007 12:05 PM, Chris Colman [EMAIL PROTECTED] 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: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Multiple wicket:child / tags on a single base page?

On Nov 7, 2007 1:39 PM, Eelco Hillenius [EMAIL PROTECTED] 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: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Multiple wicket:child / tags on a single base page?

On Nov 7, 2007 1:32 PM, Igor Vaynberg [EMAIL PROTECTED] 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Multiple wicket:child / tags on a single base page?

On Nov 7, 2007 2:02 PM, Igor Vaynberg [EMAIL PROTECTED] wrote:
 On Nov 7, 2007 1:39 PM, Eelco Hillenius [EMAIL PROTECTED] 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Multiple wicket:child / tags on a single base page?


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

Re: Multiple wicket:child / tags on a single base page?

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

-igor


On Nov 7, 2007 2:50 PM, Eelco Hillenius [EMAIL PROTECTED] 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: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Multiple wicket:child / tags on a single base page?


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 [EMAIL PROTECTED] 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: [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]

Re: Multiple wicket:child / tags on a single base page?

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

Re: Multiple wicket:child / tags on a single base page?

2007-11-07 Thread Sebastiaan van Erk


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




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



smime.p7s
Description: S/MIME Cryptographic Signature

RE: Multiple wicket:child / tags on a single base page?

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

Re: Multiple wicket:child / tags on a single base page?

2007-11-07 Thread Al Maw


Chris Colman wrote:

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

RE: Multiple wicket:child / tags on a single base page?

2007-11-06 Thread Chris Colman

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

RE: Multiple wicket:child / tags on a single base page?

2007-11-06 Thread Chris Colman

 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

Re: Multiple wicket:child / tags on a single base page?

2007-11-06 Thread Johan Compagner


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

2007-11-06 Thread John Krasnay

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

Re: Multiple wicket:child / tags on a single base page?

2007-11-06 Thread Stefan Fußenegger


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: [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#a13609607
Sent from the Wicket - User mailing list archive at Nabble.com.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Multiple wicket:child / tags on a single base page?

2007-11-06 Thread Stefan Fußenegger

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

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Multiple wicket:child / tags on a single base page?

2007-11-06 Thread Evan Chooly

On Nov 6, 2007 11:30 AM, Stefan Fußenegger [EMAIL PROTECTED] 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

Sent from the Wicket - User mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Multiple wicket:child / tags on a single base page?

2007-11-05 Thread Bruno Borges

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 [EMAIL PROTECTED] 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 wicket:child / tags on a single base page?

2007-11-05 Thread Johan Compagner

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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 wicket:child / tags on a single base page?

2007-11-05 Thread Bruno Borges

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
h1BasePage/h1
hr/
h3This is my child:/h3
wicket:child /
hr/
h3This is my OTHER child:/h3
wicket:child /
  /body
/html

** Example of a child page:*
ChildPage.html
html
  body
wicket:extend
  h4ChildPage/h4
  h5I'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

Re: Multiple wicket:child / tags on a single base page?

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
h1BasePage/h1
hr/
h3This is my child:/h3
wicket:child /
hr/
h3This is my OTHER child:/h3
wicket:child /
/body
/html

** Example of a child page:*
ChildPage.html
html
body
wicket:extend
h4ChildPage/h4
h5I'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

-
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

-
To

Re: Multiple wicket:child / tags on a single base page?

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

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

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Multiple wicket:child / tags on a single base page?

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 [EMAIL PROTECTED] wrote:

You could than for instance do some hierarchies like this:

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.

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
h1BasePage/h1
hr/
h3This is my child:/h3
wicket:child /
hr/
h3This is my OTHER child:/h3
wicket:child /
/body
/html

** Example of a child page:*
ChildPage.html
html
body
wicket:extend
h4ChildPage/h4
h5I'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:

Eelco

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Hi eelco,

Regards

-
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 ;)
--

Re: Multiple wicket:child / tags on a single base page?

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 [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:

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
h1BasePage/h1
hr/
h3This is my child:/h3
wicket:child /
hr/
h3This is my OTHER child:/h3
wicket:child /
/body
/html

** Example of a child page:*
ChildPage.html
html
body
wicket:extend
h4ChildPage/h4
h5I'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

Re: Multiple wicket:child / tags on a single base page?

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

-igor

On 11/5/07, Stefan Fußenegger [EMAIL PROTECTED] 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 [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:

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
h1BasePage/h1
hr/
h3This is my child:/h3
wicket:child /
hr/
h3This is my OTHER child:/h3
wicket:child /
/body
/html

** Example of a child page:*
ChildPage.html
html
body
wicket:extend
h4ChildPage/h4
h5I'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.

Re: Multiple wicket:child / tags on a single base page?


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 [EMAIL PROTECTED] 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 [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
   h1BasePage/h1
   hr/
   h3This is my child:/h3
   wicket:child /
   hr/
   h3This is my OTHER child:/h3
   wicket:child /
 /body
   /html
  
   ** Example of a child page:*
   ChildPage.html
   html
 body
   wicket:extend
 h4ChildPage/h4
 h5I'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

Re: Multiple wicket:child / tags on a single base page?

On 11/5/07, Stefan Fußenegger [EMAIL PROTECTED] 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Multiple wicket:child / tags on a single base page?