216 messages in org.apache.wicket.usersRe: Free wicket from component hierar...| From | Sent On | Attachments |
|---|---|---|
| 122 earlier messages | ||
| Martin Makundi | Nov 9, 2010 8:37 am | |
| Carl-Eric Menzel | Nov 9, 2010 8:39 am | |
| Martin Makundi | Nov 9, 2010 8:40 am | |
| James Carman | Nov 9, 2010 8:46 am | |
| Carl-Eric Menzel | Nov 9, 2010 8:46 am | |
| Igor Vaynberg | Nov 9, 2010 8:47 am | |
| Martin Makundi | Nov 9, 2010 8:48 am | |
| James Carman | Nov 9, 2010 8:49 am | |
| Igor Vaynberg | Nov 9, 2010 8:49 am | |
| James Carman | Nov 9, 2010 8:50 am | |
| Frank Silbermann | Nov 9, 2010 8:50 am | |
| Igor Vaynberg | Nov 9, 2010 8:53 am | |
| Martin Makundi | Nov 9, 2010 8:55 am | |
| Igor Vaynberg | Nov 9, 2010 8:55 am | |
| James Carman | Nov 9, 2010 8:56 am | |
| James Carman | Nov 9, 2010 8:57 am | |
| James Carman | Nov 9, 2010 8:58 am | |
| Igor Vaynberg | Nov 9, 2010 8:58 am | |
| Igor Vaynberg | Nov 9, 2010 8:59 am | |
| Martin Makundi | Nov 9, 2010 8:59 am | |
| James Carman | Nov 9, 2010 9:03 am | |
| Martin Makundi | Nov 9, 2010 9:05 am | |
| James Carman | Nov 9, 2010 9:11 am | |
| Martin Makundi | Nov 9, 2010 9:13 am | |
| James Carman | Nov 9, 2010 9:16 am | |
| Martin Makundi | Nov 9, 2010 9:22 am | |
| James Carman | Nov 9, 2010 9:25 am | |
| Martin Makundi | Nov 9, 2010 9:29 am | |
| Sebastian | Nov 9, 2010 9:29 am | |
| Martin Makundi | Nov 9, 2010 9:33 am | |
| James Carman | Nov 9, 2010 9:33 am | |
| James Carman | Nov 9, 2010 9:38 am | |
| Martin Makundi | Nov 9, 2010 9:38 am | |
| James Carman | Nov 9, 2010 9:41 am | |
| Martin Makundi | Nov 9, 2010 9:42 am | |
| James Carman | Nov 9, 2010 9:45 am | |
| Martin Makundi | Nov 9, 2010 9:51 am | |
| Johan Compagner | Nov 9, 2010 10:00 am | |
| Martin Makundi | Nov 9, 2010 10:04 am | |
| Johan Compagner | Nov 9, 2010 10:25 am | |
| Martin Makundi | Nov 9, 2010 10:29 am | |
| Johan Compagner | Nov 9, 2010 10:36 am | |
| Igor Vaynberg | Nov 9, 2010 10:52 am | |
| Igor Vaynberg | Nov 9, 2010 10:53 am | |
| Martin Makundi | Nov 9, 2010 10:54 am | |
| Johan Compagner | Nov 9, 2010 10:59 am | |
| Igor Vaynberg | Nov 9, 2010 11:02 am | |
| Igor Vaynberg | Nov 9, 2010 11:08 am | |
| Johan Compagner | Nov 9, 2010 11:10 am | |
| Michael Brinkman | Nov 9, 2010 11:27 am | |
| Sven Meier | Nov 9, 2010 12:03 pm | |
| Igor Vaynberg | Nov 9, 2010 12:15 pm | |
| Igor Vaynberg | Nov 9, 2010 12:17 pm | |
| Igor Vaynberg | Nov 9, 2010 12:22 pm | |
| Sven Meier | Nov 9, 2010 12:42 pm | |
| James Carman | Nov 9, 2010 12:45 pm | |
| Igor Vaynberg | Nov 9, 2010 12:57 pm | |
| James Carman | Nov 9, 2010 12:58 pm | |
| Igor Vaynberg | Nov 9, 2010 1:04 pm | |
| Carl-Eric Menzel | Nov 10, 2010 12:48 am | |
| Carl-Eric Menzel | Nov 10, 2010 1:04 am | |
| Carl-Eric Menzel | Nov 10, 2010 1:23 am | |
| James Carman | Nov 10, 2010 4:31 am | |
| Carl-Eric Menzel | Nov 10, 2010 5:08 am | |
| Frank Silbermann | Nov 10, 2010 6:18 am | |
| James Carman | Nov 10, 2010 6:23 am | |
| Igor Vaynberg | Nov 10, 2010 8:17 am | |
| Igor Vaynberg | Nov 10, 2010 8:22 am | |
| Igor Vaynberg | Nov 10, 2010 8:23 am | |
| Giannis Koutsoubos | Jan 14, 2011 8:44 am | |
| Giannis Koutsoubos | Jan 18, 2011 1:03 am | |
| Martin Grigorov | Jan 18, 2011 1:22 am | |
| Martin Makundi | Jan 18, 2011 1:24 am | |
| Martin Grigorov | Jan 18, 2011 1:42 am | |
| Martin Makundi | Jan 18, 2011 1:45 am | |
| Martijn Dashorst | Jan 18, 2011 1:51 am | |
| Martijn Dashorst | Jan 18, 2011 1:54 am | |
| Jeremy Thomerson | Jan 18, 2011 12:47 pm | |
| Martin Makundi | Jan 19, 2011 1:55 am | |
| Giannis Koutsoubos | Jan 20, 2011 7:41 am | |
| Jeremy Thomerson | Jan 20, 2011 9:16 am | |
| Martin Makundi | Jan 20, 2011 9:24 am | |
| Jeremy Thomerson | Jan 20, 2011 9:37 am | |
| Jim Pinkham | Jan 20, 2011 9:50 am | |
| Jeremy Thomerson | Jan 20, 2011 9:59 am | |
| Martin Grigorov | Jan 20, 2011 11:40 am | |
| Martin Grigorov | Jan 20, 2011 11:47 am | |
| Martin Makundi | Jan 20, 2011 12:13 pm | |
| Martin Grigorov | Jan 20, 2011 12:25 pm | |
| Martin Makundi | Jan 20, 2011 12:33 pm | |
| James Carman | Jan 20, 2011 1:42 pm | |
| Igor Vaynberg | Jan 20, 2011 2:11 pm | |
| James Carman | Jan 20, 2011 2:17 pm | |
| Martin Makundi | Jan 20, 2011 10:51 pm | |
| Subject: | Re: Free wicket from component hierarchy hell | |
|---|---|---|
| From: | Michael Brinkman (mich...@gmail.com) | |
| Date: | Nov 9, 2010 11:27:16 am | |
| List: | org.apache.wicket.users | |
I hate to jump into this, but I wanted to pose an assumption and a solution assuming my assumption is correct ;)
My assumption is that the key issue with the page objects self assembling into the correct hierarchy based on the HTML is that multiple objects may use the same wicket ID. If that's not the issue, you can probably stop reading and just let me know.
If that is in fact the issue, could you address the con ancern that some have about not getting an error letting you know something's amiss by requiring a flag to be set on the page called something like enforceUnqiueWicketIDs and basically throw exceptions on the queue methods if this isn't set and also enforce this setting withing all the queue/add methods? It seems like that would force someone whose project could make that assumption to actively opt-in code wise and then be able to queue all their components yet keep existing projects and those that don't want to have to worry about wicket ID collisions safe from issues.
I love using Wicket, but I've never been particularly fond of the need to define the nesting hierarchy twice (once in html and once in code) and an option to use this kind of assembly on the projects where I've used wicket would have been especially helpful early in the prototyping phase.
Anyway, just thought I'd share...this is an intriguing idea. Sorry if I've missed other key issues with this approach in this rather expansive thread.
-Michael
On Tue, Nov 9, 2010 at 1:10 PM, Johan Compagner <jcom...@gmail.com>wrote:
and that is only because i cant do
component.setAuto(false)
right after i call autoAdd()
else it would just stay there :)
and this is then only done to resolve it once with the first render...
On Tue, Nov 9, 2010 at 20:03, Igor Vaynberg <igor...@gmail.com> wrote:
it still wont work for a lot of usecases that require proper hierarchy. like a form trying to find form submitting component, etc
-igor
On Tue, Nov 9, 2010 at 10:59 AM, Johan Compagner <jcom...@gmail.com>
wrote:
ok a sample that it also works in with the right parent:
public class HelloWorld extends WebPage implements IComponentResolver {
final Label label; public HelloWorld() { label = new Label("label", new Model<String>() { @Override public String getObject() { return "my label: " + label.isEnabledInHierarchy(); } }); add(new WebMarkupContainer("body").setEnabled(false)); add(label); }
public boolean resolve(MarkupContainer container, MarkupStream markupStream, ComponentTag tag) {
Component component = get(tag.getId()); if (component != null) { container.autoAdd(component, markupStream); return true; } return false; } }
you will see that it is disabled...
On Tue, Nov 9, 2010 at 19:37, Johan Compagner <jcom...@gmail.com>
wrote:
textfield.isEnabledInHierachy() will then ofcourse not get to the parent it is on. because its parent is the webpage not the body markupcontainer.
So no this will not resolver from the child to the parent, only the parent to the child.
On Tue, Nov 9, 2010 at 19:30, Martin Makundi <mart...@koodaripalvelut.com> wrote:
How will it work if I call get("body").setEnabled(false); and if label was a textfield? Would the textfield be still enabled?
** Martin
2010/11/9 Johan Compagner <jcom...@gmail.com>:
no ofcourse not The label will then be gone because the body is gone. so the output will be this <html> </html>
when the body container is not visible
if the label is not visible:
<html> <body>
</body> </html>
this solution you just can throw everything in the panel or webpage that is the IComponentResolver for all its childs... Just look at how the code works.. IF a component can't be found on its own parent the ComponentResolver will ask all the parents which can be IComponentResolver to render the child..
On Tue, Nov 9, 2010 at 19:04, Martin Makundi <mart...@koodaripalvelut.com> wrote:
This does not really nest the components logically, does it?
If you set get("body").setVisible(false) will the label remain visible?
** Martin
2010/11/9 Johan Compagner <jcom...@gmail.com>:
Why are we discussing here already that works in wicket 1.4 if you really need it?
public class HelloWorld extends WebPage implements IComponentResolver {
public HelloWorld() { add(new WebMarkupContainer("body")); add(new Label("label","my label")); }
public boolean resolve(MarkupContainer container, MarkupStream markupStream, ComponentTag tag) {
Component component = get(tag.getId()); if (component != null) { component.render(markupStream); return true; } return false; } }
<html> <body wicket:id="body"> <span wicket:id="label"></span> </body> </html>
On Tue, Nov 9, 2010 at 16:29, Frank Silbermann <fran...@fedex.com> wrote:
Progress is made by people who have understanding, not by the ignorant. You're not in a position to make suggestions about extending Wicket if you don't yet understand how to use the powers it already has.
-----Original Message----- From: Martin Makundi [mailto:mart...@koodaripalvelut.com] Sent: Tuesday, November 09, 2010 9:23 AM To: use...@wicket.apache.org Subject: Re: Free wicket from component hierarchy hell
So instead of asking, "How can we make Wicket different so that my problem will go away?" the proper question to try first is, "What
is
the
Wicket way of solving my problem?"
That's not how proggress is made...
** Martin
---------------------------------------------------------------------
---------------------------------------------------------------------
---------------------------------------------------------------------