I'm sorry to say, but the whole discussion makes little sense to me and
these attempts to fix something that is not broken actually scares me a bit.
As far as I understand the philosophy of Wicket it is a Java centric and
Java code drive web application framework. This makes it very unique to
all other approaches I've seen so far.
The component hierarchy defined in the code means more than just to
layout the components right for the markup. It for example also defines
the visibility hierarchy which is important for security and usability,
and defines the update hierarchy when doing component refreshs via AJAX.
It simply is not right to allow the designer to move around components
at will which are cascaded in the code with good functional reasons.
So what I want to say is, the hierarchy defined in the markup only
represents one aspect of the hierarchy defined in the code and as such
is NOT a good source to build the runtime component hierarchy on. Also I
would not like to have a "traditional way" and another way to define
hierarchies in Wicket as this will only cause confusion. I prefer the
Python philosphy "there should be one — and only one — obvious way to do
something".
Regards,
Seb
On 07.11.2010 00:45, Igor Vaynberg wrote:
here is a proper very rough initial implementation:
https://github.com/ivaynberg/wicket/commit/cbe861f4028120993f5d10d575f12c4ca291fdce
now someone has to mature it to the point where it can be properly evaluated.
-igor
On Sat, Nov 6, 2010 at 6:54 AM, samket<sam...@gmx.com> wrote:
We need to wait until all components are added so that we can arrange
them into correct hireracy before rendering.
May I suggest that components are added with help of a builder object, for
example:
public MyPanel(String id) {
super(id);
Builder b = new Builder(this); // the Builder gets reference to this MyPanel
b.add(new TextField("name")); // can be child of "form" which is added later
b.add(new SomeForm("form"));
b.build(); // after this line this MyPanel contains the components name and form
}
If MyPanel's super class needs to access the same builder, it can provide a
constructor for it. In that case b.build() should be only invoked in MyPanel's
constructor.
If a developer uses more than one builder in a constructor, he can restrict
moving of components in markup to some extent:
public MyPanel(String id) {
super(id);
Builder b1 = new Builder(this);
b1.add(new TextField("name")); // in markup, "name" can't be put under "form"
because it's in a different builder
b1.build();
Builder b2 = new Builder(this);
b2.add(new SomeForm("form");
b2.build();
}
Of course this doesn't solve the problem Igor mentioned. For that you'd need the
"old-fashioned way":
public MyPanel(String id) {
super(id);
SomeForm form = new SomeForm("form");
form.add(new TextField("name"); // in markup, "name" can't be moved out from
"form"
add(form);
}
Developers would need to mix different approaches for building hierarchies if
security is an issue. On second thought, I should use a broader term than
security because there is more than one reason to restrict those pesky
designers ;)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
