Sounds good. I'll have to go take a look at it. Bamboo.Prevalence that is. Ian Scott Hernandez wrote:
Yep, I reviewed that and it was not up to snuff. It was an example of how you could do it. Not a real world implementation. The Bamboo.Prevalence implementation is much farther along. I'll approach them about splitting that out into its own project. There will be enough there to justify that I think.
----- Original Message ----- From: "Ian MacLean" <[EMAIL PROTECTED]>
To: "Scott Hernandez" <[EMAIL PROTECTED]>
Cc: "Nant-Developers (E-mail)" <[EMAIL PROTECTED]>
Sent: Tuesday, January 06, 2004 8:21 PM
Subject: Re: [nant-dev] Inter-Task XML Communication (WAS: new xml type)
HavingUsing xpathnavigators for this stuff would be nice. There was an msdn article a while back implementing an xpathnavigator interface over a zip file. It would work well for any sort of hierarchical data. +1 on using some sort of hierarchical storage for task inputs and outputs.
Ian
Scott Hernandez wrote:
I'm getting a better picture.
There are many places where inter-task communication would be useful.
don'tthe context of what is going on around a task is very interesting. I
areknow much about how msbuild works, but I get the idea this is what they
functionality.pushing as the mechanism for tying together their tasks, and
thatThe 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
joba task needs to know what is around it (preceding and such) to get its
possiblydone 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,
thatin-memory, instance of the xml documents (or xpathdoc). I helped write
something called domify (domify.sf.net) in java, a long time ago now,
intowrapped a java bean (object) in a W3C dom facade. Then you could put it
samean existing document, run xpath expressions against it, and such. In the
.Net world there is the idea of a xpathobjectnavigator that can do the
classeswith .Net object so they can interact directly with an xmldocument, xpath
expression, and such. This might be a great way to expose our nant
fewas xml objects, instead of actually serializing the object. There are a
baseprojects 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
ml/xml03172003.aspat this point, AFAIK.http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnexxml/ht
There are some additional comments inline below:
*XPathObjectNavigator stuff:
http://cvs.sourceforge.net/viewcvs.py/bbooprevalence/Bamboo.Prevalence/src/Bamboo.Prevalence.XPath/
mean?----- Original Message ----- From: "Matthew Mastracci" <[EMAIL PROTECTED]>
[snip]
+1, for seamless and handled by the core.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).
The XmlSerializer stuff can create xml schema for us, is this what you
nant
Are you saying that we would serialize these objects to disk for use byIf 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.
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
--
Ian MacLean, Developer, ActiveState, a division of Sophos
http://www.ActiveState.com
------------------------------------------------------- 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
