On Thu, 4 Jul 2002 18:28, Peter Donald wrote: > At 12:32 PM 7/2/2002 +0000, you wrote: > > - Changed DefaultProjectBuilder, so that it builds projects with a > > single <init> target, > > containing the entire project, including all the <target> elements > > (which get added > > as targets as the <init> target executes). Also cleaned out > > ConvertingModelBuilder, > > since there is no longer any need for it to reorder the top-level > > elements. > > Not a fan of this. It makes it difficult (impossible?) to have a GUI > frontend to look at all the targets in project or whatever. Because there > is only one "<init>" target.
Indeed. The plan is to give the project builder the option to choose whether to statically or dynamically assemble the project (or both). The current DefaultProjectBuilder happens to have chosen dynamic assembly. And when gui's that want to get at the targets start appearing, then we can change DefaultProjectBuilder to do some static assembly. In the meantime, static assembly is kinda pointless - just adds inertia. > As a matter of fact I can't really see any benefit of dynamically adding > targets to a project at all? I think the main benefit is that it allows the project model to be extended and experimented with, without needing to write a new project builder. Or without even cutting any java code. By adding targets at runtime, using tasks, you can take advantage of all the good stuff that using tasks gives you: - Can use properties during assembly (including that new-fangled DOM datatype). - Can code up assembly logic using tasks, or in java, or as a template, or some script, or a stylesheet. Or whatever else you can define tasks with. - Can include assembly logic in the project file itself. No need to compile and install a ProjectBuilder. Which makes it easy for someone to use a vanilla myrmidon install to build a project that has a weird model. - Can swap in an alternative <target> impls, or add new types of targets, to augment the plain <target>. Regardless, it's early days of experimenting with the project model. Maybe dynamic assembly is a good idea, maybe its a dud. Don't know yet (but I have my suspicions :). > Is there something that can be done via this > method that can not be done with templates? It's more a case of what they add to templates. Combine dynamic assembly with templates (that is, templates that dynamically assemble a project), and you can put together a whole range of seriously powerful templates. Without that, templates are (to me) not particularly compelling. They're ok, but I'd probably use <for-each> for most things that templates would be useful for. -- Adam -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
