Hello,

thanks for your very fast patch! That shows again where OSS beats
commercial software :-)

I tried the latest SVN snapshot with my little example, and the
behaviour is now as expected. I still have to try my full app, but I'll
probably just wait for 1.2.1 here (still in development).

I'd be glad to provide some docs etc. for this subject in the next days.
What would be the best way for providing JavaDoc-Patches? Just changing
the latest file from SVN, and posting it here?

Is there maybe a way to avoid this additional <span> inside <optgroup>
and just use the <optgroup> which then of course should not vanish? The
span will always be marked as invalid HTML in editors... I played with
setRenderBodyOnly(), but that didn't change anything no matter what.
Sure, there won't be always the relation 1 SelectOptions -> 1
<optgroup>, but still... ;-)



Also, thanks a lot for your explanation regarding model chaining. I
think I understand the problem now. I'm not yet sure how to go around
this everywhere, but I will now try to avoid Compound models where a
deeper chaining might be necessary. Maybe I'll manage to come up with an
example where I stumbled upon this where it was not possible to just use
the model bean, as there was just a (compound) model available.


greetings from Berlin,

Rüdiger Schulz



Igor Vaynberg schrieb:
> On 6/26/06, *Rüdiger Schulz* <[EMAIL PROTECTED]
> <mailto:[EMAIL PROTECTED]>> wrote:
> 
>     Hello everybody,
> 
>     I have a problem with wicket.extensions.markup.html.form.select.Select.
>     If a form containing such a dropdown is submitted with errors, the
>     selection is not remembered.
> 
>     I have attached a simple demonstration showing that, which can be put
>     into QuickStart directly. The textfield is required. If you keep it
>     empty, and select e.g. Option 3, Option 1 will be selected again after
>     the submit. If you submit the form successfully, Option 3 is selected.
>     If you leave the textfield empty again, and select Option 2, Option 3
>     will be the one to show up. I can't say for sure if this is a bug, but
>     it seems like that to me.
> 
> 
> yep, this was a bug. just fixed it in subversion, do you mind testing it?
> 
>     Coming that far was hard enough, so if this could be worked out, I'd be
>     glad to put a usage example in the Wiki (the JavaDocs lack a usage
>     example).
> 
> 
> a patch to javadoc would also be welcome, there is actually a todo in
> the javadoc to provide a usage example :)
>  
> 
>     A thing that bothers me with adding options that way, is that there
>     needs to be a span inside the <optgroup>, because if I put the wicket:id
>     into the <optgroup>, it will not show up in the HTML (just its
>     children). Having to put a <option wicket:id="option"></option> inside
>     of it was a bit weird to me at the beginning, but this is not a problem,
>     if it were mentioned in the docs somewhere :)
> 
> 
> yeah, SelectOptions is a quicky way to do it and it needs the span that
> is not rendered. once again, a patch to javadoc is more then welcome :)
> 
>     Another problem I still have is with understanding model chaining. In
>     the example you can also see a (commented out) Label, which should
>     display the current value of the dropDown property of the model bean. I
>     thought this could be done with a chained PropertyModel. But the value
>     for the Label still seems to be taken via the id of the Component, and
>     not via the expression provided with PropertyModel. What would be the
>     correct way to do this, other than changing the id of the Label?
> 
> 
> well, lets see what you are doing...
> 
> ModelBean bean = new ModelBean();
> IModel model = new CompoundPropertyModel(bean);
> Label l = new Label("debugLabel", new PropertyModel(model, "dropDown"));
> 
> so you are creating propertymodel with an object which is a model
> 
> when propertymodel's getobject is called it first checks if the
> object it is passed on is a model or just an object. if it is an object
> it performs property resolution, but if it is a model it first calls
> getobject on it because it would make little sense to do property
> resolution on an instance of IModel.
> 
> so this is where the problem is: getObject is called on model object you
> declrared, which is compound; so it in turn tries to resolve a property
> on the bean with the component's id, thus you get the No get meothod
> defined for modelBean, expression: debugLevel because the compound
> model's getObject tries to return modelBean.getDebugLevel which is the
> id of the label.
> 
> hope this clears things up, if you want to fix it pass in the bean
> object itself instead of the compound model.
> 
> -Igor
> 
> 
> ------------------------------------------------------------------------
> 
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Wicket-user mailing list
> Wicket-user@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wicket-user


Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Reply via email to