Hi,
The original idea in using IComponentResolver in our stuff was that
html designer can just put something in and our own framework (built
on wicket) automagically adds some default components to those
tags, which gives a working 'default application' very easily (we have
lots of simple pages which are used to maintain some kind of basic
parameter data in large systems).
Elsewhere, we have a component (let's say X) which is visible based on what
other stuff
(let's say Y) is present on page. How, if our application programmer adds
something
that implements Y on page, X automatically appars. This is done by visitChilden
call.
Now, if Y is autoAdded, this system broke, since visitChildern no longer found
it.
I think there are also some other use cases, which are a little bit different.
Actually,
the problem is not the IComponentResolver stuff, I think that we have just been
using visitChilden too much to inspect things. I realize that there are alternatives to
these designs, we might try to change this in the future.
Also, I think that if you remove the autoAdded stuff at end of request instead
of removing it immediately after component's render things are more robust,
since once the component is added, it is there during the whole request.
If someone writes an application which trys to find a component before
it is added, thats a problem in that application. In our case, there is no
problem like this (unless someone starts rendering components in reverse
order or something like that).
Ari S.
----- Original Message -----
From: "Johan Compagner" <[EMAIL PROTECTED]>
To: <users@wicket.apache.org>
Sent: Tuesday, October 23, 2007 1:00 AM
Subject: Re: VisitChildren + IComponentResolver broken in beta 4?
the fix is in.
Still i don't get that you depend on an auto add component from another
component
For example is that auto add component always rendered before that other
componenet?
How do you exactly use it? And why?
johan
On 10/22/07, Juha Alatalo <[EMAIL PROTECTED]> wrote:
Great! Thanks a lot Matej. When this fix is coming?
- Juha
Matej Knopp wrote:
> Well, I believe we can keep the component instance until the end of
> request and then clean it up in detach, would this help you? (it still
> wouldn't be the same as before the fix, as the instance was (supposed
> to be) cleaned during the next request, but this means keeping
> additional state for no good reason.
>
> -Matej
>
> On 10/17/07, Ari Suutari <[EMAIL PROTECTED]> wrote:
>> Hi,
>>
>>> I'm afraid you dont' really get what IComponentResolver is for. The
>>> purpose is to allow creating components from markup for a very short
>>> span of time - basically while the components are rendered and they
>>> should be removed immediate afterwards. So if you call visitChildren
>>> from another component, the resolved component will not be available.
>> Well. We have been using this from very early days of wicket
without
>> a problem. Also, there is no mention about this "very short" time
in
>> javadoc. Actually, if the autoAdded component was there previously
>> for longer time and is now removed immediately this is a quite big
>> change of behaviour if looking it from the application.
>>
>>> What changed in beta 4 is that we now remove the component immediately
>>> after it's rendered (inside the autoAdd call) because otherwise It
>>> caused us a nasty memory leak.
>> We have some rather large sites running with wicket 1.2 using
autoAdd
>> stuff, haven't noticed any huge leaks there. Couldn't you consider
>> any other alternatives for fixing that leak instead of insisting
that we are doing
>> something so wrong ?
>>
>> I really like all these IWhateverNiceInterface -things in wicket.
Usually,
>> when there is a need in application architecture, wicket has had a
nice
>> interface to support it. But it seems that it is very easy to get
yourself
>> burnt when using them, since they tend to get either rewritten or
their
>> behaviour changes.... Which is not a problem for someone who writes
>> a smaller web applications with just a couple of pages. But for
someone
>> who does larger ones, it's not so nice.
>>
>>
>> Ari S.
>>
>>
>>
>>> On 10/17/07, Ari Suutari <[EMAIL PROTECTED]> wrote:
>>>> Hi,
>>>>
>>>> But it looks like that in this case the visitChilder is performed
during
>>>> render, and it still won't find stuff added by autoAdd.
>>>>
>>>> It is not a very robust design if the behaviour of
autoAdd/visitChilder
>>>> would require some kind of component-hierarchy fine-tuning. This kind
>>>> of approach might work with static-kind-of applications, but at least
>>>> for us, the content in applications is very dynamic and interface
like
>>>> IComponentResolver has been very handy.
>>>>
>>>> Just a wild guess here - maybe the processing of IComponentResolver
stuff
>>>> was done earlier in beta3 than in beta4. Not getting this fixed can
be pretty annoying
>>>> for us - we have a couple of hundreds of pages done with wicket which
rely
>>>> on this.
>>>>
>>>> We could of course try to step back in time with svn to see which
change
>>>> has broken this, but I don't know how much sense it will make unless
>>>> developers are not going to admit that this is a problem.
>>>>
>>>> Ari S.
>>>>
>>>>
>>>> ----- Original Message -----
>>>> From: "Matej Knopp" <[EMAIL PROTECTED]>
>>>> To: <users@wicket.apache.org>
>>>> Sent: Wednesday, October 17, 2007 2:15 PM
>>>> Subject: Re: VisitChildren + IComponentResolver broken in beta 4?
>>>>
>>>>
>>>>> It depends on when you call the visitChildren method. The idea is
that
>>>>> resolved components are on page only during page render. Otherwise
>>>>> they are removed from page.
>>>>>
>>>>> -Matej
>>>>>
>>>>> On 10/17/07, Juha Alatalo <[EMAIL PROTECTED]> wrote:
>>>>>> In the JIRA issue following was commented:
>>>>>> "This doesn't seem to be a bug in Wicket. In fact, the bug was that
it
>>>>>> worked before. ..."
>>>>>>
>>>>>> This new "fix" is kind of a show stopper for us. What actually is
the
>>>>>> idea of the componentResolver? Functions like visitChildren works
for
>>>>>> normally added component. Shouldn't those functions work also for
>>>>>> components that are added using IComponentResolver as long as those
are
>>>>>> visible?
>>>>>>
>>>>>> - Juha
>>>>>>
>>>>>> Juha Alatalo wrote:
>>>>>>> https://issues.apache.org/jira/browse/WICKET-1077
>>>>>>>
>>>>>>> - Juha
>>>>>>>
>>>>>>> Matej Knopp wrote:
>>>>>>>> Please create a JIRA entry and assign the example to it.
>>>>>>>>
>>>>>>>> Thanks.
>>>>>>>>
>>>>>>>> -Matej
>>>>>>>>
>>>>>>>> On 10/15/07, Juha Alatalo <[EMAIL PROTECTED]> wrote:
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> If the components are added on the page using ComponentResolver,
>>>>>>>>> visitChildren() method seems to be working incorrectly. Created
>>>>>>>>> following example which works in beta 3 but not in beta 4.
>>>>>>>>>
>>>>>>>>> http://download.syncrontech.com/public/VisitChildrenExample.zip
>>>>>>>>>
>>>>>>>>> - Juha
>>>>>>>>>
>>>>>>>>>
---------------------------------------------------------------------
>>>>>>>>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>>>>>>>>> For additional commands, e-mail: [EMAIL PROTECTED]
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
---------------------------------------------------------------------
>>>>>>>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>>>>>>>> For additional commands, e-mail: [EMAIL PROTECTED]
>>>>>>>>
>>>>>>>
---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>>>>>>> For additional commands, e-mail: [EMAIL PROTECTED]
>>>>>>>
>>>>>>
---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>>>>>> For additional commands, e-mail: [EMAIL PROTECTED]
>>>>>>
>>>>>>
>>>>>
---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>>>>> For additional commands, e-mail: [EMAIL PROTECTED]
>>>>>
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>>>> For additional commands, e-mail: [EMAIL PROTECTED]
>>>>
>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>>> For additional commands, e-mail: [EMAIL PROTECTED]
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
