You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@wicket.apache.org by Ilya German <Il...@parex.lv> on 2010/01/14 14:21:01 UTC
final in MarkupContainer#add(Component...) method
Hello!
We're struggling with working around the final modifier for the MarkupContainer#add(Component ...) method.
We have the following scenario:
1. We'd like to use a repeater to add some components to the form.
2. We'd like these components to work with CompoundPropertyModel, thus we need these to have meaningful wicket ids
3. We'd like not to find ourselves backstabbed by the non-numeric ids in the RepeatingView's children.
This brings us to a suggested "wrapping" of the children in WebMarkupContainers, but we'd like to hide it to get rid of the
webmarkupcontainer item=new webmarkupcontainer(rv.newchildid());
part. To do this, it seems logical to extend the RepeatingView overriding the add() method to be wrapping every component, however the add() method is final :(
Could anyone suggest some other way to resolve this situation? Or, perhaps, it could be acceptable to "officially" remove the final modifier from the add() method?
Thanks in advance!
Ilya German.
Re: final in MarkupContainer#add(Component...) method
Posted by Igor Vaynberg <ig...@gmail.com>.
On Mon, Jan 18, 2010 at 4:52 AM, Sergejs Olefirs
<Se...@parex.lv> wrote:
>
> This kind of brings us back to original question -- why is
> MarkupContainer.add(..) method final? Maybe it's something that needs to be
> changed (or alternatively mechanism provided for hooking into this method)?
even if we make it non-final you still have the same problem of adding
components two different ways. one way using add() which adds it to
some internal component, the other way using super.add() or some other
method like addToDirectParent() to invoke the original behavior and
add components to the actual parent. so really, making it nonfinal
does not solve the problem, just adds confusion as to what add()
actually does.
if its formcomponents you are worried about then you can create
add(FormComponent fc) and add them to some other parent.
you can also override oncomponentadded() and add some runtime
validation to make it easier for developers to fix their code.
> It also resolved the issue with page inheritance. As it stands right now (in
> out-of-the-box Wicket), if <wicket:child /> is inside of any other tag with
> wicket-id, then children pages can no longer use add(..) method directly (as
> it would then add components in the wrong place in the hierarchy and page
> rendering will crash). With 'final' gone, it is a simple matter to override
> add(..) in the parent page so that it would add components properly -- thus
> children need not be aware of the parent innards.
does it really? so if i were to subclass the parent page and
substitute my own markup i would be ok? oh wait, no! because i now
need to know that in that page i cannot call add() like everywhere
else because it would add it to some child but i want to add directly
to the component. but i cant, because now even calling super.add()
still adds to the container. darn. so now i still have to provide a
second method addDirectlyToComponent() so subclasses can properly add
components.
the proper way to handle this situation is to make the container that
contains wicket:child tag transparent. search the list, plenty threads
with details on this one.
so really, where are we at? we still always need two methods to add
components in these situations.
first option is to make add nonfinal, allowing you to override the
default and make it easy to add components from the outside while
making it harder to add components from inside.
second option is to leave add final and make it easy to add components
from the inside while making it harder to add components from the
outside.
for me there is no clear cut solution because there are plenty of
components and usecases that fall under the different groups.
it also depends on how one views the "add" call. to you view it as a
logical: "i am putting this component inside this one" or a semantic:
"i am adding this component as a direct child" - which is the
expecation everyone has currently with add() being final.
-igor
>
> Best regards,
> Sergey
>
>
>
> Pedro H. O. dos Santos wrote:
>>
>>>>This brings us to a suggested "wrapping" of the children in
> WebMarkupContainers
>> This is not the only option you have, you can use lenient form components
>> like:
>> public class LenientTextField extends TextField
>> {
>> @Override
>> protected void onComponentTag(final ComponentTag tag)
>> {
>> tag.setName("input");
>> tag.put("type", "text");
>> super.onComponentTag(tag);
>> }
>> }
>> so you have an text field that you can your for any tag you place on your
>> template.
>>
>> About the meaningful wicket ids, you doesn't need to call rv.newchildid(),
>> only make sure to don't repeat the ids.
>>
>> 2010/1/14 Ilya German <Il...@parex.lv>
>>> This brings us to a suggested "wrapping" of the children in
>>> WebMarkupContainers, but we'd like to hide it to get rid of the
>>>
>>> webmarkupcontainer item=new webmarkupcontainer(rv.newchildid());
>>>
>>> part. To do this, it seems logical to extend the RepeatingView overriding
>>> the add() method to be wrapping every component, however the add() method
>>> is
>>> final :(
>>>
>>> Could anyone suggest some other way to resolve this situation? Or,
>>> perhaps,
>>> it could be acceptable to "officially" remove the final modifier from the
>>> add() method?
>>>
>>> Thanks in advance!
>>>
>>> Ilya German.
>>
>>
>>
>>
>> --
>> Pedro Henrique Oliveira dos Santos
>>
>>
>
> --
> View this message in context: http://old.nabble.com/final-in-MarkupContainer-add%28Component...%29-method-tp27161187p27210046.html
> Sent from the Wicket - User mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Heap space issue
Posted by Martijn Dashorst <ma...@gmail.com>.
Use jmap -histo <pid> or a memory profiler (yourkit) or visualvm to
look at the heap. It also helps to use jstat -gc <pid> 1000 in cases
when you have low heap availability before killing your darlings. It
might not be a memory leak but possibly a connection pool running out
of connections.
Any number of programming errors can lead to memory leaks, including
exceptions. Without actual profiling you won't be able to find the
leaks.
Martijn
On Mon, Jan 18, 2010 at 4:14 PM, Frank Silbermann
<fr...@fedex.com> wrote:
> I am monitoring a Wicket 1.4.5 application running on Tomcat 6.0 which
> accesses a SQL Server 2000 database. Periodically the application
> becomes unresponsive due to a lack of heap space, and I have to bounce
> Tomcat. I'm trying to figure out what sort of errors could cause this
> to happen.
>
> Any suggestions?
>
> I've looked in the Tomcat error logs, but the only errors I see prior to
> the out-of-heapspace error are a small number of SQL errors that result
> from bad input data. The Wicket application handles these errors by
> switching the user to a standard error page. I suppose it's a bad
> architecture to rely on SQL errors reported by the database rather than
> checking the data, but does this result in a memory leak?
>
> Frank Silbermann
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
--
Become a Wicket expert, learn from the best: http://wicketinaction.com
Apache Wicket 1.4 increases type safety for web applications
Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.4.4
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Heap space issue
Posted by Frank Silbermann <fr...@fedex.com>.
I am monitoring a Wicket 1.4.5 application running on Tomcat 6.0 which
accesses a SQL Server 2000 database. Periodically the application
becomes unresponsive due to a lack of heap space, and I have to bounce
Tomcat. I'm trying to figure out what sort of errors could cause this
to happen.
Any suggestions?
I've looked in the Tomcat error logs, but the only errors I see prior to
the out-of-heapspace error are a small number of SQL errors that result
from bad input data. The Wicket application handles these errors by
switching the user to a standard error page. I suppose it's a bad
architecture to rely on SQL errors reported by the database rather than
checking the data, but does this result in a memory leak?
Frank Silbermann
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: final in MarkupContainer#add(Component...) method
Posted by Pedro Santos <pe...@gmail.com>.
> And if I may to try and adjust the course of this discussion a bit -- the
> issue with repeaters is not the only argument against final add(..)
method.
> As I mentioned in passing, there's also issue of Page inheritance where
> subclasses with <wicket:extend> cannot use add(..) method if parent Page
has
> <wicket:child /> nested into some other tag with wicket:id -- leading to
the
> very similar issues. I'm sure there can be other examples as well.
This thread already get discussed in somewhere, and and custom
addComponentOnChild(...) is an good option.
> So perhaps add(..) method doesn't need to be final after all? Or would it
> break something else that I don't know about? If someone could explain
> reasons behind add(..) being final it would be most appreciated -- that
> might change my opinion on the whole subject.
There is no api break, IMO it is an good framework frozen spot, since
situation on link[1] are avoided.
[1]
http://markmail.org/search/?q=list:org.apache.wicket.users+from:"Pedro+Santos"+override+date:200910+ajax#query:list%3Aorg.apache.wicket.users%20from%3A%22Pedro%20Santos%22%20override%20date%3A200910%20ajax+page:1+mid:u5uemowe7tqujn3o+state:results<http://markmail.org/search/?q=list:org.apache.wicket.users+from:%22Pedro+Santos%22+override+date:200910+ajax#query:list%3Aorg.apache.wicket.users%20from%3A%22Pedro%20Santos%22%20override%20date%3A200910%20ajax+page:1+mid:u5uemowe7tqujn3o+state:results>
On Mon, Jan 18, 2010 at 12:15 PM, Sergejs Olefirs
<Se...@parex.lv>wrote:
>
> Thanks again for your reply.
>
> On the one hand, I agree with you, adding custom 'addComponent' method does
> make the mechanics of the code more clear.
>
> On the other hand, in practice (we used such methods for a couple of
> weeks),
> it results in the situations in application code where you sometimes have
> to
> use add(..) method and sometimes addComponent(..) method (and in case of
> addComponent(..) method, add(..) method is also available, so no
> compilation
> errors there). It invariably led to people forgetting to use
> addComponent(..) instead of add(..) and thus application crashing/behaving
> incorrectly at runtime. This was extremely annoying -- hence our decision
> to
> un-finalize add(..) method.
>
> On the yet another hand, OO programming kind of implies that objects are
> supposed to hide their implementation details, so even disregarding my
> previous usability comment, I'm not sure I agree that addComponent(..) is
> better than overridden add(..) method from the philosophical point of view.
>
>
> And if I may to try and adjust the course of this discussion a bit -- the
> issue with repeaters is not the only argument against final add(..) method.
> As I mentioned in passing, there's also issue of Page inheritance where
> subclasses with <wicket:extend> cannot use add(..) method if parent Page
> has
> <wicket:child /> nested into some other tag with wicket:id -- leading to
> the
> very similar issues. I'm sure there can be other examples as well.
>
>
> So perhaps add(..) method doesn't need to be final after all? Or would it
> break something else that I don't know about? If someone could explain
> reasons behind add(..) being final it would be most appreciated -- that
> might change my opinion on the whole subject.
>
>
> Best regards,
> Sergey
>
>
>
> Pedro H. O. dos Santos wrote:
> >
> > If you has some rules for your component, like wrap components, make more
> > sense you extend RepeatingView, create the addComponentAfterWrapHim
> > method,
> > that delegate the call to add method after your customization is made.
> You
> > gain plainness by make clean that this component add method is special.
> >
> > On Mon, Jan 18, 2010 at 10:52 AM, Sergejs Olefirs
> > <Se...@parex.lv>wrote:
> >>
> >> This kind of brings us back to original question -- why is
> >> MarkupContainer.add(..) method final? Maybe it's something that needs to
> >> be
> >> changed (or alternatively mechanism provided for hooking into this
> >> method)?
> >>
> >>
> >> For our own purposes I already adjusted this method to be non-final (but
> >> that means that upgrading Wicket version is going to be slightly more
> >> problematic).
> >>
> >> Declaring it non-final resolved the RepeaterView (actually our custom
> >> component with slightly adjusted functionality) cleanly.
> >>
> >> It also resolved the issue with page inheritance. As it stands right now
> >> (in
> >> out-of-the-box Wicket), if <wicket:child /> is inside of any other tag
> >> with
> >> wicket-id, then children pages can no longer use add(..) method directly
> >> (as
> >> it would then add components in the wrong place in the hierarchy and
> page
> >> rendering will crash). With 'final' gone, it is a simple matter to
> >> override
> >> add(..) in the parent page so that it would add components properly --
> >> thus
> >> children need not be aware of the parent innards.
> >
> --
> View this message in context:
> http://old.nabble.com/final-in-MarkupContainer-add%28Component...%29-method-tp27161187p27211055.html
> Sent from the Wicket - User mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
--
Pedro Henrique Oliveira dos Santos
Re: final in MarkupContainer#add(Component...) method
Posted by Sergejs Olefirs <Se...@parex.lv>.
Thanks again for your reply.
On the one hand, I agree with you, adding custom 'addComponent' method does
make the mechanics of the code more clear.
On the other hand, in practice (we used such methods for a couple of weeks),
it results in the situations in application code where you sometimes have to
use add(..) method and sometimes addComponent(..) method (and in case of
addComponent(..) method, add(..) method is also available, so no compilation
errors there). It invariably led to people forgetting to use
addComponent(..) instead of add(..) and thus application crashing/behaving
incorrectly at runtime. This was extremely annoying -- hence our decision to
un-finalize add(..) method.
On the yet another hand, OO programming kind of implies that objects are
supposed to hide their implementation details, so even disregarding my
previous usability comment, I'm not sure I agree that addComponent(..) is
better than overridden add(..) method from the philosophical point of view.
And if I may to try and adjust the course of this discussion a bit -- the
issue with repeaters is not the only argument against final add(..) method.
As I mentioned in passing, there's also issue of Page inheritance where
subclasses with <wicket:extend> cannot use add(..) method if parent Page has
<wicket:child /> nested into some other tag with wicket:id -- leading to the
very similar issues. I'm sure there can be other examples as well.
So perhaps add(..) method doesn't need to be final after all? Or would it
break something else that I don't know about? If someone could explain
reasons behind add(..) being final it would be most appreciated -- that
might change my opinion on the whole subject.
Best regards,
Sergey
Pedro H. O. dos Santos wrote:
>
> If you has some rules for your component, like wrap components, make more
> sense you extend RepeatingView, create the addComponentAfterWrapHim
> method,
> that delegate the call to add method after your customization is made. You
> gain plainness by make clean that this component add method is special.
>
> On Mon, Jan 18, 2010 at 10:52 AM, Sergejs Olefirs
> <Se...@parex.lv>wrote:
>>
>> This kind of brings us back to original question -- why is
>> MarkupContainer.add(..) method final? Maybe it's something that needs to
>> be
>> changed (or alternatively mechanism provided for hooking into this
>> method)?
>>
>>
>> For our own purposes I already adjusted this method to be non-final (but
>> that means that upgrading Wicket version is going to be slightly more
>> problematic).
>>
>> Declaring it non-final resolved the RepeaterView (actually our custom
>> component with slightly adjusted functionality) cleanly.
>>
>> It also resolved the issue with page inheritance. As it stands right now
>> (in
>> out-of-the-box Wicket), if <wicket:child /> is inside of any other tag
>> with
>> wicket-id, then children pages can no longer use add(..) method directly
>> (as
>> it would then add components in the wrong place in the hierarchy and page
>> rendering will crash). With 'final' gone, it is a simple matter to
>> override
>> add(..) in the parent page so that it would add components properly --
>> thus
>> children need not be aware of the parent innards.
>
--
View this message in context: http://old.nabble.com/final-in-MarkupContainer-add%28Component...%29-method-tp27161187p27211055.html
Sent from the Wicket - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: final in MarkupContainer#add(Component...) method
Posted by Marat Radchenko <sl...@gmail.com>.
> About the ids with digits for repeater, override the onBeforeRender method
> and remove that validation if you need/want.
Impossible. I just filed https://issues.apache.org/jira/browse/WICKET-2684
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: final in MarkupContainer#add(Component...) method
Posted by Pedro Santos <pe...@gmail.com>.
About the lenient form component, I thought that you are having trouble
adding text fields to your form (for example), since they validate the
markup tag (nothing to do with add modifier). As you are adding this kind of
component dynamically, you can't write on development time on your markup,
the correct tag.
About the ids with digits for repeater, override the onBeforeRender method
and remove that validation if you need/want.
If you has some rules for your component, like wrap components, make more
sense you extend RepeatingView, create the addComponentAfterWrapHim method,
that delegate the call to add method after your customization is made. You
gain plainness by make clean that this component add method is special.
On Mon, Jan 18, 2010 at 10:52 AM, Sergejs Olefirs
<Se...@parex.lv>wrote:
>
> Hi,
>
> since I work with Ilya on this project, I'd like to continue this topic as
> it is something I'm keenly interested in.
>
> First of all, thanks for your reply, Pedro.
>
> However I must admit I don't understand your suggestion about lenient form
> components. How is that supposed to work? And at any rate wouldn't it be
> too
> much work (rewriting each component) for something that could be easily
> achieved with minimal code if only the add(..) method wasn't final?
>
> Your comment about RepeatingView seems incorrect (according to my
> experience). As soon as you have something that is not numerical as a child
> ID, the component complains loudly in logs (see
> AbstractRepeater.onBeforeRender()). I also saw post by Igor somewhere where
> he stated that numeric IDs were used for some purpose (hence the warning).
>
>
> This kind of brings us back to original question -- why is
> MarkupContainer.add(..) method final? Maybe it's something that needs to be
> changed (or alternatively mechanism provided for hooking into this method)?
>
>
> For our own purposes I already adjusted this method to be non-final (but
> that means that upgrading Wicket version is going to be slightly more
> problematic).
>
> Declaring it non-final resolved the RepeaterView (actually our custom
> component with slightly adjusted functionality) cleanly.
>
> It also resolved the issue with page inheritance. As it stands right now
> (in
> out-of-the-box Wicket), if <wicket:child /> is inside of any other tag with
> wicket-id, then children pages can no longer use add(..) method directly
> (as
> it would then add components in the wrong place in the hierarchy and page
> rendering will crash). With 'final' gone, it is a simple matter to override
> add(..) in the parent page so that it would add components properly -- thus
> children need not be aware of the parent innards.
>
> Best regards,
> Sergey
>
>
>
> Pedro H. O. dos Santos wrote:
> >
> >>>This brings us to a suggested "wrapping" of the children in
> WebMarkupContainers
> > This is not the only option you have, you can use lenient form components
> > like:
> > public class LenientTextField extends TextField
> > {
> > @Override
> > protected void onComponentTag(final ComponentTag tag)
> > {
> > tag.setName("input");
> > tag.put("type", "text");
> > super.onComponentTag(tag);
> > }
> > }
> > so you have an text field that you can your for any tag you place on your
> > template.
> >
> > About the meaningful wicket ids, you doesn't need to call
> rv.newchildid(),
> > only make sure to don't repeat the ids.
> >
> > 2010/1/14 Ilya German <Il...@parex.lv>
> >> This brings us to a suggested "wrapping" of the children in
> >> WebMarkupContainers, but we'd like to hide it to get rid of the
> >>
> >> webmarkupcontainer item=new webmarkupcontainer(rv.newchildid());
> >>
> >> part. To do this, it seems logical to extend the RepeatingView
> overriding
> >> the add() method to be wrapping every component, however the add()
> method
> >> is
> >> final :(
> >>
> >> Could anyone suggest some other way to resolve this situation? Or,
> >> perhaps,
> >> it could be acceptable to "officially" remove the final modifier from
> the
> >> add() method?
> >>
> >> Thanks in advance!
> >>
> >> Ilya German.
> >
> >
> >
> >
> > --
> > Pedro Henrique Oliveira dos Santos
> >
> >
>
> --
> View this message in context:
> http://old.nabble.com/final-in-MarkupContainer-add%28Component...%29-method-tp27161187p27210046.html
> Sent from the Wicket - User mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
--
Pedro Henrique Oliveira dos Santos
Re: final in MarkupContainer#add(Component...) method
Posted by Sergejs Olefirs <Se...@parex.lv>.
Hi,
since I work with Ilya on this project, I'd like to continue this topic as
it is something I'm keenly interested in.
First of all, thanks for your reply, Pedro.
However I must admit I don't understand your suggestion about lenient form
components. How is that supposed to work? And at any rate wouldn't it be too
much work (rewriting each component) for something that could be easily
achieved with minimal code if only the add(..) method wasn't final?
Your comment about RepeatingView seems incorrect (according to my
experience). As soon as you have something that is not numerical as a child
ID, the component complains loudly in logs (see
AbstractRepeater.onBeforeRender()). I also saw post by Igor somewhere where
he stated that numeric IDs were used for some purpose (hence the warning).
This kind of brings us back to original question -- why is
MarkupContainer.add(..) method final? Maybe it's something that needs to be
changed (or alternatively mechanism provided for hooking into this method)?
For our own purposes I already adjusted this method to be non-final (but
that means that upgrading Wicket version is going to be slightly more
problematic).
Declaring it non-final resolved the RepeaterView (actually our custom
component with slightly adjusted functionality) cleanly.
It also resolved the issue with page inheritance. As it stands right now (in
out-of-the-box Wicket), if <wicket:child /> is inside of any other tag with
wicket-id, then children pages can no longer use add(..) method directly (as
it would then add components in the wrong place in the hierarchy and page
rendering will crash). With 'final' gone, it is a simple matter to override
add(..) in the parent page so that it would add components properly -- thus
children need not be aware of the parent innards.
Best regards,
Sergey
Pedro H. O. dos Santos wrote:
>
>>>This brings us to a suggested "wrapping" of the children in
WebMarkupContainers
> This is not the only option you have, you can use lenient form components
> like:
> public class LenientTextField extends TextField
> {
> @Override
> protected void onComponentTag(final ComponentTag tag)
> {
> tag.setName("input");
> tag.put("type", "text");
> super.onComponentTag(tag);
> }
> }
> so you have an text field that you can your for any tag you place on your
> template.
>
> About the meaningful wicket ids, you doesn't need to call rv.newchildid(),
> only make sure to don't repeat the ids.
>
> 2010/1/14 Ilya German <Il...@parex.lv>
>> This brings us to a suggested "wrapping" of the children in
>> WebMarkupContainers, but we'd like to hide it to get rid of the
>>
>> webmarkupcontainer item=new webmarkupcontainer(rv.newchildid());
>>
>> part. To do this, it seems logical to extend the RepeatingView overriding
>> the add() method to be wrapping every component, however the add() method
>> is
>> final :(
>>
>> Could anyone suggest some other way to resolve this situation? Or,
>> perhaps,
>> it could be acceptable to "officially" remove the final modifier from the
>> add() method?
>>
>> Thanks in advance!
>>
>> Ilya German.
>
>
>
>
> --
> Pedro Henrique Oliveira dos Santos
>
>
--
View this message in context: http://old.nabble.com/final-in-MarkupContainer-add%28Component...%29-method-tp27161187p27210046.html
Sent from the Wicket - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: final in MarkupContainer#add(Component...) method
Posted by Pedro Santos <pe...@gmail.com>.
>>This brings us to a suggested "wrapping" of the children in
WebMarkupContainers
This is not the only option you have, you can use lenient form components
like:
public class LenientTextField extends TextField
{
@Override
protected void onComponentTag(final ComponentTag tag)
{
tag.setName("input");
tag.put("type", "text");
super.onComponentTag(tag);
}
}
so you have an text field that you can your for any tag you place on your
template.
About the meaningful wicket ids, you doesn't need to call rv.newchildid(),
only make sure to don't repeat the ids.
Igor have sent to list time ago an project to make crud forms dynamically,
you can take a look and have more ideas.
2010/1/14 Ilya German <Il...@parex.lv>
> Hello!
>
> We're struggling with working around the final modifier for the
> MarkupContainer#add(Component ...) method.
> We have the following scenario:
> 1. We'd like to use a repeater to add some components to the form.
> 2. We'd like these components to work with CompoundPropertyModel, thus we
> need these to have meaningful wicket ids
> 3. We'd like not to find ourselves backstabbed by the non-numeric ids in
> the RepeatingView's children.
>
> This brings us to a suggested "wrapping" of the children in
> WebMarkupContainers, but we'd like to hide it to get rid of the
>
> webmarkupcontainer item=new webmarkupcontainer(rv.newchildid());
>
> part. To do this, it seems logical to extend the RepeatingView overriding
> the add() method to be wrapping every component, however the add() method is
> final :(
>
> Could anyone suggest some other way to resolve this situation? Or, perhaps,
> it could be acceptable to "officially" remove the final modifier from the
> add() method?
>
> Thanks in advance!
>
> Ilya German.
--
Pedro Henrique Oliveira dos Santos
Re: final in MarkupContainer#add(Component...) method
Posted by Marat Radchenko <sl...@gmail.com>.
2010/1/14 Ilya German <Il...@parex.lv>:
> Hello!
>
> We're struggling with working around the final modifier for the MarkupContainer#add(Component ...) method.
> We have the following scenario:
> 1. We'd like to use a repeater to add some components to the form.
> 2. We'd like these components to work with CompoundPropertyModel, thus we need these to have meaningful wicket ids
> 3. We'd like not to find ourselves backstabbed by the non-numeric ids in the RepeatingView's children.
>
> This brings us to a suggested "wrapping" of the children in WebMarkupContainers, but we'd like to hide it to get rid of the
>
> webmarkupcontainer item=new webmarkupcontainer(rv.newchildid());
>
> part. To do this, it seems logical to extend the RepeatingView overriding the add() method to be wrapping every component, however the add() method is final :(
>
> Could anyone suggest some other way to resolve this situation? Or, perhaps, it could be acceptable to "officially" remove the final modifier from the add() method?
>
> Thanks in advance!
>
> Ilya German.
1. You can use PropertyModel and numeric ids isn't a problem
2. You can wait for resolution on
https://issues.apache.org/jira/browse/WICKET-2684 and (if it gets
fixed) use non-numeric child ids in RepeatingView.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org