nah. you go ahead. the AutoComponentSource sounds vary vague, you will
need to elaborate it.
-igor
On Tue, Nov 9, 2010 at 12:58 PM, James Carman
<ja...@carmanconsulting.com> wrote:
> on dev list? You wanna start it?
>
> On Tue, Nov 9, 2010 at 3:57 PM, Igor Vaynberg <igor.vaynb...@gmail.com> wrote:
>> can we fork this into another thread?
>>
>> -igor
>>
>> On Tue, Nov 9, 2010 at 12:46 PM, James Carman
>> <ja...@carmanconsulting.com> wrote:
>>> Could we introduce the concept of an AutoComponentSource or something,
>>> perhaps? A page/component could potentially have multiple?
>>>
>>> On Tue, Nov 9, 2010 at 3:43 PM, Sven Meier <s...@meiers.net> wrote:
>>>> +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
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> 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
