Well, yes, in fact, I think we can guess that it would be dangereous an error prone for the developer to have a key of the map with the same name as the property.
So, indeed, it is not a problem if you first check for the property, then the map value. +1 for that, -- Laurent On 10/28/05, Johan Compagner <[EMAIL PROTECTED]> wrote: > don't know if that is weird (that the key is not there) > it can be completely valid. > What happens if i do this: > > map.xxx = yyy > > First i try to get xxx key? > Not there then i try to get xxx as a property > still not there the back to the map? > > i still think that i can first check for the expression as a property then > if not found it is map value > (doesn't matter if the key isn't there or not) > > johan > > > > > On 10/28/05, Laurent PETIT <[EMAIL PROTECTED]> wrote: > > > > On 10/28/05, Johan Compagner <[EMAIL PROTECTED]> wrote: > > > > Does Wicket also check for direct public property of the same name ? > > > > > > not yet, but that is easy to build. > > > > That would be great. > > > > > > Same remark concerning maps vs beans. > > > > > > > > If find it great if we don't know if the property is contained in the > > > > Map or is a property of the Model. > > > i am alos still in favor the current impl by just doing dots nothing > more. > > > The only thing is that for maps that are also a bean is a bit difficult. > > > But i find that a bad idea anyway.(a map that is also a bean) > > > > Yes, I agree, and for the following reason: the use case I thought of > > was that, during refactoring, the model is first implemented using a > > Map, and when it is needed to have an object instead (in order to do > > some logic in the getter/setter, or for whatever reason), the Model is > > replaced by an object. > > > > And then only the creation/injection of the model has to change, not > > all the references to getter/setter. > > > > > > if the object is an instance of a Map: > > > > first try to interpret prop as a Map key > > > > > that will never fails (if it is a setter) (mymap.xxx = yyy) > > > So i think it must be the other way around. > > > First try to do a setter and then if that fails use it as a map. > > > > Yes it's true, I only thought of the get() part of the problem, shame on > me. > > But, as we are in the semantics of accessing an "existing" property, > > what about doing a get() before the set. > > And if the get() returns null, deduce that this is not a Map property > > we want to bind to, and search javabean properties, then public > > properties ? > > > > This does not seem to weird to me, since the absence of the key would > > be as bad as the absence of a getter in this use case ? > > > > > > ------------------------------------------------------- > > This SF.Net email is sponsored by the JBoss Inc. > > Get Certified Today * Register for a JBoss Training Course > > Free Certification Exam for All Training Attendees Through End of 2005 > > Visit http://www.jboss.com/services/certification for > more information > > _______________________________________________ > > Wicket-user mailing list > > Wicket-user@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/wicket-user > > > > ------------------------------------------------------- This SF.Net email is sponsored by the JBoss Inc. Get Certified Today * Register for a JBoss Training Course Free Certification Exam for All Training Attendees Through End of 2005 Visit http://www.jboss.com/services/certification for more information _______________________________________________ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
