[Jelly] Executable XML vs. Rich Configuration

[Dan Madoni <Da...@ditech.com>]

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
documentation.

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.

Re: [Jelly] Executable XML vs. Rich Configuration

[Emmanouil Batsis <Em...@eurodyn.com>]

Paul Libbrecht wrote:

> I agree "executable XML" may suck


With an emphasis on "may" ;-)

This seems to be a common feeling. I never understood how most people 
dismiss so easily the fact that processing semantics written in XML are 
far more accessible (for humans and programs alike) than their non-XML 
counterparts.

Manos

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org

Re: [Jelly] Executable XML vs. Rich Configuration

[Paul Libbrecht <pa...@activemath.org>]

Le 11 mai 05, à 11:29, Paul Libbrecht a écrit :
> The best sub-title I found thus far was "mix-and-match" that's posted 
> in one of the documentation pages.

How about the following ?

    Apache Commons Jelly
    glue along XML pipelines
   (with side-effect!)

paul

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org

Re: [Jelly] Executable XML vs. Rich Configuration

[Paul Libbrecht <pa...@activemath.org>]

Dan,

This comes up to the point to re-consider the marketing of Jelly as we 
all wish to cut a release 1.0 soon!
I agree "executable XML" may suck but I think "rich configuration" is 
also quite "old fashioned" and is not that appropriate since there 
still is a notion of execution (or processing or pipeline).

Can you be more precise with the rants you've found about jelly ? (e.g. 
we could make a page "jelly sucks" with blog-like references and 
self-defences...).

The best sub-title I found thus far was "mix-and-match" that's posted 
in one of the documentation pages.

We should brainstorm on this, I think.
Please bring more ideas about sub-titles or qualifiers for Jelly !

paul



Le 11 mai 05, à 00:02, Dan Madoni a écrit :

> 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
> documentation.
>
> 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.
>


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org