Maybe use some extra interface which just contains the property names. It just looks ugly to not have them somewhere as a static field the dev can use to set this kind of stuff. Typing the name is kind of error phrone ..
Bye, Norman 2011/7/18 Stefano Bagnara <[email protected]>: > 2011/7/18 Norman Maurer <[email protected]>: >>Stefano Bagnara wrote: >>> My main concern is that "dom" api is a lot limited unless you use >>> "setAttribute" with some magic parameter that you expect to work like >>> our default implementation does. This doesn't sound good to me for an >>> API. >>> >>> That said I'm fine with a 0.7 release from current trunk. It's not >>> perfect, but a step forward from previous releases. >> >> i think it would sense to expose those property names as public static >> fields. are you guys ok with it? If so I will commit the this and >> after that start the release process... > > Don't know: in what class would you publish them? If they have to be > part of the interface then why not to add specific/typed setters for > each property? Instead if they have to be in the implementation I > don't think it worth using them as (if used) it would break even more > the service locator pattern. > > Stefano >
