> > The current behaviour is imo easy to grasp: either you define a > > getter/setter for a component, or the component will look for a > > property with the component's name in the data object. So > i'd vote to > > keep it that way. > > Please don't ignore real-case scenarios where this means a > real overhead. I could reduce in fact twenty lines per form > definition in my current code if this was possible, which > would make the whole form structure much more cleaner and > easier to comprehend. i can perfectly imagine that in certain situations overriding the default getter/setter can make sense. it's just that adding getter/setter properties to the Form prototype as proposed by stefan appeared misleading to me at first glance, as these methods actually aren't used by the form instance. but then, defining them where the data object is defined too doesn't look that illocical to me as it did in the beginning. nevertheless, this still adds a second place where getter/setter can be defined, but we'll see if this really makes things too complex. so i'm fine with it (finally :) robert