You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cocoon.apache.org by Hervé Guidetti <he...@idbsoft.ch> on 2000/04/07 11:35:31 UTC
Enhydra vs Cocoon
Hello,
I surfed the web. I saw Enhydra (http://www.enhydra.org).
What do you think about it ? What is the difference beteen Enhydra and
Coccon ?
I have to choose, what do you advise me ?
Thanks from a beginner.
Hervé
RE: xml -> form -> xml form to xml code
Posted by Donald Ball <ba...@webslingerZ.com>.
On Sun, 9 Apr 2000, David Duddleston wrote:
>
> What you have sounds cool, but is not exactly what I'm looking for. Here a
> simple example.
>
> You have some xml data
>
> <person id="1">
> <name>david</name>
> <email>david@i2a.com</email>
> </person>
>
> some code would convert this to an html form... could be java code, XSL or
> both.
>
> <html>
> <body>
> <form action="fromToXMLServlet" metho="post">
> <input type="text" name="/person/@id" value="1">
> <input type="text" name="/person/name" value="david">
> <input type="text" name="/person/email" value="david@i2a.com">
> </form>
That's the innovation that Jeremy was hip on. You'd have to markup your
original XML in some fashion:
<person id="xmlform:variable" xmlform:datatype="integer">
<name><xmlform:variable datatype="string"/></name>
<email>xmlform:variable datatype="email"/></email>
</person>
So that the form generator program would have _something_ to work with. I
think that's probably a really nifty approach, but I don't have the time
to write it. Everything else you want, I think XMLForm could do.
> It would post to a Servlet or something that could parse the form data and
> create a new XML doc or update an existing one... probably against a Schema
> or DTD. The form elements would have to contain a formated name so that the
> form parser could match up the parameters values and place it in the right
> XML elements/attributes. Somthing like a path might work <input type="text"
> name="person/name" value="david">
>
> OK, this is a simple explanation, but you get the idea?
Sure. XMLForm lets you specfiy an XPath expression that points to the
location in the existing XML file that the new fragment should be put. It
can either append the new node after the specified node or replace it (and
maybe some other ops as well, I can't remember).
- donald
RE: xml -> form -> xml form to xml code
Posted by Donald Ball <ba...@webslingerZ.com>.
Oh, whoops, responded to a response that wasn't in response to me. I'll be
going to bed here in a few. :) Hopefully my additional comments were
helpful anyway.
- donald
On Sun, 9 Apr 2000, David Duddleston wrote:
>
> What you have sounds cool, but is not exactly what I'm looking for. Here a
> simple example.
>
> You have some xml data
>
> <person id="1">
> <name>david</name>
> <email>david@i2a.com</email>
> </person>
>
> some code would convert this to an html form... could be java code, XSL or
> both.
>
> <html>
> <body>
> <form action="fromToXMLServlet" metho="post">
> <input type="text" name="/person/@id" value="1">
> <input type="text" name="/person/name" value="david">
> <input type="text" name="/person/email" value="david@i2a.com">
> </form>
>
>
> It would post to a Servlet or something that could parse the form data and
> create a new XML doc or update an existing one... probably against a Schema
> or DTD. The form elements would have to contain a formated name so that the
> form parser could match up the parameters values and place it in the right
> XML elements/attributes. Somthing like a path might work <input type="text"
> name="person/name" value="david">
>
> OK, this is a simple explanation, but you get the idea?
>
> -david
>
>
>
> > -----Original Message-----
> > From: blur@localhost.localdomain [mailto:blur@localhost.localdomain]On
> > Behalf Of Laura Kruse
> > Sent: Sunday, April 09, 2000 7:51 PM
> > To: cocoon-users@xml.apache.org
> > Subject: Re: xml -> form -> xml form to xml code
> >
> >
> > David Duddleston wrote:
> > >
> > > I'm wondering if anyone has code that can take an XML doc with
> > or without a
> > > Schema and generate an HTML form. Then have code that will
> > handle the post
> > > and either create a new XML doc or update an existing one.
> > >
> > > If nothing exists already, would anyone be interested if I made
> > something
> > > like this?
> > >
> > > -david
> >
> > I don't know if this is what you meant exactly, but I have a xml
> > document that queries a database, makes a form to search the database
> > based on what's in the database. Allows the user to select what the
> > want. Send the selecting to a servlet that retuns xml to be parsed back
> > into html.
> >
> > Cheers,
> > Laura
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: cocoon-users-unsubscribe@xml.apache.org
> > For additional commands, e-mail: cocoon-users-help@xml.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-users-unsubscribe@xml.apache.org
> For additional commands, e-mail: cocoon-users-help@xml.apache.org
>
RE: xml -> form -> xml form to xml code
Posted by David Duddleston <da...@i2a.com>.
What you have sounds cool, but is not exactly what I'm looking for. Here a
simple example.
You have some xml data
<person id="1">
<name>david</name>
<email>david@i2a.com</email>
</person>
some code would convert this to an html form... could be java code, XSL or
both.
<html>
<body>
<form action="fromToXMLServlet" metho="post">
<input type="text" name="/person/@id" value="1">
<input type="text" name="/person/name" value="david">
<input type="text" name="/person/email" value="david@i2a.com">
</form>
It would post to a Servlet or something that could parse the form data and
create a new XML doc or update an existing one... probably against a Schema
or DTD. The form elements would have to contain a formated name so that the
form parser could match up the parameters values and place it in the right
XML elements/attributes. Somthing like a path might work <input type="text"
name="person/name" value="david">
OK, this is a simple explanation, but you get the idea?
-david
> -----Original Message-----
> From: blur@localhost.localdomain [mailto:blur@localhost.localdomain]On
> Behalf Of Laura Kruse
> Sent: Sunday, April 09, 2000 7:51 PM
> To: cocoon-users@xml.apache.org
> Subject: Re: xml -> form -> xml form to xml code
>
>
> David Duddleston wrote:
> >
> > I'm wondering if anyone has code that can take an XML doc with
> or without a
> > Schema and generate an HTML form. Then have code that will
> handle the post
> > and either create a new XML doc or update an existing one.
> >
> > If nothing exists already, would anyone be interested if I made
> something
> > like this?
> >
> > -david
>
> I don't know if this is what you meant exactly, but I have a xml
> document that queries a database, makes a form to search the database
> based on what's in the database. Allows the user to select what the
> want. Send the selecting to a servlet that retuns xml to be parsed back
> into html.
>
> Cheers,
> Laura
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-users-unsubscribe@xml.apache.org
> For additional commands, e-mail: cocoon-users-help@xml.apache.org
>
Re: xml -> form -> xml form to xml code
Posted by Laura Kruse <lm...@cis.ksu.edu>.
David Duddleston wrote:
>
> I'm wondering if anyone has code that can take an XML doc with or without a
> Schema and generate an HTML form. Then have code that will handle the post
> and either create a new XML doc or update an existing one.
>
> If nothing exists already, would anyone be interested if I made something
> like this?
>
> -david
I don't know if this is what you meant exactly, but I have a xml
document that queries a database, makes a form to search the database
based on what's in the database. Allows the user to select what the
want. Send the selecting to a servlet that retuns xml to be parsed back
into html.
Cheers,
Laura
RE: xml -> form -> xml form to xml code
Posted by David Duddleston <da...@i2a.com>.
Donald, you have been a big help. We were probably writing emails at the
same time? I'm glad you relized that I was not responding to you, since what
you have is alot like what I just described ;-) Regardless, the extra info
should be helpful. I'll take a look at what you did.
Thanks again.
-david
> -----Original Message-----
> From: Donald Ball [mailto:balld@webslingerZ.com]
> Sent: Sunday, April 09, 2000 9:17 PM
> To: cocoon-users@xml.apache.org
> Subject: RE: xml -> form -> xml form to xml code
>
>
> On Sun, 9 Apr 2000, David Duddleston wrote:
>
> > Sounds like this could be what I'm looking for. I don't need
> anything real
> > fancy right now. Just something that will allow editing of basic XML
> > files... stuff that is not worth creating custom code for if
> you know what I
> > mean. I'll check it out.
> >
> > Thanks Donald.
>
> And just so you know - IBM, at least, had some "editor generator" java
> program on alphaworks a little while back that could take in a DTD or
> schema and produce a java program that would allow you to edit a document
> based on that schema. I could never make it work right, but it sounded
> interesting. My basic criticism of most XML editor and editor generators
> is that their UI is more akin to a file browser than a word processor or
> an HTML form. I like the HTML form approach because it's ubiquitous and it
> lets you offer a highly constrained editing experience.
>
> - donald
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-users-unsubscribe@xml.apache.org
> For additional commands, e-mail: cocoon-users-help@xml.apache.org
>
RE: xml -> form -> xml form to xml code
Posted by Donald Ball <ba...@webslingerZ.com>.
On Sun, 9 Apr 2000, David Duddleston wrote:
> Sounds like this could be what I'm looking for. I don't need anything real
> fancy right now. Just something that will allow editing of basic XML
> files... stuff that is not worth creating custom code for if you know what I
> mean. I'll check it out.
>
> Thanks Donald.
And just so you know - IBM, at least, had some "editor generator" java
program on alphaworks a little while back that could take in a DTD or
schema and produce a java program that would allow you to edit a document
based on that schema. I could never make it work right, but it sounded
interesting. My basic criticism of most XML editor and editor generators
is that their UI is more akin to a file browser than a word processor or
an HTML form. I like the HTML form approach because it's ubiquitous and it
lets you offer a highly constrained editing experience.
- donald
RE: xml -> form -> xml form to xml code
Posted by David Duddleston <da...@i2a.com>.
Sounds like this could be what I'm looking for. I don't need anything real
fancy right now. Just something that will allow editing of basic XML
files... stuff that is not worth creating custom code for if you know what I
mean. I'll check it out.
Thanks Donald.
-david
> -----Original Message-----
> From: Donald Ball [mailto:balld@webslingerZ.com]
> Sent: Sunday, April 09, 2000 8:44 PM
> To: cocoon-users@xml.apache.org
> Subject: Re: xml -> form -> xml form to xml code
>
>
> On Sun, 9 Apr 2000, David Duddleston wrote:
>
> > I'm wondering if anyone has code that can take an XML doc with
> or without a
> > Schema and generate an HTML form. Then have code that will
> handle the post
> > and either create a new XML doc or update an existing one.
> >
> > If nothing exists already, would anyone be interested if I made
> something
> > like this?
>
> Yes, I have written something along these lines called XMLForm:
>
> http://www.webslingerZ.com/balld/xmlform/
>
> I haven't played with it in a while; Jeremy Quinn and I had been
> discussing ways to extend this more generically but I'm afraid I got tied
> up in actual billable work and haven't had a chance to revisit it in a
> while. The code's pretty solid. Some people feel there are security
> concerns with the approach, but my feeling is that it's no more dangerous,
> and likely less so, than letting people edit your XML content files by
> hand. Just don't open it up for the world to play with.
>
> I'm not likely to have the chance to do much else to this code for a
> while, so Jeremy, David, anyone - if you're interested in doing any
> development on or with the code, I'll be happy to check it into
> sourceforge or wherever. Jeremy had a nice thought about reworking the
> configuration - instead of forcing the author to write a form with
> specially named variables describing an XML structure, he was thinking
> that you reverse that, you could mark up a skeletal version of your XML
> with special tags that indicated how to generate a form to edit it. Matt
> Seargeant (the perl XML::Form author who inspired this work) also had some
> ideas about how he would like to revamp his perl module if you want to
> talk to him.
>
> - donald
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-users-unsubscribe@xml.apache.org
> For additional commands, e-mail: cocoon-users-help@xml.apache.org
>
Re: xml -> form -> xml form to xml code
Posted by Donald Ball <ba...@webslingerZ.com>.
On Sun, 9 Apr 2000, David Duddleston wrote:
> I'm wondering if anyone has code that can take an XML doc with or without a
> Schema and generate an HTML form. Then have code that will handle the post
> and either create a new XML doc or update an existing one.
>
> If nothing exists already, would anyone be interested if I made something
> like this?
Yes, I have written something along these lines called XMLForm:
http://www.webslingerZ.com/balld/xmlform/
I haven't played with it in a while; Jeremy Quinn and I had been
discussing ways to extend this more generically but I'm afraid I got tied
up in actual billable work and haven't had a chance to revisit it in a
while. The code's pretty solid. Some people feel there are security
concerns with the approach, but my feeling is that it's no more dangerous,
and likely less so, than letting people edit your XML content files by
hand. Just don't open it up for the world to play with.
I'm not likely to have the chance to do much else to this code for a
while, so Jeremy, David, anyone - if you're interested in doing any
development on or with the code, I'll be happy to check it into
sourceforge or wherever. Jeremy had a nice thought about reworking the
configuration - instead of forcing the author to write a form with
specially named variables describing an XML structure, he was thinking
that you reverse that, you could mark up a skeletal version of your XML
with special tags that indicated how to generate a form to edit it. Matt
Seargeant (the perl XML::Form author who inspired this work) also had some
ideas about how he would like to revamp his perl module if you want to
talk to him.
- donald
xml -> form -> xml form to xml code
Posted by David Duddleston <da...@i2a.com>.
I'm wondering if anyone has code that can take an XML doc with or without a
Schema and generate an HTML form. Then have code that will handle the post
and either create a new XML doc or update an existing one.
If nothing exists already, would anyone be interested if I made something
like this?
-david
Re: Enhydra vs Cocoon
Posted by Stefano Mazzocchi <st...@apache.org>.
"David H. Young" wrote:
>
> Sorry you're offended... marketing and religion are fairly
> synonymous these days...
They might, but I try not to be religious... we are both biased toward
our projects and this makes perfect sense.
Anyway people pointed out that Apache uses this "leading web server"
marketing shit all over the place, and it's totally true so I'm going to
deprecate me being offended and turn it into a question: how do you know
you are the leading XML/Java application server? where do you base you
numbers?
Look, don't want to appear defensive: I'm just positively curious about
such XML surveys.
> Just an FYI... Enhydra has nothing to do with Jserv other
> than Enhydra Multiserver also serves up Tomcat based servlets.
> There is no Jserv code in Enhydra.
At ApacheCON 2000 I was given an Enhydra CD and after installing it, I
looked into the source code to find out if you guys were using any
apache stuff then found Apache JServ in the main jar packages.
It could be an old release. Anyway, like I said, i have no problems with
that at all!
> Feel free to review the
> source code. Tomcat and Xerces are incorporated into Enhydra.
> Shawn McMurdo from Lutris has been very active on the Tomcat
> mail list.
That's great.
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
Missed us in Orlando? Make it up with ApacheCON Europe in London!
------------------------- http://ApacheCon.Com ---------------------
Re: Enhydra vs Cocoon
Posted by "David H. Young" <da...@lutris.com>.
Sorry you're offended... marketing and religion are fairly
synonymous these days...
Just an FYI... Enhydra has nothing to do with Jserv other
than Enhydra Multiserver also serves up Tomcat based servlets.
There is no Jserv code in Enhydra. Feel free to review the
source code. Tomcat and Xerces are incorporated into Enhydra.
Shawn McMurdo from Lutris has been very active on the Tomcat
mail list.
David, Chief Evangelist, Enhydra
Stefano Mazzocchi wrote:
> "David H. Young" wrote:
>
> [...]
>
> > As always, it comes down to picking your poison. And figuring out the
> > nature of your project, the capabilities of your team and how you allocate
> > different groups to different parts of the project.
>
> Totally true.
>
> Anyway, to be extremely honest with you, I don't have _any_ problem to
> have open source projects that are based on the same technology (Enhydra
> is based on Apache JServ) and are competing in other grounds (XML).
>
> What I found _offensive_ and utterly provocative is that "leading"
> marketing shit in all your advertising. I also find "scary" the need for
> an open source project to be -advertised- on slashdot to gain momentum.
>
> I'll tell you a story: NewAtlanta people used to have a signature on
> their emails such as "the leading providers for servlet technology".
> When people started to laught at that, they removed it.
>
> Once the community is laughing at you, it's pretty hard to back it up,
> don't you think? ;-)
>
> --
> Stefano Mazzocchi One must still have chaos in oneself to be
> able to give birth to a dancing star.
> <st...@apache.org> Friedrich Nietzsche
> --------------------------------------------------------------------
> Missed us in Orlando? Make it up with ApacheCON Europe in London!
> ------------------------- http://ApacheCon.Com ---------------------
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-users-unsubscribe@xml.apache.org
> For additional commands, e-mail: cocoon-users-help@xml.apache.org
--
David H. Young
Chief Evangelist
Lutris Technologies, Inc.
1200 Pacific Avenue, Suite 200
Santa Cruz, CA 95060 USA
831.460.7310; 831.471.9754 (fax)
http://www.lutris.com
http://www.enhydra.org
Re: Enhydra vs Cocoon
Posted by Stefano Mazzocchi <st...@apache.org>.
"David H. Young" wrote:
[...]
> As always, it comes down to picking your poison. And figuring out the
> nature of your project, the capabilities of your team and how you allocate
> different groups to different parts of the project.
Totally true.
Anyway, to be extremely honest with you, I don't have _any_ problem to
have open source projects that are based on the same technology (Enhydra
is based on Apache JServ) and are competing in other grounds (XML).
What I found _offensive_ and utterly provocative is that "leading"
marketing shit in all your advertising. I also find "scary" the need for
an open source project to be -advertised- on slashdot to gain momentum.
I'll tell you a story: NewAtlanta people used to have a signature on
their emails such as "the leading providers for servlet technology".
When people started to laught at that, they removed it.
Once the community is laughing at you, it's pretty hard to back it up,
don't you think? ;-)
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
Missed us in Orlando? Make it up with ApacheCON Europe in London!
------------------------- http://ApacheCon.Com ---------------------
Re: Enhydra vs Cocoon
Posted by Ed Knutson <ed...@webcombo.net>.
On Sat, 08 Apr 2000, David H. Young wrote:
> First, the HTML code just became a resource of Java. It putJava in full
> control of the flow of the presentation, rather than HTML dictating flow with
> Java inserted where needed.
> <snip/>
> XMLC's design strategy means that the programmer can stick to Java for
> manipulating the DOM (except when inserting JavaScript, usually to
> perform client-side validation checks). There's little need for scripting,
> which is really another form of embedding a programming language.
> With enhydra xmlc you don't need XSL editors and because there are
> _no_ HTML tags introduced, it works with any HTML editor.
>
> As always, it comes down to picking your poison. And figuring out the
> nature of your project, the capabilities of your team and how you allocate
> different groups to different parts of the project.
We're basically saying the same thing. ;) Enhydra is geared towards
programming applications, where different documents are produced according to a
flow of objects. Cocoon 1 excels where you have more documents than logic or
need flexible presentation or the benefits of XSL.
If you have a database-driven application (DODS is definitely an Enhydra strong
point) that doesn't rely on an existing document base, you could probably
duplicate Enhydra with XSP taglibs but that would be reinventing Enhydra.
Personally, I had a bunch of HTML docs, most of which didn't have lots of logic
but needed to be able to adapt presentation to a broad range of client
software. I tried Enhydra before I had even heard of Cocoon, but I just didn't
need that much of a Java-focused environment. (Note subtle humor) XT alone
couldn't do what I needed, so....
It's all about the path of least resistance.
-ed
Re: Enhydra vs Cocoon
Posted by "David H. Young" <da...@lutris.com>.
I don't know if anybody from enhydra.org has spoke up before here,
so let me take a stab at explaining the design center behind Enhydra
XMLC, one of the many technologies included in the Open Source
Enhydra Java/XML application server...
The #1 goal was to address the product lifecycle problems created by
embedding Java or any other structured language inside a mark-up language:
difficult-to-maintain presentations that required technical expertise to
change. We (Lutris) as consultants wanted our HTML designers to
focus on HTML design and not Java development. So we came up
with a way to leverage HTML/XML attributes to isolate areas of HTML
created dynamically, such as a table of customers. XMLC fixed a bunch
of things. First, the HTML code just became a resource of Java. It put
Java in full control of the flow of the presentation, rather than HTML
dictating flow with Java inserted where needed. Second, it became
much easier to work with 3rd party HTML designers because the only
handshake required was to agree on the ID names, such as
"DustomerName", in the string <TD ID=CustomerName>John Doe</TD>.
Thirdly, one could leave mocked up data, such as a mocked up table,
to be removed automatically at compile time or during
runtime exection. That meant only one "truth" document was required.
rather than maintaining two parallel documents (one without embedded
Java code, the other with embedded Java code). So, the work flow goes
something like... the HTML or WML designer creates a template, using
mocked up data and all, inserting the agreed-upon ID attributes to identify
areas of dynamic content. The Java developer takes the document and
compiles it into a DOM with xmlc which creates the java class, with
accessor functions automatically created to access nodes based on the id
names, such as htmlDocument.setTextCustomerName( ). Enhydra will
perform automatic compilation if the html/wml/xml document has been
altered since a previous compilation.
XMLC's design strategy means that the programmer can stick to Java for
manipulating the DOM (except when inserting JavaScript, usually to
perform client-side validation checks). There's little need for scripting,
which is really another form of embedding a programming language.
With enhydra xmlc you don't need XSL editors and because there are
_no_ HTML tags introduced, it works with any HTML editor.
As always, it comes down to picking your poison. And figuring out the
nature of your project, the capabilities of your team and how you allocate
different groups to different parts of the project.
David
Ed Knutson wrote:
> On Fri, 07 Apr 2000, Roman Seidl wrote:
> > On Fri, 7 Apr 2000, Ed Knutson wrote:
> >
> > > So the question to ask is: am I trying to publish documents or build
> > > applications?
> > What if you build applications that publish documnets?
>
> In that case, go with Cocoon unless you know it doesn't support something you
> need. Most of the work is already done, even if you do have to "hack"
> it now and then. Use Enhydra to do things Cocoon can't do. Otherwise, why
> reinvent the wheel?
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-users-unsubscribe@xml.apache.org
> For additional commands, e-mail: cocoon-users-help@xml.apache.org
--
David H. Young
Chief Evangelist
Lutris Technologies, Inc.
1200 Pacific Avenue, Suite 200
Santa Cruz, CA 95060 USA
831.460.7310; 831.471.9754 (fax)
http://www.lutris.com
http://www.enhydra.org
Re: Enhydra vs Cocoon
Posted by Stefano Mazzocchi <st...@apache.org>.
Mauro Jaskelioff wrote:
>
> >
> > Honest question from the ignorant: what does Enhydra does that Cocoon
> > can't do?
> >
> > I'm asking because I could not find anything in which enhydra was
> > better... but of course I'm so biased that this is probably blinding me.
> >
> Well, Enhydra is MUCH better documented. That's the one thing I think that
> Cocoon should improve. But, yeah, I know, that's the boring part ;-)
Touché :)
Anyway, what stops you guys from helping? ;)
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
Missed us in Orlando? Make it up with ApacheCON Europe in London!
------------------------- http://ApacheCon.Com ---------------------
RE: Enhydra vs Cocoon
Posted by Mauro Jaskelioff <ma...@citynet.net.ar>.
>
> Honest question from the ignorant: what does Enhydra does that Cocoon
> can't do?
>
> I'm asking because I could not find anything in which enhydra was
> better... but of course I'm so biased that this is probably blinding me.
>
Well, Enhydra is MUCH better documented. That's the one thing I think that
Cocoon should improve. But, yeah, I know, that's the boring part ;-)
Re: Enhydra vs Cocoon
Posted by Mark Washeim <es...@canuck.com>.
Enhydra is an entire application server. It's 'multiserver' can play the function
of web server (a very fast one, at that), servlet runtime and it has per
application administrative interfaces, to boot.
What it does not perform is your separation of contexts. In fact, it imposes on
the programmer responsibilities for deploying 'content' which are onerous (namely,
you have to compile sources like xml and .gifs into your .jar file/applications)
Mark
Stefano Mazzocchi wrote:
> Ed Knutson wrote:
> >
> > On Fri, 07 Apr 2000, Roman Seidl wrote:
> > > On Fri, 7 Apr 2000, Ed Knutson wrote:
> > >
> > > > So the question to ask is: am I trying to publish documents or build
> > > > applications?
> > > What if you build applications that publish documnets?
> >
> > In that case, go with Cocoon unless you know it doesn't support something you
> > need. Most of the work is already done, even if you do have to "hack"
> > it now and then. Use Enhydra to do things Cocoon can't do. Otherwise, why
> > reinvent the wheel?
>
> Honest question from the ignorant: what does Enhydra does that Cocoon
> can't do?
>
> I'm asking because I could not find anything in which enhydra was
> better... but of course I'm so biased that this is probably blinding me.
>
> I would be happy if you guys could outline what you "don't like" about
> Cocoon so that we can make it better.
>
> I keep on hearing "cocoon is great", "thanks for doing this" and such...
> hey, this is awesome and I love it, ok? but I want this project to grow
> and growing means to polish the corners and smooth the angles.
>
> But we can't do this if we don't see those rough angles.
>
> Do I make sense?
>
> --
> Stefano Mazzocchi One must still have chaos in oneself to be
> able to give birth to a dancing star.
> <st...@apache.org> Friedrich Nietzsche
> --------------------------------------------------------------------
> Missed us in Orlando? Make it up with ApacheCON Europe in London!
> ------------------------- http://ApacheCon.Com ---------------------
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-users-unsubscribe@xml.apache.org
> For additional commands, e-mail: cocoon-users-help@xml.apache.org
Re: Enhydra vs Cocoon
Posted by Stefano Mazzocchi <st...@apache.org>.
Ed Knutson wrote:
>
> On Fri, 07 Apr 2000, Roman Seidl wrote:
> > On Fri, 7 Apr 2000, Ed Knutson wrote:
> >
> > > So the question to ask is: am I trying to publish documents or build
> > > applications?
> > What if you build applications that publish documnets?
>
> In that case, go with Cocoon unless you know it doesn't support something you
> need. Most of the work is already done, even if you do have to "hack"
> it now and then. Use Enhydra to do things Cocoon can't do. Otherwise, why
> reinvent the wheel?
Honest question from the ignorant: what does Enhydra does that Cocoon
can't do?
I'm asking because I could not find anything in which enhydra was
better... but of course I'm so biased that this is probably blinding me.
I would be happy if you guys could outline what you "don't like" about
Cocoon so that we can make it better.
I keep on hearing "cocoon is great", "thanks for doing this" and such...
hey, this is awesome and I love it, ok? but I want this project to grow
and growing means to polish the corners and smooth the angles.
But we can't do this if we don't see those rough angles.
Do I make sense?
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
Missed us in Orlando? Make it up with ApacheCON Europe in London!
------------------------- http://ApacheCon.Com ---------------------
Re: Enhydra vs Cocoon
Posted by Ed Knutson <ed...@webcombo.net>.
On Fri, 07 Apr 2000, Roman Seidl wrote:
> On Fri, 7 Apr 2000, Ed Knutson wrote:
>
> > So the question to ask is: am I trying to publish documents or build
> > applications?
> What if you build applications that publish documnets?
In that case, go with Cocoon unless you know it doesn't support something you
need. Most of the work is already done, even if you do have to "hack"
it now and then. Use Enhydra to do things Cocoon can't do. Otherwise, why
reinvent the wheel?
Re: Enhydra vs Cocoon
Posted by Roman Seidl <ro...@pvl.pvl.at>.
On Fri, 7 Apr 2000, Ed Knutson wrote:
> So the question to ask is: am I trying to publish documents or build
> applications?
What if you build applications that publish documnets?
cheers
roman
unsubscribe?
Posted by "Joseph B. Ottinger" <jo...@suninternet.com>.
I *really* hate to post this to the list, but I've tried to unsubscribe
from all the cocoon lists a number of times, and it never works. Can
anyone get me off of these lists?
-----------------------------------------------------------
Joseph B. Ottinger joeo@cupid.suninternet.com
http://cupid.suninternet.com/~joeo HOMES.COM Developer
Re: Enhydra vs Cocoon
Posted by Ed Knutson <ed...@webcombo.net>.
On Fri, 07 Apr 2000, Herv� Guidetti wrote:
> I surfed the web. I saw Enhydra (http://www.enhydra.org).
> What do you think about it ? What is the difference beteen Enhydra and
> Coccon ?
There is some overlap, but Enhydra is a very different product. In a nutshell:
makefiles.
I looked at Enhydra before I found Cocoon. It seemed like specifically it
would be good for interfacing XML with databases, but in general it was a lot
more complicated to set up and maintain than Cocoon.
Cocoon is very document driven and is a publishing framework.
Enhydra is more like rewriting little servlet fragments of Cocoon for each
equivalent task. It is an application framework.
So the question to ask is: am I trying to publish documents or build
applications?
-ed
Re: Enhydra vs Cocoon
Posted by Edwin Glaser <ed...@pannenleiter.de>.
You wrote:
> I have to choose, what do you advise me ?
OK, you did ask...
We have used both of them for real world applications. Enhydra
doesn't bring the power of XML/XSL in action. If you change the
style of your pages, you also have to change your Java code.
It may be a good choice, if you application logic is complicated
and the style of your pages will not change.
On the other hand, Cocoon is great if you need nifty pages. You
can redesign the style without affecting the logic. But the flow
control of Coocon has some limitations and it turned out that we
had to implement big parts in Java.
So we decided to restart from scratch with a flexible XSLT
based flow control. As you already guess, we recommend this
system - rmdms.sourceforge.net -.
--
Edwin Glaser -- edwin@pannenleiter.de
Re: Enhydra vs Cocoon
Posted by Yann <yl...@ims.ltd.uk>.
I am in the same situation. I have to say that Enhydra's forthcoming support
for J2EE is very attractive.
What are the plans for EJB support in Cocoon? Or will Cocoon remain a
servlet client to other EJB containers?
Yann.
P.S. BTW, I downloaded Cocoon a couple of days ago and I am going to use it
for a 3 weeks project. I have been able to prototype some ideas in a matter
of hours. You guys that have worked on Cocoon are really making our life so
much easier. Thanks ever so much again.