+1 on rethinking the auto* stuff together with the proposed queueing.
Sven
Am 09.11.2010 um 21:17 schrieb Igor Vaynberg:
> 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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
