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
