[Jelly] Executable XML vs. Rich Configuration

classic Classic list List threaded Threaded
31 messages Options
12
Reply | Threaded
Open this post in threaded view
|

[Jelly] Executable XML vs. Rich Configuration

Dan Madoni
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.

Reply | Threaded
Open this post in threaded view
|

Re: [Jelly] Executable XML vs. Rich Configuration

Paul Libbrecht
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

RE: [Jelly] Executable XML vs. Rich Configuration

Dan Madoni
In reply to this post by Dan Madoni
Thanks for your reply, Paul. While I have several criticisms, my remarks
need to be received in the context of my appreciation for Jelly. I have far
more good than bad to say about it; but like most people, it's a lot easier
for me to talk about the bad. :)

I agree that "rich configuration" sells Jelly short ("intelligent
configuration" or "active configuration" might come a little closer, but
still wouldn't do it complete justice); but when it comes to positioning, I
would argue that the issue isn't whether you sell something short as much as
it is clearly demonstrating its usefulness.

Because of its XML nature, the solved problem that immediately connects with
Jelly would relate to configuration, storage, or perhaps page mark-up
processing (a la Cocoon)--you know: XML-ly things.

Perhaps a better term that isn't as restrictive as "Rich Configuration" or
as strange as "Executable XML" might be "Active XML Processing", or
something like that. Such a term doesn't imply that you'll use it for
programming, and instead suggests that it's useful for what you already use
XML for, with Jelly adding a valuable "active" dimension to XML rather than
just thinking of an XML document as a data container or template.

I should also mention that the name Jelly may also be a liability. I know
we're all geeks and we name things after pets or food or whatever makes for
great lore; but for Jelly to grow up and be noticed, it needs a more
meaningful name.

I'd actually maybe like to help with the two big weaknesses I found in
Jelly: sparse documentation and script error handling. I can't do that on my
client's time, but feel free to e-mail me at [hidden email] to discuss
it on my own time.



-----Original Message-----
From: Paul Libbrecht [mailto:[hidden email]]
Sent: Wednesday, May 11, 2005 2:30 AM
To: Jakarta Commons Users List
Subject: Re: [Jelly] Executable XML vs. Rich Configuration

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: [hidden email]
For additional commands, e-mail: [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: [Jelly] Executable XML vs. Rich Configuration

Emmanouil Batsis
In reply to this post by Paul Libbrecht
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

RE: [Jelly] Executable XML vs. Rich Configuration

Dan Madoni
In reply to this post by Dan Madoni
I'm not sure how the argument can be made that processing semantics written
in XML are more accessible than any well-designed language. If you were to
write an XML parser from scratch to handle Jelly scripts for instance (and
don't forget to include parsing requirements for JEXL and other Jelly
dependencies), it's likely you would require as much or more time developing
code that can discern XML Jelly script semantics than if you went through
the same exercise in writing, say, a C parser.

Existing XML parsers typically provide API's that transform XML semantically
from a mark-up language to a DOM representation. In this sense, XML
semantics are easily accessible, but no less easily than any parser which
transformed any structured language into a DOM representation.

Then again, it may be apples and oranges to make this sort of comparison,
but your assertion implies that such a comparison exists to begin with.

In terms of human accessibility, I'd heartily disagree, acknowledging that
the predication is a subjective one in any case. It certainly isn't true in
my case: my experience with using XML as a programming language is that it
is much more cumbersome to express or discern something meaningful relative
to programming languages that were designed from the outset to be
programming languages.

Perhaps the most powerful argument against both of those assertions is your
own observation that "most people" have the same visceral reaction. The
instinctive repulsion to the idea of "executable XML" is not unlike the
reaction one might have to the idea of using a screw driver to pound a nail.


Jelly is fabulous and certainly has its place; but as long as it is
positioned as "executable XML", which sounds about as relevant as
"Spreadsheet: The Video Game", few will understand or bother to investigate
its usefulness.


-----Original Message-----
From: Emmanouil Batsis [mailto:[hidden email]]
Sent: Thursday, May 12, 2005 12:25 AM
To: Jakarta Commons Users List
Subject: Re: [Jelly] Executable XML vs. Rich Configuration

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: [hidden email]
For additional commands, e-mail: [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: [Jelly] Executable XML vs. Rich Configuration

Paul Libbrecht
In reply to this post by Dan Madoni

Le 11 mai 05, à 19:42, Dan Madoni a écrit :
> Perhaps a better term that isn't as restrictive as "Rich
> Configuration" or
> as strange as "Executable XML" might be "Active XML Processing", or
> something like that. Such a term doesn't imply that you'll use it for
> programming, and instead suggests that it's useful for what you
> already use XML for, with Jelly adding a valuable "active" dimension
> to XML rather than just thinking of an XML document as a data
> container or template.

Active XML processing tastes good although it might have a taste to be
close to ASP which I really do not wish (that's kind of personal).

How about the sub-title: "XML processing with side-effects." (as
opposed to XSLT processing) ? Or "XML pipeline with effects".

About the liability, I am not sure to understand you: I think the name
"Jakarta Commons Jelly" is quite a good "brand-name"...

> I'd actually maybe like to help with the two big weaknesses I found in
> Jelly: sparse documentation and script error handling. I can't do that
> on my
> client's time, but feel free to e-mail me at [hidden email] to
> discuss it on my own time.

All this happens on commons-dev mailing list where you are happily
invited!
The documentation problem can become too big and I'd rather say we
should just polish a bit only the little set before the release.
The exception-in-the-face problem is a problem, for sure, see jira for
this... I think that just, by default, displaying the line number would
be better.

paul

PS: don't excuse yourself for such complaints, I've definitely
understood your appreciation of Jelly.

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [Jelly] Executable XML vs. Rich Configuration

Emmanouil Batsis
In reply to this post by Dan Madoni
Dan Madoni wrote:

>I'm not sure how the argument can be made that processing semantics written
>in XML are more accessible than any well-designed language.
>  
>
<snip/>

>In terms of human accessibility, I'd heartily disagree, acknowledging that
>the predication is a subjective one in any case.
>

I have to admit my perspective is a bit subjective; i started my IT
career as an HTML author and still carry the wrong assumption that
markup is familiar even to non-programmers.

In general though i think that XML does lower the bar for many different
kinds of people, whether they are desingers with some markup experience
or programmers that can choose from a variety of APIs and tools. A fine
example of "executable XML" that shares some properties with Jelly is
XSLT and few comment on it in the same manner they do for Ant build
files (which, i believe, is where all this "XML scripting is bad" mostly
comes from for some reason).

> It certainly isn't true in
>my case: my experience with using XML as a programming language is that it
>is much more cumbersome to express or discern something meaningful relative
>to programming languages that were designed from the outset to be
>programming languages.
>

I can see your point, all i can say is that i dont think we dissagree.
Most choices have their own pros and cons.

>Jelly is fabulous and certainly has its place; but as long as it is
>positioned as "executable XML", which sounds about as relevant as
>"Spreadsheet: The Video Game", few will understand or bother to investigate
>its usefulness.
>

True, i think the term is unfortunate. Anyway, i think i've been too
philosophical for this list already :-)

Manos

>
>
>-----Original Message-----
>From: Emmanouil Batsis [mailto:[hidden email]]
>Sent: Thursday, May 12, 2005 12:25 AM
>To: Jakarta Commons Users List
>Subject: Re: [Jelly] Executable XML vs. Rich Configuration
>
>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: [hidden email]
>For additional commands, e-mail: [hidden email]
>
>  
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [Jelly] Executable XML vs. Rich Configuration

Paul Libbrecht
In reply to this post by Paul Libbrecht

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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [Jelly] Executable XML vs. Rich Configuration

Hale India
In reply to this post by Dan Madoni
Hi

Just my one cent

I was just looking for "Rich Configuration" when I
have choosen to use Jelly for our project.

And I got what I was looking for.

Executable XML does not correspond to what it is and
plus it seems to me that it not what people are
looking for.

I think that in maven, for example, jelly use is also
for "Rich Configuration".

In any case I would like to avoid "exotic name" which
could give a bad image....

Best regards

Andre Legendre
--- Paul Libbrecht <[hidden email]> wrote:

>
> 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:
> [hidden email]
> For additional commands, e-mail:
> [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [Jelly] Executable XML vs. Rich Configuration

Paul Libbrecht
This seems to be another voice in favour of even changing Jakarta
Commons Jelly... I am really surprised and would make sure I understand
it correctly.

Changing "Executable XML" into "Rich Configuration" or "Running XML"  
is about changing a subtitle...

can I just request clarification ?

thanks

paul


Le 13 mai 05, à 18:44, Hale India a écrit :

> In any case I would like to avoid "exotic name" which
> could give a bad image....


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

RE: [Jelly] Executable XML vs. Rich Configuration

Dan Madoni
In reply to this post by Dan Madoni
Hello Paul.

I can't speak for Hale, but I would like to respond to your comments since
these are important issues to me.

Regarding your comment on the idea that a change to "Executable XML" amounts
to a subtitle change, I would argue that it isn't merely about a subtitle,
but about positioning. This, of course, is a critical difference. Even
though Jelly is OSS and all that, there is still a job of selling to do,
both in order for Jelly to reach its potential, and so that the most
developers possible can benefit from it, and perhaps contribute to its
continued improvement.

I know I've already said my piece about the name "Jelly", but if you'll
indulge me again: the name is meaningless, even more so than most Apache
project names, (and that's saying something). At least "Tomcat" might
conjure images of something agile and street-savvy; "Betwixt" implies
something that sits between something else (which hints at what it is); of
course, names like "FileUpload" and "Logging" are precise and immediately
communicate the purpose of the project...

...but "Jelly"? It might as well be called "Blah" or "Hmmm", (don't get any
ideas). :)


-----Original Message-----
From: Paul Libbrecht [mailto:[hidden email]]
Sent: Saturday, May 14, 2005 12:34 PM
To: Jakarta Commons Users List
Subject: Re: [Jelly] Executable XML vs. Rich Configuration

This seems to be another voice in favour of even changing Jakarta
Commons Jelly... I am really surprised and would make sure I understand
it correctly.

Changing "Executable XML" into "Rich Configuration" or "Running XML"  
is about changing a subtitle...

can I just request clarification ?

thanks

paul


Le 13 mai 05, à 18:44, Hale India a écrit :

> In any case I would like to avoid "exotic name" which
> could give a bad image....


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: [Jelly] Executable XML vs. Rich Configuration

Frank W. Zammetti
I've always liked the name Jelly... it makes me think of something very
flexible and very much not rigid, which is very much the goal of XML in
general and also of scripting tools.

Then again, I start Homer-drooling every time I think about it, so
that's a mark against it :)

--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com


Dan Madoni wrote:

> Hello Paul.
>
> I can't speak for Hale, but I would like to respond to your comments since
> these are important issues to me.
>
> Regarding your comment on the idea that a change to "Executable XML" amounts
> to a subtitle change, I would argue that it isn't merely about a subtitle,
> but about positioning. This, of course, is a critical difference. Even
> though Jelly is OSS and all that, there is still a job of selling to do,
> both in order for Jelly to reach its potential, and so that the most
> developers possible can benefit from it, and perhaps contribute to its
> continued improvement.
>
> I know I've already said my piece about the name "Jelly", but if you'll
> indulge me again: the name is meaningless, even more so than most Apache
> project names, (and that's saying something). At least "Tomcat" might
> conjure images of something agile and street-savvy; "Betwixt" implies
> something that sits between something else (which hints at what it is); of
> course, names like "FileUpload" and "Logging" are precise and immediately
> communicate the purpose of the project...
>
> ...but "Jelly"? It might as well be called "Blah" or "Hmmm", (don't get any
> ideas). :)
>
>
> -----Original Message-----
> From: Paul Libbrecht [mailto:[hidden email]]
> Sent: Saturday, May 14, 2005 12:34 PM
> To: Jakarta Commons Users List
> Subject: Re: [Jelly] Executable XML vs. Rich Configuration
>
> This seems to be another voice in favour of even changing Jakarta
> Commons Jelly... I am really surprised and would make sure I understand
> it correctly.
>
> Changing "Executable XML" into "Rich Configuration" or "Running XML"  
> is about changing a subtitle...
>
> can I just request clarification ?
>
> thanks
>
> paul
>
>
> Le 13 mai 05, ? 18:44, Hale India a ?crit :
>
>
>>In any case I would like to avoid "exotic name" which
>>could give a bad image....
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [Jelly] Executable XML vs. Rich Configuration

Lauren Bish
In reply to this post by Dan Madoni
My first thought was a book I read in college about requirements called
"Nailing jelly to a tree" - but personally I find it easier to remember
and associate with a product, once I know what it is, than many other
more descriptive names, especially the litany of products based on acronyms.

Dan Madoni wrote:

>
> I know I've already said my piece about the name "Jelly", but if you'll
> indulge me again: the name is meaningless, even more so than most Apache
> project names, (and that's saying something). At least "Tomcat" might
> conjure images of something agile and street-savvy; "Betwixt" implies
> something that sits between something else (which hints at what it is); of
> course, names like "FileUpload" and "Logging" are precise and immediately
> communicate the purpose of the project...
>
> ...but "Jelly"? It might as well be called "Blah" or "Hmmm", (don't get any
> ideas). :)
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

HttpClient and best way to parse an Html file

Rajat Sharma
In reply to this post by Dan Madoni
Hi Folks,

I am implementing a http client using httpclient package. I need to parse the html file to get the valid "name" fields, so I could fill them up with some "values" on the client side and then post the form.

What is the best way to parse the html file or the only way is to have my own raw parser.

Any suggestions how I can go about it.

Thanks

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [Jelly] Executable XML vs. Rich Configuration

Paul Libbrecht
In reply to this post by Dan Madoni
Le 16 mai 05, à 19:11, Dan Madoni a écrit :
> ...but "Jelly"? It might as well be called "Blah" or "Hmmm", (don't
> get any
> ideas). :)

re-interpreting differently... (really playing!):

     jelly
glue along  XML pipelines


would be much understandable, or ?
Doesn't jelly make you think, at least, to Jell-O or some jam a dirty
kid would put on pens it borrows ?
We probably need more explicit images for you!

More or less kidding... but marketing brainstorming needs this, or ?

paul

PS: would honey or maple-syrup be more sticky ?
PPS: I agree that the jelly-fish-like logo could be more explicit

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

RE: [Jelly] Executable XML vs. Rich Configuration

Dan Madoni
In reply to this post by Dan Madoni
Perhaps "Jelly" itself should be made into an acronym, which would make it
both meaningful *and* memorable. :)

Some suggestions for J.E.L.L.Y.:

Jammin'
Engine for XML
Language and
Lots more for
You

Join the
Elites who
Love to
Lay out "executable XML",
Y Not?

Jail
Everyone who
Loathes or
Laughs at
Your XML "program"

Just
Eat the
Leftover
Lasagna,
Yvonne

Jeeps,
Escalades,
Land Rovers, and
Lincoln Navigators are popular SUV's. Oh, I forgot
Yukons.

Jerry
Entertained
Laura with his
Lovely rendition of the 1950's hit
Yakity Yak

...okay, I'll stop. :)



-----Original Message-----
From: Lauren Bish [mailto:[hidden email]]
Sent: Monday, May 16, 2005 5:44 PM
To: Jakarta Commons Users List
Subject: Re: [Jelly] Executable XML vs. Rich Configuration

My first thought was a book I read in college about requirements called
"Nailing jelly to a tree" - but personally I find it easier to remember
and associate with a product, once I know what it is, than many other
more descriptive names, especially the litany of products based on acronyms.

Dan Madoni wrote:

>
> I know I've already said my piece about the name "Jelly", but if you'll
> indulge me again: the name is meaningless, even more so than most Apache
> project names, (and that's saying something). At least "Tomcat" might
> conjure images of something agile and street-savvy; "Betwixt" implies
> something that sits between something else (which hints at what it is); of
> course, names like "FileUpload" and "Logging" are precise and immediately
> communicate the purpose of the project...
>
> ...but "Jelly"? It might as well be called "Blah" or "Hmmm", (don't get
any
> ideas). :)
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: [Jelly] Executable XML vs. Rich Configuration

Dan Madoni
In reply to this post by Dan Madoni
I just read through the FAQ's and found that "Jelly" does indeed have an
intended meaning. From
http://jakarta.apache.org/commons/jelly/faq.html#why-called-jelly:

<quote>
The name started out as 'Jele' as in Java ELEments but then I thought Jelly
was a nicer spelling :-). The basic idea behind Jelly that Java code is
bound on to XML elements.

Also Jelly (in British or Jello in American) can be molded to fit any shape
required which kinda fits with Jelly's main aim to be a flexible Java and
XML based scripting engine that can do anything.

There are many different specific frameworks that take an XML document, bind
it to some kind of bean or object and then evaluate it in some kind of
script or process, so Jelly was an attempt at a generic engine using ideas
from JSP, JSTL, Velocity, Cocoon and Ant."
</quote>

I can actually go along with the explanation of Jelly being molded into any
shape, although that's a bit of a stretch of the word "Jelly", as people
don't really think of jelly as something you mold around something else.
That is, I'll put jelly on my toast, but it's not the first thing I think of
when I need something flexible and moldable like clay or Silly Putty.

I should note at this point that I'm American, and the suggestion that
British "Jelly"--our "Jello"--being moldable makes much more sense, as it is
very common to mold Jello; but "jelly" and "Jello" have no implied
connection here.

If the original acronym (JELE) would have stuck, then the connection between
"jelly" (by American definition) and "something moldable" would have made
more sense, i.e. because you're not grasping at straws to use the word
"jelly" to make the comparison since the name JELE is pronounced like the
word "jelly".

Of course, the acronym would be problematic anyway since "Java Elements"
isn't really meaningful either.

Anyway, I'm the proverbial complainer with few good ideas to suggest as
alternatives. :)  I suppose if it were my invention, I would have named it
something like "Active XML", which conveys some meaning as to what it is and
preemptively wards off some of the naysayers, (i.e. it stops short of the
off-the-wall concept of "executable XML" and instead suggests that XML
documents can be interactive, which is an important distinction).

I'm aware of the fact that I'm beating this dead horse beyond recognition,
but I'm enjoying this conversation. :)


-----Original Message-----
From: Paul Libbrecht [mailto:[hidden email]]
Sent: Tuesday, May 17, 2005 8:52 AM
To: Jakarta Commons Users List
Subject: Re: [Jelly] Executable XML vs. Rich Configuration

Le 16 mai 05, à 19:11, Dan Madoni a écrit :
> ...but "Jelly"? It might as well be called "Blah" or "Hmmm", (don't
> get any
> ideas). :)

re-interpreting differently... (really playing!):

     jelly
glue along  XML pipelines


would be much understandable, or ?
Doesn't jelly make you think, at least, to Jell-O or some jam a dirty
kid would put on pens it borrows ?
We probably need more explicit images for you!

More or less kidding... but marketing brainstorming needs this, or ?

paul

PS: would honey or maple-syrup be more sticky ?
PPS: I agree that the jelly-fish-like logo could be more explicit

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: [Jelly] Executable XML vs. Rich Configuration

Dion Gillard-2
On 5/19/05, Dan Madoni <[hidden email]> wrote:
[snip]

> I can actually go along with the explanation of Jelly being molded into any
> shape, although that's a bit of a stretch of the word "Jelly", as people
> don't really think of jelly as something you mold around something else.
> That is, I'll put jelly on my toast, but it's not the first thing I think of
> when I need something flexible and moldable like clay or Silly Putty.
>
> I should note at this point that I'm American, and the suggestion that
> British "Jelly"--our "Jello"--being moldable makes much more sense, as it is
> very common to mold Jello; but "jelly" and "Jello" have no implied
> connection here.

Come on, you're only American, if that's causing a problem for you,
what about the rest of the world that doesn't even speak English!

--
http://www.multitask.com.au/people/dion/

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [Jelly] Executable XML vs. Rich Configuration

Catalin Grigoroscuta
In reply to this post by Dan Madoni
Also, should keep in mind that if you use too much Jelly (or Jello, as
other may preffer), it can get quite messy ;)
And, although it's very flexible and appealing, only kids like to play
with it.

Dan Madoni wrote:

>Also Jelly (in British or Jello in American) can be molded to fit any shape
>required which kinda fits with Jelly's main aim to be a flexible Java and
>XML based scripting engine that can do anything.
>  
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: HttpClient and best way to parse an Html file

Lee Francis Wilhelmsen
In reply to this post by Rajat Sharma
Hi

You might want to check out http://htmlparser.sourceforge.net/

It's pretty good, but documentation is lacking. However, there are some
examples to get you started.

Regards
Lee Francis Wilhelmsen

> Subject: HttpClient and best way to parse an Html file
> From: "Rajat Sharma" <[hidden email]>
> Date: Tue, 17 May 2005 09:51:51 -0400
 >
> Hi Folks,
>
> I am implementing a http client using httpclient package. I need to parse the html file to get the valid "name" fields, so I could fill them up with some "values" on the client side and then post the form.
>
> What is the best way to parse the html file or the only way is to have my own raw parser.
>
> Any suggestions how I can go about it.

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

12