Ian
Scott Hernandez wrote:
I'm getting a better picture.
There are many places where inter-task communication would be useful. Having the context of what is going on around a task is very interesting. I don't know much about how msbuild works, but I get the idea this is what they are pushing as the mechanism for tying together their tasks, and functionality. The only problem I start to see is that there becomes a situation of inter-dependence and a complication of context. If it gets to the point that a task needs to know what is around it (preceding and such) to get its job done it may get too complicated to write and test.
As for the XML related tasks (xmlpoke/peek/foreach, solution, style/xsl, etc) it would make sense to allow them to interact with a single, possibly in-memory, instance of the xml documents (or xpathdoc). I helped write something called domify (domify.sf.net) in java, a long time ago now, that wrapped a java bean (object) in a W3C dom facade. Then you could put it into an existing document, run xpath expressions against it, and such. In the .Net world there is the idea of a xpathobjectnavigator that can do the same with .Net object so they can interact directly with an xmldocument, xpath expression, and such. This might be a great way to expose our nant classes as xml objects, instead of actually serializing the object. There are a few projects underway that do something like this, but I have been thinking I should write a full featured library that does this (creating a xpathobjectnavigator that supports and respects the xml serialization attributes). The bamboo.prevalence team has the most fleshed-out code base at this point, AFAIK.
There are some additional comments inline below:
*XPathObjectNavigator stuff: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnexxml/html/xml03172003.asp http://cvs.sourceforge.net/viewcvs.py/bbooprevalence/Bamboo.Prevalence/src/Bamboo.Prevalence.XPath/
----- Original Message ----- From: "Matthew Mastracci" <[EMAIL PROTECTED]>
[snip]
What I'm proposing is that the NAnt build script writer user would use the task outputs as if they were XML, but under the hood they would be fully-fledged C# classes.
We all agree that the "xml" object type that Martin is suggesting would be used within any XML task within the build script as raw XML. It would fit snugly into the <xmlpeek>/<xmlpoke>/<xmlforeach> tasks.
I'm proposing that we back these "xml" documents with fully-fledged C# objects in the NAnt backend. I hope that this would lead to long-term, schema/class-enforced XML communication of some sort between tasks. Each task could expect and produce certain kinds of wellformed data.
Each "xml" input or output from an NAnt task would be mapped to an
XmlSerializer-ready NAnt class, preferably backed by a true .xsd file
somewhere within NAnt. This serialization would be automatic and
handled by the NAnt core without task writer intervention (modulo some
attribute decoration).
+1, for seamless and handled by the core.
The XmlSerializer stuff can create xml schema for us, is this what you mean?
If each xml object could tag along an associated schema, this would
enforce the validity of the object during user manipulation of the XML
object, allowing it to be "re-imported" into the NAnt world at some
later date.
Are you saying that we would serialize these objects to disk for use by nant during another execution, or just during the current one? What is the application of this?
Does this make sense?
------------------------------------------------------- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click _______________________________________________ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
