Nicola Ken Barozzi wrote:
But we can have top-level tasks...
So called top-level tasks should only set properties, import
stuff, define file sets and such and perhaps do a few other
selected things. All Ant elements. Allowing arbitrary commands
at top level is a bad idea, one reason being the problem of
nailing down a sensible execution order if there are arbitrary
side effects. This has been argued up and down, so I'm not
going to start this again. It's going to correct itself anyway.
3) all namespaced tags that are not declared as in (2) must be declared
beforehand as <namespacedef namespace="nms" handler="..."/>, so that the
Ant ProjectHelper can use that particular Handler to process the
extension. A convenient nullHandler is created when the handler is not
specified.
I'd stick with binding classes to the task's QName for a while.
For example, it seems to be a bit of an overkill to write
a handler class just for adding a single task. Add the handler
later if necessary.
Currently they are used only when reqesting a property in ${}, and it
may be really confusing to have them also in the names, I tend to agree.
Using QNames for something else than element or attribute names
is *abuse*. After all, the prefix is bound to an *XML* namespace,
not a property namespace or something.
On the other hand I can have clashes of names, but it can also be a
"feature", and not a problem that cannot be resolved with good naming
rules.
If clashes prove to be a problem, and can't be cured by resonable
scoping rules, some sort of namespaces may have to be introduced,
but *don't* use XML namespaces for this purposes. Invent property
namespaces if necessary.
Sorry, I don't understand, can you please explain it with an Ant
example? Thanks.
This was an Ant example
main file main
importA imports file importA
importB importA imports file importB
target X importB declares target X
target X importA declares target X
> But super.x can enable you to automatically collect features:
Automatic collection may cause unintended behaviour:
main imports A
A imports B
B declares X
A declares X, but does not call X imported from B
main imports B
somewhere in main super.X is called
What's the expectation: is X from B executed or not?
Is it executed before or after X from A?
I have the feeling that having exactly one imported target
executed and multiple matches reported as error will prevent
nasty surprises. For example I think I can construct a circular
dependency which can only be detected after some tasks have
already been executed. I'll try a bit harder tomorrow.
Also, I'm not too fond of the inflation of small expression
languages (comma separated lists, dot separated names...)
[BTW, is whitespace allowed around the dot?].
And I like to be able to process such expressions easily
with current XSLT processors, in a portable way. Comma
separated lists qualify nearly but not quite for "easy".
Hmmm... so tasks should have namespaces, targets and properties cannot,
since they are not elements.
Mapped to OO, tasks are classes, targets are instances (of class "target")
and so on. Another way to point out that there are differences.
> > write a complete specification
> We're slowly getting there anyway ;-)
Sorry? I seem to be missing something...or is it just too slow
to notice?
J.Pietschmann
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
