Il giorno 28/lug/04, alle 08:12, Antonio Gallardo ha scritto:
I agree. The idea I buyed from XML was that we don't need to add new parsers, easily transformations using XSLT, etc. and that is a point we will lose.
We have 74 classes to maintain in the o.a.c.components.treeprocessor package. It's true that you don't have to write the code to turn <map:*> into org.w3c.dom.Element but other than that ...
You know that I like Groovy. and I thought about that long time ago, but I
was no brave enough to propose a Groovy syntax because the problems
parsing the Groovy code for later purposes. Note, I am not droping the
idea. I think we need to see closer to the pros and cons about a Groovy
sitemap syntax.
Yes. That's why I presented a half-baked idea instead of a working implementation. To have a platform upon which to base further discussions.
I still have the idea that we need an IDE for Cocoon and using non-XML
syntax will be harder to parse. Just think what if we need to build an
non-XML reader to interpret the sitemap. With an XML syntax it is a very
easy task. Perhaps Sylvain call tell us more about this since they are
developing a tool for Cocoon.
There are plugins coming out for Grrovy on various IDEs (I know Eclipse has one) and syntax-highlighting modules for various editors. I am pretty sure someone will write a module to enable step-by-step debugging of Groovy scripts in your favourite IDE (maybe it's already there). Then you'll have step-by-step sitemap debugging FOR FREE in your IDE!
The point is not what we'll be able to do with such an arrangement. I'm pretty sure will be able to do more than what we do today and have others provide the necessary tools (remember I'm lazy). The point is whether using a full-fledged scripting language will give users far too many options and rope to hang themselves with, and how to avoid it.
Ugo
-- Ugo Cei - http://beblogging.com/
smime.p7s
Description: S/MIME cryptographic signature
