commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dan Madoni <>
Subject [Jelly] Executable XML vs. Rich Configuration
Date Tue, 10 May 2005 22:02:09 GMT
Having just completed a project using Jelly as a script execution engine, it
occurred to me that the perplexity I was initially met with regarding Jelly
("executable XML? huh?") was displaced by appreciation for how valuable it
can be.

As I began working on the project, I had a home-grown solution in mind for
the component that Jelly is now used in place of. The home-grown component
wasn't "executable XML", but it was very complex XML-based configuration,
and a cohort suggested that I look at Jelly after having perused my design

At first, I didn't exactly get it--why would I want to "execute" XML? After
thinking about it in the context of the project, it began to make a great
deal of sense for the specific purpose I had in mind: Jelly is ideal for
"rich configuration", where configuration data alone may be insufficient or
too cumbersome, and some sort of "intelligent" configuration is needed, even
to the point where the configuration data actually interacts manipulatively
with the application.

I don't know if this is what Jelly's creator(s) had in mind upon embarking
on the project. Actually, I get the impression someone was caught up in the
same frenzy that compels people to try to solve every freaking problem with
XML, and just thought "It would be cool to program with XML. Yeah, that's
cool." In any case, I think I'm the rule and not the exception when I say
that the idea of "executable XML" sounds like a solution in search of a
problem. If my fellow developer hadn't already been familiar with Jelly and
put two and two together to suggest it as something I could use, I may well
have come across the Jelly home page some other way and assumed a Squidward
attitude ("oh puh-leeze").

Other than what I believe to be a misplaced identity, the only other nits I
have are that the documentation leaves much to be desired and debugging
Jelly scripts is awfully cumbersome when the script error raises a Java
exception (perhaps script execution exception handling could have been a bit
better thought out).

But I can't really complain. Jelly is fabulous, and was absolutely key in
making this application work as well as it does. It would probably find more
users and less scorn (I read some really harsh stuff while researching it)
if it were simply repositioned a bit. The whole "executable XML" theme is
cute and might make an interesting discussion at a nerd convention, but I
would guess that there are far more developers who need to tackle complex
configuration problems and who will readily understand the meaning of "rich
configuration" or "intelligent configuration" than there are developers who
regard Utopia as being able to code in XML.

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message