i wonder if queuing can actually replace icomponentresolver and
auto-adding. i wonder if after onbeforerender we can do what unqueing
does now, parse the markup, find any missing components, and insert
them. autocomponents and autoadd() is something ive always disliked
because it doesnt work for anything that needs to stick around across
requests.

-igor


On Tue, Nov 9, 2010 at 11:10 AM, Johan Compagner <jcompag...@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.vaynb...@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 <jcompag...@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 <jcompag...@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
>>>> <martin.maku...@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 <jcompag...@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
>>>>>> <martin.maku...@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 <jcompag...@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
>>>>>>>> <frank.silberm...@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:martin.maku...@koodaripalvelut.com]
>>>>>>>>> Sent: Tuesday, November 09, 2010 9:23 AM
>>>>>>>>> To: users@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
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>> 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
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> 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
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> 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

Reply via email to