2011/7/18 Norman Maurer <[email protected]>: > Hi there, > > just to be more clear. I'm not very strong with it, so if others > prefer we can just release it like it is...
I leave this to you and Oleg. Either way it is not an elegant solution and we'll need to fix that part of the api (configuration + advanced features) in future releases (IMO). Stefano > 2011/7/18 Norman Maurer <[email protected]>: >> 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 >>> >> >
