Hi Jaroslaw,
Not a lot really at the moment. But keep in mind that this was one
nights hacking that got this code produced. The end game is to have the
ability to specify arguments that the task accepts so that might look
something like this:
<taskdef>
<attributes>
<attribute name="file" optional="false" />
</attributes>
<tasks>
<sometask someattribute="${file}" />
</tasks>
</taskdef>
One important thing to note here is that the attributes on the task
would get converted to properties for the tasks inside the tasks
element. I'm looking to implement a prototype of this this week.
To really lock it down I'd like to have some kind of scoping mechanism
build so that the ${file} property wouldn't be visible outside the task,
this would lead to less "interesting" bugs from an end-users point of
view.
I'm note quite sure how this would work, but I'm thinking of Nant
execution as a stack. As you transition through each stack frame (nant,
call, task, target, task container etc) a scope object is added. Then
when property lookups are done they look at properties associated with
the local scope first, then walk back up (there could be some additional
rules here). It sounds complicated which is why I want to implement
something on my local sandbox to see if I can make it simple.
When declaring properties I thought that there could be an additional
attribute that defines its visibility. The default would be global to
retain compatibility with current scripts.
<property name="foo" value="bar" scope="global|local|tree" />
Tree is an interesting one, it basically says its visible to the current
stack frame, and stack frames below it. Global and local should be
obvious.
As I said this taskdef could potentially drive a few other
enhancements/changes in the engine. Can I get an expression of interest
in:
1. <taskdef />
2. Scoped properties
----------------------------------------
- Mitch Denny
- [EMAIL PROTECTED]
- http://www.monash.net
- +61 (414) 610141
-
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Jaroslaw Kowalski
Sent: Saturday, 17 January 2004 10:28 PM
To: Mitch Denny; [EMAIL PROTECTED]
Subject: Re: [nant-dev] Idea: Inline task definitions (task
orchestration/macros).
What's wrong with <call> task?
<project>
<target name="foobar">
<echo message="Hello" />
<echo message="World" />
</target>
<target name="build">
<call target="foobar" />
</target>
</project>
Jarek
----- Original Message -----
From: "Mitch Denny" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Saturday, January 17, 2004 11:34 AM
Subject: [nant-dev] Idea: Inline task definitions (task
orchestration/macros).
> Hi folks,
>
> I had a chance to do some tinkering last night on a feature that I
have
> desperately wanted in Nant for quite some time. The ability to do
inline
> task definitions in XML that orchestrate a number of other tasks. It
> works like this:
>
> <project name="test">
> <taskdef name="foobar">
> <echo message="Hello" />
> <echo message="World" />
> </taskdef>
> <target name="build">
> <foobar />
> </target>
> </project>
>
> I've managed to get an implementation of this working by making a
number
> of minor modifications to the source. The list of source files
affected
> is:
>
> 1. Project.cs
> Added a loop to the InitializeProjectDocument method which reads the
> taskdef elements and creates a task builder for them. Also modified
the
> loop that executes the global tasks so that it ignores the taskdef
> elements and doesn't treat them as tasks.
>
> 2. TaskBuilder.cs
> Added a new constructor which takes an XmlNode so the task builder can
> pass that onto the InlineTask instance when it is created. Also added
a
> property IsInline as a flag to the task builder's CreateTask
(modified)
> method to know to handle them in a special way.
>
> 3. InlineTask.cs
> This is a new class. This class takes the XmlNode that was stored with
> the TaskBuilder when the project file was read in. It's a
TaskContainer
> so it just calls ExecuteChildTasks (modified).
>
> 4. TaskContainer.cs
> Added an overload for ExecuteChildTasks which allows the InlineTask
> class to override which XmlNode it users to parse over.
>
> I think that is pretty much it, although if I went through and did it
> again I'd be tempted to refactor things a little bit. Anyway, where I
> see this being useful is helping lower the barrier to entry for task
> developers by allowing them to just have .build files that they can
> include in without having to cut real code (and therefore have a build
> system for that code). I've tested that this works with include files
> and it does (so far).
>
> You might be wondering how this differs from target elements, and I
> think there is little difference to be honest, other than it feels
more
> consistent when all you are doing is orchestrating the functionality
of
> a number of tasks for reuse. It could also drive a few other tweaks
such
> as the ability to have "private properties". On the taskdef element,
> somehow I'd like to be able to specify attributes which can be used
just
> like properties for the tasks contained within the taskdef, but have
> their scope limited just for that run.
>
> I think there is enough to bite off there!
>
> ----------------------------------------
> - Mitch Denny
> - [EMAIL PROTECTED]
> - http://www.monash.net
> - +61 (414) 610141
> -
>
>
>
> -------------------------------------------------------
> The SF.Net email is sponsored by EclipseCon 2004
> Premiere Conference on Open Tools Development and Integration
> See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
> http://www.eclipsecon.org/osdn
> _______________________________________________
> nant-developers mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/nant-developers
>
-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
nant-developers mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/nant-developers
-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
nant-developers mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/nant-developers
