On 13 Mar 2002, Stefan Bodewig wrote: > On Fri, 8 Mar 2002, <[EMAIL PROTECTED]> wrote: > > > Ok, everything can be done with no code change in > > RuntimeConfigurable except making some fields protected. > > Or add accessors instead of touching the attributes directly.
Adding accessors would be my preference. If we do so, I would prefer using xml-independent accessors - addAttribute( String name, String value ); ( or ns, name, value ) instead of AttributeList/Attributes. Having the core depend on sax1 is not very clean, so I would deprecate the use of sax1 attributes. Of course, the current interfaces are easy to support for backward compat, just stop using them in new code. > > It's pretty smart code, I'm impressed > > Well, I've certainly heard different statements, but UnknownElement is > the worse of the two, I agree. ;-) Yes, but UnknownElement can be avoided by using the ProjectComponentHelper. AFAIK the main purpose for UnknownElement is to deal with tasks that can't be constructed at runtime ( for example they are taskdef-ed in a target ). The default ProjectComponentHelper may treat them in the same way as 'external' components, and use the task adapter - which can delay the construction of the object if it wants to. I'm not talking about the current TaskAdapter, the ProjectComponentHelper may return different subclasses - I think the ProjectComponentAdapter should be just a base class ( even interface ), so we move more functionality out of core and into plugins. > > For consistency, we should have all tasks use the > > RuntimeConfigurable, even if they are top level > > What would you gain by this change? The top level tasks will be > executed immediately anyway. Or do you propose to defer the execution > until parsing has finished? Consistency ( and simpler code ) in the xml processor. We can't defer the execution - that would change the behavior, the default must remain backward compatible. But I'm not saying we shouldn't support defered execution, or any other feature that may be interesting - just that the default should be what we have, and the core API should permit anything. Costin P.S. I'll have little time this week, I have the changes required by Connor on ProjectHelper and a bit more code on the component helper, but I need more tests. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
