Apache Wicket › Users forum

Free wicket from component hierarchy hell

Classic

List

Threaded

216 messages Options

1234 ... 11

Martin Makundi

Free wicket from component hierarchy hell

I propose "Free Wicket" from component-hierarchy hell

We have discussd before that Wicket has unnecessary binding to
wicket:id and component hierarchy
[http://www.mail-archive.com/users@.../msg53941.html].

I think I found a simple solution: "wicket:id" should be allowed to be
on any level within given Panel-type element. User has freedom to
position components and change html layout.

What you think?

Old wicket applications can be automatically refectored to have unique
ids. Currently the wicket hardcoded component hierarchy slows down
development and is totally unnecessary.

https://cwiki.apache.org/confluence/display/WICKET/Wicket+1.5+Wish+List

**
Martin

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

7zark7

Re: Free wicket from component hierarchy hell

Perhaps this is what you mean by "any level within given Panel-type
element",
but would this not screw up making components?

The hierarchy is rather important for this - unlike JSP, etc where you
just dump data references in a "page response"

Components are one of the things that makes Wicket so nice.

On 11/4/10 1:13 PM, Martin Makundi wrote:

> I propose "Free Wicket" from component-hierarchy hell
>
> We have discussd before that Wicket has unnecessary binding to
> wicket:id and component hierarchy
> [http://www.mail-archive.com/users@.../msg53941.html].
>
> I think I found a simple solution: "wicket:id" should be allowed to be
> on any level within given Panel-type element. User has freedom to
> position components and change html layout.
>
> What you think?
>
> Old wicket applications can be automatically refectored to have unique
> ids. Currently the wicket hardcoded component hierarchy slows down
> development and is totally unnecessary.
>
> https://cwiki.apache.org/confluence/display/WICKET/Wicket+1.5+Wish+List
>
> **
> Martin
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Jonathan Locke

Re: Free wicket from component hierarchy hell

In reply to this post by Martin Makundi

I think if you find component hierarchies to be "hell", you probably aren't using Wicket right. Break things down into small reusable chunks using Panels and you will find everything gets much, much easier.

Martin Makundi

Re: Free wicket from component hierarchy hell

1. I want freedom inside panels.

2. Doubly defined hierarhices are redundant. Server-side hierarchy can
be automatically deduced from markup hierarcy. Such tasks should be
done by COMPUTER. Not coder.

**
Martin

2010/11/5 Jonathan Locke <[hidden email]>:

>
> I think if you find component hierarchies to be "hell", you probably aren't
> using Wicket right. Break things down into small reusable chunks using
> Panels and you will find everything gets much, much easier.
> --
> View this message in context: http://apache-wicket.1842946.n4.nabble.com/Free-wicket-from-component-hierarchy-hell-tp3027705p3027881.html
> Sent from the Users forum mailing list archive at Nabble.com.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Martin Makundi

Re: Free wicket from component hierarchy hell

Can you see the matrix?

;)

If you have:

<html>
<form wicket:id="form">
<input wicket:id="input" .../>
</form>
</html>

public class MyPage extends WebPage {
public MyPage () {
add(new Form("form"));
add(new TextField("input", model)); // Wicket could
automatically handle parse hierarchy from markup
}
}

**
Martin

2010/11/5 Martin Makundi <[hidden email]>:

> 1. I want freedom inside panels.
>
> 2. Doubly defined hierarhices are redundant. Server-side hierarchy can
> be automatically deduced from markup hierarcy. Such tasks should be
> done by COMPUTER. Not coder.
>
> **
> Martin
>
> 2010/11/5 Jonathan Locke <[hidden email]>:
>>
>> I think if you find component hierarchies to be "hell", you probably aren't
>> using Wicket right. Break things down into small reusable chunks using
>> Panels and you will find everything gets much, much easier.
>> --
>> View this message in context: http://apache-wicket.1842946.n4.nabble.com/Free-wicket-from-component-hierarchy-hell-tp3027705p3027881.html
>> Sent from the Users forum mailing list archive at Nabble.com.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

jeremy@wickettraining.com

Re: Free wicket from component hierarchy hell

On Thu, Nov 4, 2010 at 5:13 PM, Martin Makundi <
[hidden email]> wrote:

> Can you see the matrix?
>
> ;)
>
> If you have:
>
> <html>
> <form wicket:id="form">
> <input wicket:id="input" .../>
> </form>
> </html>
>
> public class MyPage extends WebPage {
> public MyPage () {
> add(new Form("form"));
> add(new TextField("input", model)); // Wicket could
> automatically handle parse hierarchy from markup
> }
> }
>
> **
> Martin
>

Can you see how this would fail?

<html>
<form wicket:id="form1">
<input wicket:id="input" .../>
</form>
<form wicket:id="form2">
<input wicket:id="input" .../>
</form>
</html>

When wicket looks up "input", it must look it up on the appropriate parent
component. You can't have two things in your page (or panel) that have the
same ID - Wicket couldn't possibly know how to differentiate which component
you mean when it parses the markup and finds the tag with ID "input".

What about repeaters?

What about if form1 was in BasePage.html and form2 was in HomePage.html
(which extends BasePage.html) - how do we know which input component to
get? The one you called add on in BasePage.java, or the one in
HomePage.java? Oh, we can't differentiate which class you called add from
within. Oh, and you could have meant for the one added in HomePage.java to
replace the one added in BasePage.java.

How do you propose we do all that?

--
Jeremy Thomerson
http://wickettraining.com
*Need a CMS for Wicket? Use Brix! http://brixcms.org*

Martin Makundi

Re: Free wicket from component hierarchy hell

Hi!

> Can you see how this would fail?
>
> <html>
> <form wicket:id="form1">
> <input wicket:id="input" .../>
> </form>
> <form wicket:id="form2">
> <input wicket:id="input" .../>
> </form>
> </html>

That's old-school-wicket ;)

This would not be allowed anymore. An application would have to be
refactored (using an automated script) into:

<html>
<form wicket:id="form1">
<input wicket:id="input-1" .../>
</form>
<form wicket:id="form2">
<input wicket:id="input-X" .../>
</form>
</html>

We would simply change wicket syntax: panels and pages require unique
wicket id for all components.

> What about repeaters?

What about repeaters? Repeaters are generated on-the-fly anyways so
they can be definitely computed on-the-fly.

> What about if form1 was in BasePage.html and form2 was in HomePage.html
> (which extends BasePage.html) - how do we know which input component to
> get? The one you called add on in BasePage.java, or the one in
> HomePage.java? Oh, we can't differentiate which class you called add from
> within. Oh, and you could have meant for the one added in HomePage.java to
> replace the one added in BasePage.java.
>
> How do you propose we do all that?

You win some, you lose some. Nobody ever complained that parent and
super classes cannot have protected fields with same names. Wicket:ids
simply are considered protected-scoped. Maybe it could also be
possible to define wicket:id:private which requires hierarcy and
wicket:id which is "friendly" visibility etc.

When there is a will, there is a way.

**
Martin

>
> --
> Jeremy Thomerson
> http://wickettraining.com
> *Need a CMS for Wicket? Use Brix! http://brixcms.org*
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Martin Makundi

Re: Free wicket from component hierarchy hell

Hi!

We could also make so that "wicket:id" is old-school and
"wicket:id:protected" is new-school.

No need to refactor anything.

Just pros without any cons.

**
Martin

2010/11/5 Martin Makundi <[hidden email]>:

> Hi!
>
>> Can you see how this would fail?
>>
>> <html>
>> <form wicket:id="form1">
>> <input wicket:id="input" .../>
>> </form>
>> <form wicket:id="form2">
>> <input wicket:id="input" .../>
>> </form>
>> </html>
>
> That's old-school-wicket ;)
>
> This would not be allowed anymore. An application would have to be
> refactored (using an automated script) into:
>
> <html>
> <form wicket:id="form1">
> <input wicket:id="input-1" .../>
> </form>
> <form wicket:id="form2">
> <input wicket:id="input-X" .../>
> </form>
> </html>
>
> We would simply change wicket syntax: panels and pages require unique
> wicket id for all components.
>
>> What about repeaters?
>
> What about repeaters? Repeaters are generated on-the-fly anyways so
> they can be definitely computed on-the-fly.
>
>> What about if form1 was in BasePage.html and form2 was in HomePage.html
>> (which extends BasePage.html) - how do we know which input component to
>> get? The one you called add on in BasePage.java, or the one in
>> HomePage.java? Oh, we can't differentiate which class you called add from
>> within. Oh, and you could have meant for the one added in HomePage.java to
>> replace the one added in BasePage.java.
>>
>> How do you propose we do all that?
>
> You win some, you lose some. Nobody ever complained that parent and
> super classes cannot have protected fields with same names. Wicket:ids
> simply are considered protected-scoped. Maybe it could also be
> possible to define wicket:id:private which requires hierarcy and
> wicket:id which is "friendly" visibility etc.
>
> When there is a will, there is a way.
>
> **
> Martin
>
>>
>> --
>> Jeremy Thomerson
>> http://wickettraining.com
>> *Need a CMS for Wicket? Use Brix! http://brixcms.org*
>>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Michał Letyński

Re: Free wicket from component hierarchy hell

In reply to this post by Jonathan Locke

Hi.
I think its not a solution for problem which Martin described. If you cooperate with some outer company which provide you styled markup or they are modifing an existing one they can broke your hierarchy and you must change your code. It would be nice to not do this, for e.g adding everythink to page. I know that in this case (Jeremy wrote that) you must provide uniqueness of components in whole page but it also can be resolved somehow :)

> I think if you find component hierarchies to be "hell", you probably aren't
> using Wicket right. Break things down into small reusable chunks using
> Panels and you will find everything gets much, much easier.

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Martin Makundi

Re: Free wicket from component hierarchy hell

> I know that in this case (Jeremy wrote that) you must provide
> uniqueness of components in whole page but it also can be resolved somehow

+1

Also DOM requires id uniqueness according to spec so it is nothing new
to web developers.

**
Martin

>
>> I think if you find component hierarchies to be "hell", you probably
>> aren't
>> using Wicket right. Break things down into small reusable chunks using
>> Panels and you will find everything gets much, much easier.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Martin Grigorov-4

Re: Free wicket from component hierarchy hell

On Fri, Nov 5, 2010 at 10:07 AM, Martin Makundi <
[hidden email]> wrote:

> > I know that in this case (Jeremy wrote that) you must provide
> > uniqueness of components in whole page but it also can be resolved
> somehow
>
> +1
>
> Also DOM requires id uniqueness according to spec so it is nothing new
> to web developers.
>
Martin,

Did you understand what Jeremy and Michal described above ?
If you have to use libraries A and B that provide Wicket components and both
of them use "message" or "feedback" as component id in any of their
components then how your application will deal with that ?

>
> **
> Martin
>
> >
> >> I think if you find component hierarchies to be "hell", you probably
> >> aren't
> >> using Wicket right. Break things down into small reusable chunks using
> >> Panels and you will find everything gets much, much easier.
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

Martin Makundi

Re: Free wicket from component hierarchy hell

Hi!

> If you have to use libraries A and B that provide Wicket components and both
> of them use "message" or "feedback" as component id in any of their
> components then how your application will deal with that ?

You make decision: feedback is either private (traditional) or
protected/panel-scope member. Both ways can be supported. Ifcourse
even better if we can have compile-time conflict resolution (Project
Lombok, Bindgen).

**
Martin

>
>>
>> **
>> Martin
>>
>> >
>> >> I think if you find component hierarchies to be "hell", you probably
>> >> aren't
>> >> using Wicket right. Break things down into small reusable chunks using
>> >> Panels and you will find everything gets much, much easier.
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: [hidden email]
>> > For additional commands, e-mail: [hidden email]
>> >
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Martin Grigorov-4

Re: Free wicket from component hierarchy hell

On Fri, Nov 5, 2010 at 10:16 AM, Martin Makundi <
[hidden email]> wrote:

> Hi!
>
> > If you have to use libraries A and B that provide Wicket components and
> both
> > of them use "message" or "feedback" as component id in any of their
> > components then how your application will deal with that ?
>
> You make decision: feedback is either private (traditional) or
> protected/panel-scope member. Both ways can be supported. Ifcourse
> even better if we can have compile-time conflict resolution (Project
> Lombok, Bindgen).
>

Let's say both libraries are "modern" (because private scope is old-fashion,
right) and export "message" with Page scope.
Then project X (Lombok, Bindgen) finds the problem at compile time and
explain you that both lib A and B export component with the same id.
What would you do now ?
Throw away either lib A or B and re-write it ?

>
> **
> Martin
>
> >
> >>
> >> **
> >> Martin
> >>
> >> >
> >> >> I think if you find component hierarchies to be "hell", you probably
> >> >> aren't
> >> >> using Wicket right. Break things down into small reusable chunks
> using
> >> >> Panels and you will find everything gets much, much easier.
> >> >
> >> > ---------------------------------------------------------------------
> >> > To unsubscribe, e-mail: [hidden email]
> >> > For additional commands, e-mail: [hidden email]
> >> >
> >> >
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: [hidden email]
> >> For additional commands, e-mail: [hidden email]
> >>
> >>
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

Marc Nuri

Re: Free wicket from component hierarchy hell

In reply to this post by Martin Makundi

Hi
In my opinion, when you use lots of inheritance in a page, its really
imposible to control if a component appears just once in the page.
Wicket is great for the ability to reuse components. Actually I've been able
to create a private framework where I'm able to build an entire page with
components binded to a JPA entity bean just with some annotations (amazing
productivity).
If the project gets complicated, I think there is no possible way to control
the uniqueness of the component in the page. The advantages of adding a
component wherever you cant along the hierarchy are true, I don't think that
your proposal gives the best of both worlds.
Regards
--
Marc Nuri

-- Marc Nuri www.marcnuri.com

Martin Makundi

Re: Free wicket from component hierarchy hell

In reply to this post by Martin Grigorov-4

> Let's say both libraries are "modern" (because private scope is old-fashion,
> right) and export "message" with Page scope.
> Then project X (Lombok, Bindgen) finds the problem at compile time and
> explain you that both lib A and B export component with the same id.
> What would you do now ?
> Throw away either lib A or B and re-write it ?

Please give a concrete example of such situation. If names are panel
or page scope I cannot immagine many worthwile items that can be
imported onto panels and pages that cannot be refactored.

**
Martin

>
>>
>> **
>> Martin
>>
>> >
>> >>
>> >> **
>> >> Martin
>> >>
>> >> >
>> >> >> I think if you find component hierarchies to be "hell", you probably
>> >> >> aren't
>> >> >> using Wicket right. Break things down into small reusable chunks
>> using
>> >> >> Panels and you will find everything gets much, much easier.
>> >> >
>> >> > ---------------------------------------------------------------------
>> >> > To unsubscribe, e-mail: [hidden email]
>> >> > For additional commands, e-mail: [hidden email]
>> >> >
>> >> >
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: [hidden email]
>> >> For additional commands, e-mail: [hidden email]
>> >>
>> >>
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Martin Makundi

Re: Free wicket from component hierarchy hell

To be more precise: namespace would always be per each markupcontainer
which has its own markup.

**
Martin

> Please give a concrete example of such situation. If names are panel
> or page scope I cannot immagine many worthwile items that can be
> imported onto panels and pages that cannot be refactored.
>
> **
> Martin
>
>>
>>>
>>> **
>>> Martin
>>>
>>> >
>>> >>
>>> >> **
>>> >> Martin
>>> >>
>>> >> >
>>> >> >> I think if you find component hierarchies to be "hell", you probably
>>> >> >> aren't
>>> >> >> using Wicket right. Break things down into small reusable chunks
>>> using
>>> >> >> Panels and you will find everything gets much, much easier.
>>> >> >
>>> >> > ---------------------------------------------------------------------
>>> >> > To unsubscribe, e-mail: [hidden email]
>>> >> > For additional commands, e-mail: [hidden email]
>>> >> >
>>> >> >
>>> >>
>>> >> ---------------------------------------------------------------------
>>> >> To unsubscribe, e-mail: [hidden email]
>>> >> For additional commands, e-mail: [hidden email]
>>> >>
>>> >>
>>> >
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>>>
>>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Martin Grigorov-4

Re: Free wicket from component hierarchy hell

In reply to this post by Martin Makundi

LibA provides PanelA which exports ComponentA with id == "messages" (e.g.
ListView) with Page scope.
LibB provides PanelB which exports ComponentB with id == "messages" (e.g.
DataGrid) with Page scope.
Then your application has a page MyPage which includes both PanelA and
PanelB and the problem arises.

On Fri, Nov 5, 2010 at 10:29 AM, Martin Makundi <
[hidden email]> wrote:

> > Let's say both libraries are "modern" (because private scope is
> old-fashion,
> > right) and export "message" with Page scope.
> > Then project X (Lombok, Bindgen) finds the problem at compile time and
> > explain you that both lib A and B export component with the same id.
> > What would you do now ?
> > Throw away either lib A or B and re-write it ?
>
> Please give a concrete example of such situation. If names are panel
> or page scope I cannot immagine many worthwile items that can be
> imported onto panels and pages that cannot be refactored.
>
> **
> Martin
>
> >
> >>
> >> **
> >> Martin
> >>
> >> >
> >> >>
> >> >> **
> >> >> Martin
> >> >>
> >> >> >
> >> >> >> I think if you find component hierarchies to be "hell", you
> probably
> >> >> >> aren't
> >> >> >> using Wicket right. Break things down into small reusable chunks
> >> using
> >> >> >> Panels and you will find everything gets much, much easier.
> >> >> >
> >> >> >
> ---------------------------------------------------------------------
> >> >> > To unsubscribe, e-mail: [hidden email]
> >> >> > For additional commands, e-mail: [hidden email]
> >> >> >
> >> >> >
> >> >>
> >> >> ---------------------------------------------------------------------
> >> >> To unsubscribe, e-mail: [hidden email]
> >> >> For additional commands, e-mail: [hidden email]
> >> >>
> >> >>
> >> >
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: [hidden email]
> >> For additional commands, e-mail: [hidden email]
> >>
> >>
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

Martin Grigorov-4

Re: Free wicket from component hierarchy hell

In reply to this post by Martin Makundi

On Fri, Nov 5, 2010 at 10:31 AM, Martin Makundi <
[hidden email]> wrote:

> To be more precise: namespace would always be per each markupcontainer
> which has its own markup.
>
So the "hell" is still here. It is just moved one level up.
It seems you didn't think of all cases.

>
> **
> Martin
>
> > Please give a concrete example of such situation. If names are panel
> > or page scope I cannot immagine many worthwile items that can be
> > imported onto panels and pages that cannot be refactored.
> >
> > **
> > Martin
> >
> >>
> >>>
> >>> **
> >>> Martin
> >>>
> >>> >
> >>> >>
> >>> >> **
> >>> >> Martin
> >>> >>
> >>> >> >
> >>> >> >> I think if you find component hierarchies to be "hell", you
> probably
> >>> >> >> aren't
> >>> >> >> using Wicket right. Break things down into small reusable chunks
> >>> using
> >>> >> >> Panels and you will find everything gets much, much easier.
> >>> >> >
> >>> >> >
> ---------------------------------------------------------------------
> >>> >> > To unsubscribe, e-mail: [hidden email]
> >>> >> > For additional commands, e-mail: [hidden email]
> >>> >> >
> >>> >> >
> >>> >>
> >>> >>
> ---------------------------------------------------------------------
> >>> >> To unsubscribe, e-mail: [hidden email]
> >>> >> For additional commands, e-mail: [hidden email]
> >>> >>
> >>> >>
> >>> >
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: [hidden email]
> >>> For additional commands, e-mail: [hidden email]
> >>>
> >>>
> >>
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

Martin Makundi

Re: Free wicket from component hierarchy hell

In reply to this post by Martin Grigorov-4

> LibA provides PanelA which exports ComponentA with id == "messages" (e.g.
> ListView) with Page scope.

PanelA defines independent namespace.

> LibB provides PanelB which exports ComponentB with id == "messages" (e.g.
> DataGrid) with Page scope.

PanelB defines independent namespace.

> Then your application has a page MyPage which includes both PanelA and
> PanelB and the problem arises.

MyPage defines new namespace.

PanelA and PanelB are independent.

No problems.

**
Martin

>
> On Fri, Nov 5, 2010 at 10:29 AM, Martin Makundi <
> [hidden email]> wrote:
>
>> > Let's say both libraries are "modern" (because private scope is
>> old-fashion,
>> > right) and export "message" with Page scope.
>> > Then project X (Lombok, Bindgen) finds the problem at compile time and
>> > explain you that both lib A and B export component with the same id.
>> > What would you do now ?
>> > Throw away either lib A or B and re-write it ?
>>
>> Please give a concrete example of such situation. If names are panel
>> or page scope I cannot immagine many worthwile items that can be
>> imported onto panels and pages that cannot be refactored.
>>
>> **
>> Martin
>>
>> >
>> >>
>> >> **
>> >> Martin
>> >>
>> >> >
>> >> >>
>> >> >> **
>> >> >> Martin
>> >> >>
>> >> >> >
>> >> >> >> I think if you find component hierarchies to be "hell", you
>> probably
>> >> >> >> aren't
>> >> >> >> using Wicket right. Break things down into small reusable chunks
>> >> using
>> >> >> >> Panels and you will find everything gets much, much easier.
>> >> >> >
>> >> >> >
>> ---------------------------------------------------------------------
>> >> >> > To unsubscribe, e-mail: [hidden email]
>> >> >> > For additional commands, e-mail: [hidden email]
>> >> >> >
>> >> >> >
>> >> >>
>> >> >> ---------------------------------------------------------------------
>> >> >> To unsubscribe, e-mail: [hidden email]
>> >> >> For additional commands, e-mail: [hidden email]
>> >> >>
>> >> >>
>> >> >
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: [hidden email]
>> >> For additional commands, e-mail: [hidden email]
>> >>
>> >>
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Martin Makundi

Re: Free wicket from component hierarchy hell

In reply to this post by Marc Nuri

> If the project gets complicated, I think there is no possible way to control
> the uniqueness of the component in the page. The advantages of adding a
> component wherever you cant along the hierarchy are true, I don't think that
> your proposal gives the best of both worlds.

This is a misunderstanding. Not ANYWHERE. Only on Panel and Page and
similar markupprovider levels.

> Regards
> --
> Marc Nuri
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

1234 ... 11