As far as I can tell from ant things work a little differently from what
we are talking about.
Ant defines a Reference object that DataType(s) holds onto. Then the
FileSet (derived from DataType) looks at the Reference object and uses
it, in combination of its own xml to do the job. This would require each
refid'd task would have to know how to deal with a Reference.
I'm much more of the opinion that should do the xml merging, or double
xml initialization.
See the rest of my comments below.
> -----Original Message-----
> From: Tomas Restrepo
> Subject: Re: [nant-dev] FileSet includes question
>
> Hi Gerry,
>
> > <echo refid="HelloEcho" message="Goodbye!"/>
> > <!-- here the echo task gets init'ed with 'Hello, World!' then gets
set
> > to 'Goodbye!'. -->
>
> humm... For tasks with simple attributes, this makes quite a bit of
sense,
> and it's semantically simple. However, what would be the semantics for
> more
> complex elements, say, a FileSet?
This does become a little more complicated.
> For example, consider this:
>
> <fileset id="Fileset1">
> <includes name="src/**/*.cs"/>
> <includes name="tests/**/*.cs"/>
> </fileset>
>
> <fileset refid="Fileset1">
> <excludes name="src/file.cs"/>
> </fileset>
>
> What would the semantics be? Should the second FileSet
excludes/includes
> element be "merged" with the original FileSet's filelist? Or should
the
> list
> be replaced? I think the correct solution would be to Merge them (iow,
in
If you wanted to replace things, you could just start over with a new
fileset, without the ref.
> the example above, you'd end up with a fileset with two includes and
one
> exclude. However, I'm not sure this would be the best solution in all
> cases.
Merged would be my first response. It would also require that the
fileset(task) know that it may be init'd more than once.
> A second thing I have been considering is that during reinitialization
> what
> you really want is to copy the original element instance. IOW,
elements
> should be clonable. Why? Well, if you always made changes on the same
> object
> that was initialized when the element with the id attribute was found.
I'd say that we should just use the xml that was used to init that
element, not the element itself.
BTW. Element does have a copy ctor but doesn't support ICloneable, or
Copy().
> Otherwise when you refid'd a single element more than once later in
the
> buildfile, there's no way you could predict exactly what that element
> would
> contain. For example, if I created yet another fileset referencing
> Fileset1
> above, what would it be referencing? A FileSet with two includes, or a
> FileSet with two-includes and one excludes? I think the first behavior
is
> what the user would expect, and it's the easier to deal with in
complex
> buildfiles... What do you guys think?
I'd be inclined to make the rule something like this.
--If extra xml is defined in the ref'd element, do the double xml init.
<fileset id="Fileset1">
<includes name="src/**/*.cs"/>
<includes name="tests/**/*.cs"/>
</fileset>
<fileset refid="Fileset1">
<excludes name="src/file.cs"/>
</fileset>
Results in something like this for ref'd one
<fileset>
<includes name="src/**/*.cs"/>
<includes name="tests/**/*.cs"/>
<excludes name="src/file.cs"/>
</fileset>
And 2 fileset objects being created, which are not connected.
--If no extra xml is defined in the ref'd element, use a object ref.
<fileset id="Fileset1">
<includes name="src/**/*.cs"/>
<includes name="tests/**/*.cs"/>
</fileset>
<fileset refid="Fileset1"/>
Results 1 fileset object and both fileset xml decls using them.
> Finally, am I right in assuming that given NAnt's current behavior
when
> loading the buildfiles, this would require that an element can only be
> refid'd _after_ the original element with such _id_ appears? IOW, in a
> sortta-programming-language-like way, elements can only be referenced
> after
> they have been defined?
Yes, this is currently a problem. I've been thinking about supporting
lazy init'n so that all id/names are resolved, then the tasks/elements
are evaluated during Execute. The scheme I've described above should fit
well with a lazy init scheme.
It would make sure that name resolution working independently of where
you defined the link. Order would not be a problem as it is now.
The other thing to keep in mind is that with this scheme we would
probably use an XPath expression like //fileset[id='foo'] to find the
source element. This would require a full document traversal to find the
element. So once you use a ref, you could incur some performance
penalties.
I'm wondering if there is some general XML technology that could help us
out during xml reading.
I don't expect this to be too big a deal, but I just brought it up for
an FYI.
-------------------------------------------------------
Sponsored by:
ThinkGeek at http://www.ThinkGeek.com/
_______________________________________________
Nant-developers mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/nant-developers
