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).
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.
Does this make sense?
Scott Hernandez wrote:
This sounds interesting but I'm not sure I follow. Can you explain a little more?
The concept of inputs/outputs to tasks (when called from other tasks) and adding context info so tasks know about following task, and preceding tasks, sounds interesting. But I'm not sure how this ties in here.
What would the user experience be? What would the syntax be?
----- Original Message ----- From: "Matthew Mastracci" <[EMAIL PROTECTED]>
For tasks (such as the solution task), what about having C# classes in NAnt that map to XML itself? They could appear as XML to xmlpeek/xmlpoke/xmlforeach, but would be backed by C# classes internally.
This would make it far simpler to "return" values from tasks.
Martin Aliger wrote:
Hi all,
I'm trying to develop new xml type. Right now I have some preliminary
patch
to enable script like this:
<xml id="x1"> <book> <author> <name>John</name> <surname>Smith</surname> </author> <title>John Smith's life</title> </book> </xml>
<target name="test"> <xmlpeek refid="x1" xpath="book/author/name" property="authorname"/> <echo message="${authorname}"/> </target>
How you like it? I'm looking forward to your comments...
What I want to do is something James and Ivan also proposed: add some
way to
return information from task back to script. I dont think that add resultproperty/outputproperty to exec task and other whateverproperties
to
other tasks is good way. What I want to do is add one general attribute (e.g. result) to all tasks. Result itself will be xml dom with
potentionaly
many values. exec task could for example have in it full commandline executed, result code, stdout, stderr and maybe even more things! So it could be written something like this:
<exec program="${csprojconv.dir}\Gordic.Develop.CsprojConverter.exe" commandline="${foldername}\${folder}.csproj ${version}" result="res1" /> <xmlpeek refid="res1" xpath="output/resultcode"
property="resultcode"/>
<if test="${resultcode>2}"> <fail message="serious CsprojConverter error"/> </if>
or even shorter when function for xmlpeek exists!
Martin
------------------------------------------------------- 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
------------------------------------------------------- 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