I am a little saddened that my original post was not clear :-)
Well, I don't know in what way your post was unclear. I find that people are often saying that they were being unclear, or that I misunderstood them, when the fact is that I understood their points perfectly well, but basically just disagreed.
And it's not so much that I disagree either. I understand that there are, in principle, some benefits to standardizing on one presentation tool. OTOH, I still basically think that, overall, the arguments for restricting choice are bound to be weaker and more tenuous than the arguments in favor of choice. Particularly in the context of an open-source project, where the usual ethos tends to be all about giving users choices. Interoperating with other open-source tools almost unambiguously adds value. That, in fact, is why I am bothering to make the case for the FreeMarker-AndroMDA glue code. I feel it adds some value to FreeMarker, even though I have practically no real stake in it. I just want 3rd party tools in general to interoperate with FreeMarker, on the theory that it's win-win on both sides.
If you look at my original posting you'll see I didn't really express an opinion as to whether or not we should add FreeMarker support to AndroMDA. What I tried to do in my post was to start a discussion on the points that I thought were relevant if we wanted to consider adding FreeMarker support to AndroMDA.
Here is the way I see the issue again. There are two distinct issues to being considered:
1) the decoupling of AndroMDA from any particular scripting engine (i.e. Velocity) 2) the addition of FreeMarker as a supported scripting engine alternative
So here is my opinion on the topic. Point (1) just seems like a good thing to do from an architectural point of view. I cannot see any strong reasons for why we'd want AndroMDA to continue to be so tightly coupled to Velocity. Just because we decouple AndroMDA from Velocity does not mean we must provide an alternative scripting engine. It just means that we can.
Well, the above distinction is certainly valid theoretically. However, as a practical matter, I don't really know how far this goes. After all, nobody is likely to donate a patch for 1) unless they want 2) as well -- not necessarily FreeMarker support, mind you, but some alternative. So, to say that you like aspect 1) of the patch, but don't like aspect 2) that it actually provides a choice of template engines, seems a bit iffy to me. In practice, 1) and 2) stand and fall together.
Point (2) is not so clear to me. I believe Jonathan has stated the case very clearly. Would AndroMDA be served well by the "friendly fascism" of not providing alternative scripting engines? Or would AndroMDA be better served by providing alternatives? Jonathan thinks yes. I honestly do not know, but I don't think more choices is clearly better. I actually see it as a really hard call to know what is the right thing to do. Honestly I would be ok with it going either way.
Well, I think the onus is much more heavily on the "friendly fascism" side to make their case clear than the other side of the debate. I mean, it's also really a kind of "less is more" sort of argument, that by supporting only one presentation solution, rather than more than one, you have something more focused and coherent or whatever -- i.e. less is more.
Well, yeah, there are cases where less is more, I suppose. However, the normal situation is that less is simply less. "Less is more" has its sort of paradoxical side, and I think that when you're going to make that kind of argument, there's more onus on you to make *your* case clear. To set up things such that the onus is on the other side to explain why the extra power and flexibility is desirable seems wrong to me; there is a stronger onus on the person arguing against the extra options to make *their* case. Or more concretely, Sebastian clearly prefers to use AndroMDA in conjunction with FreeMarker. Clearly, the patch adds value to him because, otherwise, presumably, he would not waste his time with it. I think there's a much stronger onus on you to justify rejecting it than for Sebastian to make the case for the patch.
Anyway, the above is fairly abstracted, the issue of offering more options to your users. Getting back to concrete issues, another factor you might strongly consider is Velocity's significant deficiencies in terms of creating reusable templates -- i.e. macro libraries, the main thing being the utter lack of any notion of namespaces. Whenever you #include more than one template containing macros, there is some possibility that the macro definitions will clobber one another. Velocity has terrible problems in terms of controlling the output of whitespace -- which is often not so bad in (mostly) whitespace-insensitive formats like HTML, but can be crippling elsewhere.
If you were going to impose a single template engine on your user base in the interests of avoiding fragmentation, I think it would make sense to perform some due dilligence to make sure that the solution you were imposing was technically the best one.
I think it would also make sense to ask your users about such issues.
Regards,
Jonathan Revusky -- lead developer, FreeMarker project, http://freemarker.org/
------------------------------------------------------- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01 _______________________________________________ Andromda-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/andromda-devel
