Re: How to load Cocoon into Eclipse-Tomcat plugin from Sysdeo

[Robert Simmons]

If you add the following Java options to the line that runs tomcat:

-Xint -Xdebug -Xrunjdwp:transport=dt_socket,server=y,address=12999,suspend=n

Then you can attach to tomcat using elicpse at the socket  12999. How to
attach eclipse specifically is somethign I dont know. I use NetBeans because
it is a far better product. However I think even eclipse will do this just
fine.

-- Robert

- Original Message -
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Wednesday, February 12, 2003 11:23 AM
Subject: RE: How to load Cocoon into Eclipse-Tomcat plugin from Sysdeo


Hi Robert,

I want to use the Eclipse debugger. I dont' if it is JPD compatible but I
think...

In Eclipse, how do you attach Tomcat remotely?

Thanks
Regards
Sylvain


-Message d'origine-
De: Robert Simmons [mailto:[EMAIL PROTECTED]]
Date: mardi, 11. février 2003 21:55
À: [EMAIL PROTECTED]
Objet: Re: How to load Cocoon into Eclipse-Tomcat plugin from Sysdeo


Debugging is easy if you have a JPD compatible debugger. Look at the Java
documentation on the Java command for info on how to run tomcat in debug
mode and then attach to it remotely. I use this technique with JBoss all the
time.

-- Robert

- Original Message -
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Tuesday, February 11, 2003 2:03 PM
Subject: RE: How to load Cocoon into Eclipse-Tomcat plugin from Sysdeo


Martin,

You said that you run Tomcat out of Eclipse. So you don't need a /WEB-INF
directory in your Eclipse project, right?
The Tomcat Eclipse runs Tomcat inside Eclipse. What is exactly the difference
between outside and inside?

To start/stop (outside) Tomcat from Eclipse, what do you change in
windows/Preferences?

At this time I don't want to develop components but I would like to debug the
existing components. Would be better to create Java project?


Thanks again
Best.
Sylvain



-Message d'origine-
De: Martin Dulisch [mailto:[EMAIL PROTECTED]]
Date: mardi, 11. février 2003 10:16
À: [EMAIL PROTECTED]
Objet: Re: How to load Cocoon into Eclipse-Tomcat plugin from Sysdeo


Sylvain,

I use the tomcat plug-in only to start/stop tomcat out of eclipse. I
dont use the tomcat project type.

If you want to develop java components like actions or transformers
than create a java project. If you do not develop java components than
you can create a simple project. The project folder should be in both
cases the tomcat/webapps/cocoon folder.

Java Build Path settings (Properties of the project):
- Build output folder: WEB-INF/classes
- Libraries: add libs from WEB-INF/lib you need to compile

To start/stop tomcat set the tomcat path in Windows/Preferences. The
tomcat plug-in starts tomcat in debug mode. So you can set breakpoints
in your source files. I use tomcat 4.1.X. Here hot code replacement
works for me.

For the non java work I use the sunBow plug-in :)

Hope I did not have forget anything.

Martin





- Original Message -
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Tuesday, February 11, 2003 9:47 AM
Subject: RE: How to load Cocoon into Eclipse-Tomcat plugin from Sysdeo


Hi Martin,

I want to develop application like you. And I have installed this
Tomcat plugin to debug my app and the Cocoon sources. I don't want to
work at the Cocoon sources, only understand how it works for
debugging.

Yes please. A description of your environment in Eclipse would be
greatly appreciated.

Thank you very much
Regards
Sylvain

-Message d'origine-
De: Martin Dulisch [mailto:[EMAIL PROTECTED]]
Date: mardi, 11. février 2003 09:23
À: [EMAIL PROTECTED]
Objet: Re: How to load Cocoon into Eclipse-Tomcat plugin from Sysdeo


Hi Sylvain,

what do you want to do with this project? Application development with
cocoon or do you want to work at the cocoon sources?

I do the first one. If you want to do the same I could describe my
environment in eclipse.

Martin

- Original Message -
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Monday, February 10, 2003 4:55 PM
Subject: How to load Cocoon into Eclipse-Tomcat plugin from Sysdeo


Is there someone that could explain me how to load Cocoon into a
Tomcat project in Eclipse?
This type of project comes from the Sysdeo plugin which allow to run
Tomcat into Eclipse.

Thanks
Regards
Sylvain

-
Please check that your question  has not already been answered in the
FAQ before posting. http://xml.apache.org/cocoon/faq/index.html

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail:   [EMAIL PROTECTED]


-
Please check that your question  has not already been answered in the
FAQ before posting. http://xml.apache.org/cocoon/faq/index.html

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail:   [EMAIL PROTECTED]


-
Please check that your

Re: Too much java in xsp

[Robert Simmons]

Probably a generator actually. Use generators for things that are more
complex. XSP should be used, IMHO, only for generation with small amounts of
code.

-- Robert

- Original Message -
From: Lionel Crine [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Wednesday, February 12, 2003 5:40 PM
Subject: Too much java in xsp


 I'm using an xsp in which I manipulate some code (xsp:request parameters,
 for example).

 But unfortunately, There is too much code java in it and so the xsp is very
 HUGE.

 I was thinking about using an action in the sitemap to modify my document
 instead of java code in the xsp, is it a good idea ?

 am I on the right way ?


 -
 Please check that your question  has not already been answered in the
 FAQ before posting. http://xml.apache.org/cocoon/faq/index.html

 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail:   [EMAIL PROTECTED]



-
Please check that your question  has not already been answered in the
FAQ before posting. http://xml.apache.org/cocoon/faq/index.html

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail:   [EMAIL PROTECTED]

Re: A note about the best(?) (cocoon-) development environment ...

[Robert Simmons]

NetBeans at www.netbeans.org has these features in its XML editor.

-- Robert

- Original Message -
From: Rob Hoopman [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Tuesday, February 11, 2003 12:43 PM
Subject: Re: A note about the best(?) (cocoon-) development environment ...


 SAXESS - Hussayn Dabbous wrote:

 snip

  5.) eclipse
  6.) sunbow eclipse tools (xml/sitemap)

 snip

 I'm currently evaluating oxygen (http://www.oxygenxml.com), it has
 tag-closing DTD/Schema aware tag insert and XSLT transformation
 functionality and so far I'm impressed by it.

 Do any of you know any other editors that support similar functionality?
 I'm tempted to spring the USD 65 (USD 25 academic)  when my evaluation
 expires, but there might be something better out there?


 Regards.

 Rob



 -
 Please check that your question  has not already been answered in the
 FAQ before posting. http://xml.apache.org/cocoon/faq/index.html

 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail:   [EMAIL PROTECTED]



-
Please check that your question  has not already been answered in the
FAQ before posting. http://xml.apache.org/cocoon/faq/index.html

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail:   [EMAIL PROTECTED]

Re: How to load Cocoon into Eclipse-Tomcat plugin from Sysdeo

[Robert Simmons]

Debugging is easy if you have a JPD compatible debugger. Look at the Java
documentation on the Java command for info on how to run tomcat in debug
mode and then attach to it remotely. I use this technique with JBoss all the
time.

-- Robert

- Original Message -
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Tuesday, February 11, 2003 2:03 PM
Subject: RE: How to load Cocoon into Eclipse-Tomcat plugin from Sysdeo


Martin,

You said that you run Tomcat out of Eclipse. So you don't need a /WEB-INF
directory in your Eclipse project, right?
The Tomcat Eclipse runs Tomcat inside Eclipse. What is exactly the difference
between outside and inside?

To start/stop (outside) Tomcat from Eclipse, what do you change in
windows/Preferences?

At this time I don't want to develop components but I would like to debug the
existing components. Would be better to create Java project?


Thanks again
Best.
Sylvain



-Message d'origine-
De: Martin Dulisch [mailto:[EMAIL PROTECTED]]
Date: mardi, 11. février 2003 10:16
À: [EMAIL PROTECTED]
Objet: Re: How to load Cocoon into Eclipse-Tomcat plugin from Sysdeo


Sylvain,

I use the tomcat plug-in only to start/stop tomcat out of eclipse. I
dont use the tomcat project type.

If you want to develop java components like actions or transformers
than create a java project. If you do not develop java components than
you can create a simple project. The project folder should be in both
cases the tomcat/webapps/cocoon folder.

Java Build Path settings (Properties of the project):
- Build output folder: WEB-INF/classes
- Libraries: add libs from WEB-INF/lib you need to compile

To start/stop tomcat set the tomcat path in Windows/Preferences. The
tomcat plug-in starts tomcat in debug mode. So you can set breakpoints
in your source files. I use tomcat 4.1.X. Here hot code replacement
works for me.

For the non java work I use the sunBow plug-in :)

Hope I did not have forget anything.

Martin





- Original Message -
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Tuesday, February 11, 2003 9:47 AM
Subject: RE: How to load Cocoon into Eclipse-Tomcat plugin from Sysdeo


Hi Martin,

I want to develop application like you. And I have installed this
Tomcat plugin to debug my app and the Cocoon sources. I don't want to
work at the Cocoon sources, only understand how it works for
debugging.

Yes please. A description of your environment in Eclipse would be
greatly appreciated.

Thank you very much
Regards
Sylvain

-Message d'origine-
De: Martin Dulisch [mailto:[EMAIL PROTECTED]]
Date: mardi, 11. février 2003 09:23
À: [EMAIL PROTECTED]
Objet: Re: How to load Cocoon into Eclipse-Tomcat plugin from Sysdeo


Hi Sylvain,

what do you want to do with this project? Application development with
cocoon or do you want to work at the cocoon sources?

I do the first one. If you want to do the same I could describe my
environment in eclipse.

Martin

- Original Message -
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Monday, February 10, 2003 4:55 PM
Subject: How to load Cocoon into Eclipse-Tomcat plugin from Sysdeo


Is there someone that could explain me how to load Cocoon into a
Tomcat project in Eclipse?
This type of project comes from the Sysdeo plugin which allow to run
Tomcat into Eclipse.

Thanks
Regards
Sylvain

-
Please check that your question  has not already been answered in the
FAQ before posting. http://xml.apache.org/cocoon/faq/index.html

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail:   [EMAIL PROTECTED]


-
Please check that your question  has not already been answered in the
FAQ before posting. http://xml.apache.org/cocoon/faq/index.html

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail:   [EMAIL PROTECTED]


-
Please check that your question  has not already been answered in the
FAQ before posting. http://xml.apache.org/cocoon/faq/index.html

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail:   [EMAIL PROTECTED]


-
Please check that your question  has not already been answered in the
FAQ before posting. http://xml.apache.org/cocoon/faq/index.html

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail:   [EMAIL PROTECTED]


-
Please check that your question  has not already been answered in the
FAQ before posting. http://xml.apache.org/cocoon/faq/index.html

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail:   [EMAIL PROTECTED]


-
Please check that your question  has not 

Jobs in the UK

[Robert Simmons]

Search for XML and XSLT in the UK job board 
revealed 55 positions!!! Check them out if you are contemplating speaking 
Brit for a while. 

http://www.theitjobboard.com/searchresults.php?keywords=XML+xslttype=0location%5B%5D=999days=0

-- Robert

Re: xsp util and file contents

[Robert Simmons]

XSP is just XML. Just write a transformer that copies the XML into the XSP
file. Run this transformer before you run the XSP transformer in the sitemap
and viola, problem solved.

Hmm, I'm starting to get the hang of this thing  scary.

-- Robert

- Original Message -
From: Leszek Gawron [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Tuesday, February 11, 2003 10:33 PM
Subject: Re: xsp util and file contents


 On wto, lut 11, 2003 at 09:13:08 -, Tom Place wrote:
  Hi,
 
  I'm trying to insert xml into my xsp, this xml is for navigation
  purposes so ideally I would like to use one navigation file in many
  different xsp documents.
 Apart from your problem : why don't you use aggregation?
 ouzo
 --
 __
  | /  \ |Leszek Gawron//  \\
 \_\\  //_/  [EMAIL PROTECTED]  _\\()//_
  .'/()\'. Phone: +48(600)341118 / //  \\ \
   \\  //  recursive: adj; see recursive  | \__/ |


 -
 Please check that your question  has not already been answered in the
 FAQ before posting. http://xml.apache.org/cocoon/faq/index.html

 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail:   [EMAIL PROTECTED]



-
Please check that your question  has not already been answered in the
FAQ before posting. http://xml.apache.org/cocoon/faq/index.html

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail:   [EMAIL PROTECTED]

Javadoc in XML Format?

[Robert Simmons]

Greetings,I have been looking for a doclet 
that will create Javadoc API documentation but in XML format. This could then be 
used with cocoon to give far mroe control over rendering javadoc. I have looked 
through the internet and it appears Apache had a project on it at one time but 
now i cant find any links to it. Anyone know where i could find such an animal? 
The default HTML Javadoc is such a drag. =) 


-- Robert

Re: A note about the best(?) (cocoon-) development environment ...

[Robert Simmons]

Nope. 100% pure Java specification. Give it a read. The first couple chapters
will give you a good idea of its meaning.

-- Robert

- Original Message -
From: Niclas Hedhman [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Sunday, February 09, 2003 9:30 AM
Subject: Re: A note about the best(?) (cocoon-) development environment ...


On Sunday 09 February 2003 05:59, Robert Simmons wrote:
 Sun JDO JSR-12.

And I thought this is a Java specific specification of the ODMG model. No?


 - Original Message -
 From: Thor Heinrichs-Wolpert [EMAIL PROTECTED]
 To: [EMAIL PROTECTED]
 Sent: Saturday, February 08, 2003 10:22 PM
 Subject: Re: A note about the best(?) (cocoon-) development environment
 ...


 Which JDO?  The ODMG JDO (like what Castor uses) or the after class
 generation muck about that is in the Sun JDO?

 Jetty has been using JMX long before Tomcat, it fully supports the spec
 ... and I'm thinking it supports it before the reference implementation
 does (like the classpath stuff).  Is it superior, I can't say for sure
 (but it is the default / preferred servlet engine in JBoss.  I like it
 because it takes me less screwing around with jar clashes between
 applications and what the server itself uses (making me less dependent
 on their support cycle and changes in where the JDK wants things).

 Cheers,
 Thor HW

 On Saturday, February 8, 2003, at 01:05  PM, Robert Simmons wrote:
  I use JBoss but not jetty. Are you saying the Jetty-JBoss combo is
  superior
  to the Tomcat-JBoss combo? If so, I will definitely go try it. Perhaps
  it
  will fix my classpath in XSP issue. Bugzilla Reference:
  http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16580.
 
  Kodo JDO is an implementation of the JDO specification and MORE. It
  basically
  rules. Go through the tutorials and you will love it. Create an object
  model
  using your favorite problem domain. Then create the JDO mapping file
  (raw XML
  or with IDE plug-in) and then just say uhh, make a schema for me and
  it
  just does it. Its amazing! No more screwing around with persistence and
  schema manipulation.
 
  I have the commercial version of that product and will be talking
  about using
  it in the book that I am writing.
 
  -- Robert
 
 
 
  - Original Message -
  From: Thor Heinrichs-Wolpert [EMAIL PROTECTED]
  To: [EMAIL PROTECTED]
  Sent: Saturday, February 08, 2003 9:47 PM
  Subject: Re: A note about the best(?) (cocoon-) development
  environment ...
 
 
  Robert:
 
  Have a look at Jetty, or JBoss/Jetty (aka JBossWeb).  No nasty must
  copy things to endorsed directories, etc.).  You take Cocoon (2.0/2.1)
  and drop it in your deploy directory and POOF it's there.  It's nice
  when the servlet engine actually uses the libs you define and not its
  own first as the default ... isn't that in the spec ... and will be
  available in Tomcat at some point.
 
  If you want any extra libs in cocoon-2.1 you add them in the lib tree,
  add them to jars.xml and the cocoon build adds them to the Manifest ...
  Jetty/Jboss just eats 'em up in the right place.
 
  I'm off to look for Kudo JDO (which hopefully follows the ODMG JDO and
  not Sun's) ... how does this rank against Castor or Jakarta-OJB ?
 
  Cheers,
  Thor HW
 
  On Saturday, February 8, 2003, at 11:42  AM, Robert Simmons wrote:
  Hy, all;
 
  During the last months of activities i learned a lot from this
  mailing
  list. while i followed the discussions i started getting my
  development
  environment a bit up to date.  I plan to setup a Wiki page on this
  theme. Although this may be a bit off topic, it still would be great,
  if someone could comment on this issue.
 
 
  the tools collection
  
  Here is what i have put together so far. Of course this is driven
  at least partially by what i do for my customers...
 
  free tools:
  1.) OS: linux and solaris (maybe a mater of taste)
 
  Go linux. Instead of spending money on licenses, you spend money on
  support
  contracts. Cheaper. In addition, Solaris is primitive compared to
  Linux.
 
  2.) apache 1.3.26 (mod_jk2, mod_SSL)
 
  Duh ;)
 
  3.) tomcat 4.1.18
 
  Yes, but you can go one step further. Get JBoss with integrated
  tomcat. JBoss
  will handle all sorty of nasty things like deploying to clusters for
  you. As
  a bonus, you get the ability to integrate with EJB based programs.
 
  4.) cocoon-2.0.4
 
  2.1 Hopefully soon!
 
  5.) eclipse
 
  See my previous message about eclopse vs netbeans.
 
  6.) sunbow eclipse tools (xml/sitemap)
 
  URL ?
 
  7.) ant
 
  I have 15 million of them in my damn appartment, want a few? Oh ...
  you mean
  Jakarta ant? Ok, nevermind then. =) Im currently looking at Krysalis'
  extensions to ant. http://www.krysalis.org/centipede/quickstart.html
 
  8.) java-1.3.1 (sun JDK on all platforms)
 
  No no .. 1.4.1!! In 1.4 there are so many COOOL things that I
  couldnt
  live without anymore.
 
  9.) Secureway LDAP Server (i'll switch to Open LDAP soon

Re: A note about the best(?) (cocoon-) development environment ...

[Robert Simmons]

Point of correction. Class enhancement is not generation per se. The actual
class files are enhanced in place. In other words the byte code enhancers go
into the class files and alter them. The solution elegantly solves some nasty
problems.

-- Robert

- Original Message -
From: Robert Simmons [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Saturday, February 08, 2003 10:59 PM
Subject: Re: A note about the best(?) (cocoon-) development environment ...


 Sun JDO JSR-12.


 - Original Message -
 From: Thor Heinrichs-Wolpert [EMAIL PROTECTED]
 To: [EMAIL PROTECTED]
 Sent: Saturday, February 08, 2003 10:22 PM
 Subject: Re: A note about the best(?) (cocoon-) development environment
...


 Which JDO?  The ODMG JDO (like what Castor uses) or the after class
 generation muck about that is in the Sun JDO?

 Jetty has been using JMX long before Tomcat, it fully supports the spec
 ... and I'm thinking it supports it before the reference implementation
 does (like the classpath stuff).  Is it superior, I can't say for sure
 (but it is the default / preferred servlet engine in JBoss.  I like it
 because it takes me less screwing around with jar clashes between
 applications and what the server itself uses (making me less dependent
 on their support cycle and changes in where the JDK wants things).

 Cheers,
 Thor HW

 On Saturday, February 8, 2003, at 01:05  PM, Robert Simmons wrote:

  I use JBoss but not jetty. Are you saying the Jetty-JBoss combo is
  superior
  to the Tomcat-JBoss combo? If so, I will definitely go try it. Perhaps
  it
  will fix my classpath in XSP issue. Bugzilla Reference:
  http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16580.
 
  Kodo JDO is an implementation of the JDO specification and MORE. It
  basically
  rules. Go through the tutorials and you will love it. Create an object
  model
  using your favorite problem domain. Then create the JDO mapping file
  (raw XML
  or with IDE plug-in) and then just say uhh, make a schema for me and
  it
  just does it. Its amazing! No more screwing around with persistence and
  schema manipulation.
 
  I have the commercial version of that product and will be talking
  about using
  it in the book that I am writing.
 
  -- Robert
 
 
 
  - Original Message -
  From: Thor Heinrichs-Wolpert [EMAIL PROTECTED]
  To: [EMAIL PROTECTED]
  Sent: Saturday, February 08, 2003 9:47 PM
  Subject: Re: A note about the best(?) (cocoon-) development
  environment ...
 
 
  Robert:
 
  Have a look at Jetty, or JBoss/Jetty (aka JBossWeb).  No nasty must
  copy things to endorsed directories, etc.).  You take Cocoon (2.0/2.1)
  and drop it in your deploy directory and POOF it's there.  It's nice
  when the servlet engine actually uses the libs you define and not its
  own first as the default ... isn't that in the spec ... and will be
  available in Tomcat at some point.
 
  If you want any extra libs in cocoon-2.1 you add them in the lib tree,
  add them to jars.xml and the cocoon build adds them to the Manifest ...
  Jetty/Jboss just eats 'em up in the right place.
 
  I'm off to look for Kudo JDO (which hopefully follows the ODMG JDO and
  not Sun's) ... how does this rank against Castor or Jakarta-OJB ?
 
  Cheers,
  Thor HW
 
  On Saturday, February 8, 2003, at 11:42  AM, Robert Simmons wrote:
 
  Hy, all;
 
  During the last months of activities i learned a lot from this
  mailing
  list. while i followed the discussions i started getting my
  development
  environment a bit up to date.  I plan to setup a Wiki page on this
  theme. Although this may be a bit off topic, it still would be great,
  if someone could comment on this issue.
 
 
  the tools collection
  
  Here is what i have put together so far. Of course this is driven
  at least partially by what i do for my customers...
 
  free tools:
  1.) OS: linux and solaris (maybe a mater of taste)
 
  Go linux. Instead of spending money on licenses, you spend money on
  support
  contracts. Cheaper. In addition, Solaris is primitive compared to
  Linux.
 
  2.) apache 1.3.26 (mod_jk2, mod_SSL)
 
  Duh ;)
 
  3.) tomcat 4.1.18
 
  Yes, but you can go one step further. Get JBoss with integrated
  tomcat. JBoss
  will handle all sorty of nasty things like deploying to clusters for
  you. As
  a bonus, you get the ability to integrate with EJB based programs.
 
  4.) cocoon-2.0.4
 
  2.1 Hopefully soon!
 
  5.) eclipse
 
  See my previous message about eclopse vs netbeans.
 
  6.) sunbow eclipse tools (xml/sitemap)
 
  URL ?
 
  7.) ant
 
  I have 15 million of them in my damn appartment, want a few? Oh ...
  you mean
  Jakarta ant? Ok, nevermind then. =) Im currently looking at Krysalis'
  extensions to ant. http://www.krysalis.org/centipede/quickstart.html
 
 
  8.) java-1.3.1 (sun JDK on all platforms)
 
  No no .. 1.4.1!! In 1.4 there are so many COOOL things that I
  couldnt
  live without anymore.
 
  9.) Secureway LDAP Server (i'll switch to Open LDAP soon

Re: A note about the best(?) (cocoon-) development environment ...

[Robert Simmons]

Yes. That is part of the specification. The enhancement is to byte code, not
to native versions of the code. Therefore any JVM can read the enhanced
files. You might look at Jakarta's BCEL project to get an idea about how byte
code enhancement works.

As for the ODMG vs. byte code enhancement, Id have to disagree. The thing I
want out of a persistence project is a fire and forget solution. As a
consultant, I don't get paid for providing persistence solutions. I get paid
for working on what makes my clients money. Be that web purchasing or genetic
engineering. I am far better off having solutions where I need to invest only
small amounts of thought in how to persist data and do object to relational
mapping.

In addition, there are instances, many of them, where you have neither
control of the data that needs to be stored, nor access to the class files
defining these data objects. At which point the JDO approach is far superior.
Lastly the JDO approach provides the ability to reverse engineer schemas into
the cross JDO vendor portable JDO metadeta files. This gives enormous power
when working with legacy databases.

-- Robert

- Original Message -
From: Thor Heinrichs-Wolpert [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Monday, February 10, 2003 1:37 AM
Subject: Re: A note about the best(?) (cocoon-) development environment ...


Have you found that it works well for you across JVM versions and
implementations?  The ODMG JDO works everywhere.

On Sunday, February 9, 2003, at 05:22  AM, Robert Simmons wrote:

 Point of correction. Class enhancement is not generation per se. The
 actual
 class files are enhanced in place. In other words the byte code
 enhancers go
 into the class files and alter them. The solution elegantly solves
 some nasty
 problems.

 -- Robert

 - Original Message -
 From: Robert Simmons [EMAIL PROTECTED]
 To: [EMAIL PROTECTED]
 Sent: Saturday, February 08, 2003 10:59 PM
 Subject: Re: A note about the best(?) (cocoon-) development
 environment ...


 Sun JDO JSR-12.


 - Original Message -
 From: Thor Heinrichs-Wolpert [EMAIL PROTECTED]
 To: [EMAIL PROTECTED]
 Sent: Saturday, February 08, 2003 10:22 PM
 Subject: Re: A note about the best(?) (cocoon-) development
 environment
 ...


 Which JDO?  The ODMG JDO (like what Castor uses) or the after class
 generation muck about that is in the Sun JDO?

 Jetty has been using JMX long before Tomcat, it fully supports the
 spec
 ... and I'm thinking it supports it before the reference
 implementation
 does (like the classpath stuff).  Is it superior, I can't say for sure
 (but it is the default / preferred servlet engine in JBoss.  I like it
 because it takes me less screwing around with jar clashes between
 applications and what the server itself uses (making me less dependent
 on their support cycle and changes in where the JDK wants things).

 Cheers,
 Thor HW

 On Saturday, February 8, 2003, at 01:05  PM, Robert Simmons wrote:

 I use JBoss but not jetty. Are you saying the Jetty-JBoss combo is
 superior
 to the Tomcat-JBoss combo? If so, I will definitely go try it.
 Perhaps
 it
 will fix my classpath in XSP issue. Bugzilla Reference:
 http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16580.

 Kodo JDO is an implementation of the JDO specification and MORE. It
 basically
 rules. Go through the tutorials and you will love it. Create an
 object
 model
 using your favorite problem domain. Then create the JDO mapping file
 (raw XML
 or with IDE plug-in) and then just say uhh, make a schema for me
 and
 it
 just does it. Its amazing! No more screwing around with persistence
 and
 schema manipulation.

 I have the commercial version of that product and will be talking
 about using
 it in the book that I am writing.

 -- Robert



 - Original Message -
 From: Thor Heinrichs-Wolpert [EMAIL PROTECTED]
 To: [EMAIL PROTECTED]
 Sent: Saturday, February 08, 2003 9:47 PM
 Subject: Re: A note about the best(?) (cocoon-) development
 environment ...


 Robert:

 Have a look at Jetty, or JBoss/Jetty (aka JBossWeb).  No nasty must
 copy things to endorsed directories, etc.).  You take Cocoon
 (2.0/2.1)
 and drop it in your deploy directory and POOF it's there.  It's nice
 when the servlet engine actually uses the libs you define and not its
 own first as the default ... isn't that in the spec ... and will be
 available in Tomcat at some point.

 If you want any extra libs in cocoon-2.1 you add them in the lib
 tree,
 add them to jars.xml and the cocoon build adds them to the Manifest
 ...
 Jetty/Jboss just eats 'em up in the right place.

 I'm off to look for Kudo JDO (which hopefully follows the ODMG JDO
 and
 not Sun's) ... how does this rank against Castor or Jakarta-OJB ?

 Cheers,
 Thor HW

 On Saturday, February 8, 2003, at 11:42  AM, Robert Simmons wrote:

 Hy, all;

 During the last months of activities i learned a lot from this
 mailing
 list. while i followed the discussions i started getting my
 development

Re: A note about the best(?) (cocoon-) development environment ...

[Robert Simmons]

Well, I don't want to debate JDO vs. ODMG object mapping. I use JDO as will a
very large amount of other people. Don't judge it when you know little about
it. As for the query language, it blasts any other object based query
language to hell. As for CMP and BMP, you can toss those out the window.
Entity beans are the one blemish to EJB in my opinion. They are poorly
thought out and poorly implemented. In short, all entity beans are basically
crap.

-- Robert

- Original Message -
From: Thor Heinrichs-Wolpert [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Monday, February 10, 2003 2:25 AM
Subject: Re: A note about the best(?) (cocoon-) development environment ...


I'm familiar with BCEL and have used it to speed up JMX and reflection
based applications.
I haven't found the ODMG way to be very slow.  Are we comparing specs
to tools?  Most things can auto-deploy schemas, but very few of my
clients will use such a feature.
We've used several ODMG based solutions to take advantage of a
particular vendors enhancements, or J2C connectors.  I can say that in
the past my team of 3 have used these techniques to deliver
maintainable, workable solutions very quickly.

If you're persisting classes that you don't have control over, nor
access to the class files (don't you need access to manipulate them?)
then I'd be worried about version management and coupling.

But, I'll have another look.  Last thing, it's too bad that with JDO
they have introduced 3 query languages, rather than have one that works
for JDO, CMP-EJB, etc.

Cheers,
Thor HW

On Sunday, February 9, 2003, at 04:56  PM, Robert Simmons wrote:

 Yes. That is part of the specification. The enhancement is to byte
 code, not
 to native versions of the code. Therefore any JVM can read the enhanced
 files. You might look at Jakarta's BCEL project to get an idea about
 how byte
 code enhancement works.

 As for the ODMG vs. byte code enhancement, Id have to disagree. The
 thing I
 want out of a persistence project is a fire and forget solution. As a
 consultant, I don't get paid for providing persistence solutions. I
 get paid
 for working on what makes my clients money. Be that web purchasing or
 genetic
 engineering. I am far better off having solutions where I need to
 invest only
 small amounts of thought in how to persist data and do object to
 relational
 mapping.

 In addition, there are instances, many of them, where you have neither
 control of the data that needs to be stored, nor access to the class
 files
 defining these data objects. At which point the JDO approach is far
 superior.
 Lastly the JDO approach provides the ability to reverse engineer
 schemas into
 the cross JDO vendor portable JDO metadeta files. This gives enormous
 power
 when working with legacy databases.

 -- Robert

 - Original Message -
 From: Thor Heinrichs-Wolpert [EMAIL PROTECTED]
 To: [EMAIL PROTECTED]
 Sent: Monday, February 10, 2003 1:37 AM
 Subject: Re: A note about the best(?) (cocoon-) development
 environment ...


 Have you found that it works well for you across JVM versions and
 implementations?  The ODMG JDO works everywhere.

 On Sunday, February 9, 2003, at 05:22  AM, Robert Simmons wrote:

 Point of correction. Class enhancement is not generation per se. The
 actual
 class files are enhanced in place. In other words the byte code
 enhancers go
 into the class files and alter them. The solution elegantly solves
 some nasty
 problems.

 -- Robert

 - Original Message -
 From: Robert Simmons [EMAIL PROTECTED]
 To: [EMAIL PROTECTED]
 Sent: Saturday, February 08, 2003 10:59 PM
 Subject: Re: A note about the best(?) (cocoon-) development
 environment ...


 Sun JDO JSR-12.


 - Original Message -
 From: Thor Heinrichs-Wolpert [EMAIL PROTECTED]
 To: [EMAIL PROTECTED]
 Sent: Saturday, February 08, 2003 10:22 PM
 Subject: Re: A note about the best(?) (cocoon-) development
 environment
 ...


 Which JDO?  The ODMG JDO (like what Castor uses) or the after class
 generation muck about that is in the Sun JDO?

 Jetty has been using JMX long before Tomcat, it fully supports the
 spec
 ... and I'm thinking it supports it before the reference
 implementation
 does (like the classpath stuff).  Is it superior, I can't say for
 sure
 (but it is the default / preferred servlet engine in JBoss.  I like
 it
 because it takes me less screwing around with jar clashes between
 applications and what the server itself uses (making me less
 dependent
 on their support cycle and changes in where the JDK wants things).

 Cheers,
 Thor HW

 On Saturday, February 8, 2003, at 01:05  PM, Robert Simmons wrote:

 I use JBoss but not jetty. Are you saying the Jetty-JBoss combo is
 superior
 to the Tomcat-JBoss combo? If so, I will definitely go try it.
 Perhaps
 it
 will fix my classpath in XSP issue. Bugzilla Reference:
 http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16580.

 Kodo JDO is an implementation of the JDO specification and MORE. It
 basically
 rules

Re: A note about the best(?) (cocoon-) development environment ...

[Robert Simmons]

I find eclipse to be a bit too pushy for my tastes. The NetBeans platform
is a bit more open. In addition the eclipse XML editor is a little primitive.
The NetBeans one at least closes tags and offers various other functionality.
Additionally the eclipse release schedule is almost wholly managed by IBM
which makes it a hit or miss thing. The last straw is the relatively limited
plug-in availability for eclipse. It took me hours just to find a site with a
full eclipse module catalog.

The only other comment I have is that I'm still searching for a content
editor for Static XML. I'm currently investigating using adobe FrameMaker.
The idea being that I would have a WYSIWYG way of editing documents that any
one of my clients could use and I could write XSLT processors to convert that
to the web format using cocoon. Right now the current XML editors are too
primitive. Usable for a programmer but for a corporate document jockey, no
chance.

-- Robert

- Original Message -
From: SAXESS - Hussayn Dabbous [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Saturday, February 08, 2003 12:46 PM
Subject: A note about the best(?) (cocoon-) development environment ...


 Hy, all;

 During the last months of activities i learned a lot from this mailing
 list. while i followed the discussions i started getting my development
 environment a bit up to date.  I plan to setup a Wiki page on this
 theme. Although this may be a bit off topic, it still would be great,
 if someone could comment on this issue.


 the tools collection
 
 Here is what i have put together so far. Of course this is driven
 at least partially by what i do for my customers...

 free tools:
 1.) OS: linux and solaris (maybe a mater of taste)
 2.) apache 1.3.26 (mod_jk2, mod_SSL)
 3.) tomcat 4.1.18
 4.) cocoon-2.0.4
 5.) eclipse
 6.) sunbow eclipse tools (xml/sitemap)
 7.) ant
 8.) java-1.3.1 (sun JDK on all platforms)
 9.) Secureway LDAP Server (i'll switch to Open LDAP soon)

 commercial tools:
 10.) clearcase cms (see below)
 11.) xml-spy
 12.) several DB-Systems

 notes about the collection
 --

 * All tools mentioned above fit tightly together.
I use apache/tomcat since about three years now.
The above combination also works fine with SSL.

 * After i got eclipse setup in tomcat debugging mode,
i could at least double my productivity.
Thanks to the tomcat site it was a matter of seconds to
get it up see:

 http://jakarta.apache.org/site/idedev-rdtomcat.html

 * I also managed to setup eclipse with Cocoon in less than 10
minutes. OK, i did a lousy trick, but for debugging and
learning how cocoon internals  work it's absolutley
satisfying...

 * about SCM in general and Clearcase in particular:
Clearcase is a quite expensive and known to be very slow
SCM tool. On the other hand it is super easy to integrate.
Due to exposing the data within a virtual filesystem you
just don't see it from the users viewpoint (except checkin
checkout your files).
Having the clearcase integration kit for eclipse up and
running comes near to a developers dream. I hope, after
Rational has been incorporated into IBM, clearcase or a
derivate of it will eventually find it's way into the
ongoing eclipse efforts to build just another SCM. See

  http://www.eclipse.org/technology/index.html
  follow the link to stellation at the bottom of the page.

Another interesting new SCM could be subversion from

  http://subversion.tigris.org/ ...

All of these SCM's provide directory versioning
(something once you got it, you'll never want to miss again...)

 * I happen to use XML-Spy since a couple of years now.
Maybe i just got used to it. I like it, although i have
to pay for the license. At least it helps me getting
my XSCHEMA's generated in no time.


 My personal SAXESS story ...
 
 SAXESS stands for System AXESS, just to get this clear;-)
 I write this down, mainly because i got very very satisfied
 with this especially when i compare this to what i was used
 to in former times when open source was something, nobody
 ever heard of...

 I'm running my webserver on some linux box and my webapps
 on solaris driven by tomcat. All of my code is dropped
 into a company wide  multiplatform SCM system. I'm developing
 with the eclipse IDE right on my Desktop machine. I'm running
 Cocoon for the visualisation part of my projects. This is just
 a great XML publishing tool, and i'm still only using the
 basics of it for now. By saving my work to the SCM,
 my testwebapp gets autodeployed on a solaris box, which
 happens to be our testenvironment. I can setup remote debuggig
 sessions from my desktop directly into the heart of my
 webapplications...
 Once i checked in my work into the SCM, my webapp gets
 autodeployed on linux, which happens to be our website
 server. And i bet, after fiddeling around a bit, i could

Javadoc Doclets Compatible with cocoon ?

[Robert Simmons]

Greetings. Does anyone know a Javadoc Doclet that 
puts out documentation with XML markup that would be usable within a cocoon 
distribution? Id like to set up a system where I have a bit more control over 
rendering of the Javadoc and where I can have the Javadoc auto-generated nightly 
and available by intranet on the web via XML-XSLT. 

-- Robert

Re: A note about the best(?) (cocoon-) development environment ...

[Robert Simmons]

 Hy, all;

 During the last months of activities i learned a lot from this mailing
 list. while i followed the discussions i started getting my development
 environment a bit up to date.  I plan to setup a Wiki page on this
 theme. Although this may be a bit off topic, it still would be great,
 if someone could comment on this issue.


 the tools collection
 
 Here is what i have put together so far. Of course this is driven
 at least partially by what i do for my customers...

 free tools:
 1.) OS: linux and solaris (maybe a mater of taste)

Go linux. Instead of spending money on licenses, you spend money on support
contracts. Cheaper. In addition, Solaris is primitive compared to Linux.

 2.) apache 1.3.26 (mod_jk2, mod_SSL)

Duh ;)

 3.) tomcat 4.1.18

Yes, but you can go one step further. Get JBoss with integrated tomcat. JBoss
will handle all sorty of nasty things like deploying to clusters for you. As
a bonus, you get the ability to integrate with EJB based programs.

 4.) cocoon-2.0.4

2.1 Hopefully soon!

 5.) eclipse

See my previous message about eclopse vs netbeans.

 6.) sunbow eclipse tools (xml/sitemap)

URL ?

 7.) ant

I have 15 million of them in my damn appartment, want a few? Oh ... you mean
Jakarta ant? Ok, nevermind then. =) Im currently looking at Krysalis'
extensions to ant. http://www.krysalis.org/centipede/quickstart.html


 8.) java-1.3.1 (sun JDK on all platforms)

No no .. 1.4.1!! In 1.4 there are so many COOOL things that I couldnt
live without anymore.

 9.) Secureway LDAP Server (i'll switch to Open LDAP soon)

Im an LDAP idiot so Ill trust you there.

Tools you didnt talk  about:

CVS - Use it over clearcase. its powerful, free, and a pleasure to use.
BugZilla - Great program! Lousy looking interface. We should start a
project to port
it to cocoon. =) However bugzilla is a great and free
bugtracking system.

 commercial tools:
 10.) clearcase cms (see below)

Garbage.

 11.) xml-spy

Good but confusing.

 12.) several DB-Systems

all you need is Mysql baby.

Ones you didnt talk about:

13) Together control center. If you can afford it, it absolutely kills any
other IDE on the planet.
14) eXcelon Stylus Studio. A great XML editor. It has a bonus of being easy
to use and allot less confusing than XML Spy.
15) User editors for creating static content. (FrameMaker? OpenOffice? Im
still working on this one)
16) Kodo JDO. Dont leave home without it. All that nasty persistence stuff
just goes POOOF.


 notes about the collection
 --

 * All tools mentioned above fit tightly together.
I use apache/tomcat since about three years now.
The above combination also works fine with SSL.

 * After i got eclipse setup in tomcat debugging mode,
i could at least double my productivity.
Thanks to the tomcat site it was a matter of seconds to
get it up see:

 http://jakarta.apache.org/site/idedev-rdtomcat.html

 * I also managed to setup eclipse with Cocoon in less than 10
minutes. OK, i did a lousy trick, but for debugging and
learning how cocoon internals  work it's absolutley
satisfying...

Shouldnt be tough, just run tomcat (or JBoss) in debug mode with a socket
attach. Then you can remote attach to the socket and you are on your way!


 * about SCM in general and Clearcase in particular:
Clearcase is a quite expensive and known to be very slow
SCM tool. On the other hand it is super easy to integrate.
Due to exposing the data within a virtual filesystem you
just don't see it from the users viewpoint (except checkin
checkout your files).
Having the clearcase integration kit for eclipse up and
running comes near to a developers dream. I hope, after
Rational has been incorporated into IBM, clearcase or a
derivate of it will eventually find it's way into the
ongoing eclipse efforts to build just another SCM. See

  http://www.eclipse.org/technology/index.html
  follow the link to stellation at the bottom of the page.

Another interesting new SCM could be subversion from

  http://subversion.tigris.org/ ...

All of these SCM's provide directory versioning
(something once you got it, you'll never want to miss again...)

 * I happen to use XML-Spy since a couple of years now.
Maybe i just got used to it. I like it, although i have
to pay for the license. At least it helps me getting
my XSCHEMA's generated in no time.


 My personal SAXESS story ...
 
 SAXESS stands for System AXESS, just to get this clear;-)
 I write this down, mainly because i got very very satisfied
 with this especially when i compare this to what i was used
 to in former times when open source was something, nobody
 ever heard of...

 I'm running my webserver on some linux box and my webapps
 on solaris driven by tomcat. All of my code is dropped
 into a company wide  multiplatform SCM system. I'm developing
 with the eclipse 

Re: A note about the best(?) (cocoon-) development environment ...

[Robert Simmons]

I use JBoss but not jetty. Are you saying the Jetty-JBoss combo is superior
to the Tomcat-JBoss combo? If so, I will definitely go try it. Perhaps it
will fix my classpath in XSP issue. Bugzilla Reference:
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16580.

Kodo JDO is an implementation of the JDO specification and MORE. It basically
rules. Go through the tutorials and you will love it. Create an object model
using your favorite problem domain. Then create the JDO mapping file (raw XML
or with IDE plug-in) and then just say uhh, make a schema for me and it
just does it. Its amazing! No more screwing around with persistence and
schema manipulation.

I have the commercial version of that product and will be talking about using
it in the book that I am writing.

-- Robert



- Original Message -
From: Thor Heinrichs-Wolpert [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Saturday, February 08, 2003 9:47 PM
Subject: Re: A note about the best(?) (cocoon-) development environment ...


Robert:

Have a look at Jetty, or JBoss/Jetty (aka JBossWeb).  No nasty must
copy things to endorsed directories, etc.).  You take Cocoon (2.0/2.1)
and drop it in your deploy directory and POOF it's there.  It's nice
when the servlet engine actually uses the libs you define and not its
own first as the default ... isn't that in the spec ... and will be
available in Tomcat at some point.

If you want any extra libs in cocoon-2.1 you add them in the lib tree,
add them to jars.xml and the cocoon build adds them to the Manifest ...
Jetty/Jboss just eats 'em up in the right place.

I'm off to look for Kudo JDO (which hopefully follows the ODMG JDO and
not Sun's) ... how does this rank against Castor or Jakarta-OJB ?

Cheers,
Thor HW

On Saturday, February 8, 2003, at 11:42  AM, Robert Simmons wrote:

 Hy, all;

 During the last months of activities i learned a lot from this mailing
 list. while i followed the discussions i started getting my
 development
 environment a bit up to date.  I plan to setup a Wiki page on this
 theme. Although this may be a bit off topic, it still would be great,
 if someone could comment on this issue.


 the tools collection
 
 Here is what i have put together so far. Of course this is driven
 at least partially by what i do for my customers...

 free tools:
 1.) OS: linux and solaris (maybe a mater of taste)

 Go linux. Instead of spending money on licenses, you spend money on
 support
 contracts. Cheaper. In addition, Solaris is primitive compared to
 Linux.

 2.) apache 1.3.26 (mod_jk2, mod_SSL)

 Duh ;)

 3.) tomcat 4.1.18

 Yes, but you can go one step further. Get JBoss with integrated
 tomcat. JBoss
 will handle all sorty of nasty things like deploying to clusters for
 you. As
 a bonus, you get the ability to integrate with EJB based programs.

 4.) cocoon-2.0.4

 2.1 Hopefully soon!

 5.) eclipse

 See my previous message about eclopse vs netbeans.

 6.) sunbow eclipse tools (xml/sitemap)

 URL ?

 7.) ant

 I have 15 million of them in my damn appartment, want a few? Oh ...
 you mean
 Jakarta ant? Ok, nevermind then. =) Im currently looking at Krysalis'
 extensions to ant. http://www.krysalis.org/centipede/quickstart.html


 8.) java-1.3.1 (sun JDK on all platforms)

 No no .. 1.4.1!! In 1.4 there are so many COOOL things that I
 couldnt
 live without anymore.

 9.) Secureway LDAP Server (i'll switch to Open LDAP soon)

 Im an LDAP idiot so Ill trust you there.

 Tools you didnt talk  about:

 CVS - Use it over clearcase. its powerful, free, and a pleasure to use.
 BugZilla - Great program! Lousy looking interface. We should start
 a
 project to port
 it to cocoon. =) However bugzilla is a great and free
 bugtracking system.

 commercial tools:
 10.) clearcase cms (see below)

 Garbage.

 11.) xml-spy

 Good but confusing.

 12.) several DB-Systems

 all you need is Mysql baby.

 Ones you didnt talk about:

 13) Together control center. If you can afford it, it absolutely kills
 any
 other IDE on the planet.
 14) eXcelon Stylus Studio. A great XML editor. It has a bonus of being
 easy
 to use and allot less confusing than XML Spy.
 15) User editors for creating static content. (FrameMaker? OpenOffice?
 Im
 still working on this one)
 16) Kodo JDO. Dont leave home without it. All that nasty persistence
 stuff
 just goes POOOF.


 notes about the collection
 --

 * All tools mentioned above fit tightly together.
I use apache/tomcat since about three years now.
The above combination also works fine with SSL.

 * After i got eclipse setup in tomcat debugging mode,
i could at least double my productivity.
Thanks to the tomcat site it was a matter of seconds to
get it up see:

 http://jakarta.apache.org/site/idedev-rdtomcat.html

 * I also managed to setup eclipse with Cocoon in less than 10
minutes. OK, i did a lousy trick, but for debugging and
learning how cocoon internals  work it's

Re: A note about the best(?) (cocoon-) development environment ...

[Robert Simmons]

Sun JDO JSR-12.


- Original Message -
From: Thor Heinrichs-Wolpert [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Saturday, February 08, 2003 10:22 PM
Subject: Re: A note about the best(?) (cocoon-) development environment ...


Which JDO?  The ODMG JDO (like what Castor uses) or the after class
generation muck about that is in the Sun JDO?

Jetty has been using JMX long before Tomcat, it fully supports the spec
... and I'm thinking it supports it before the reference implementation
does (like the classpath stuff).  Is it superior, I can't say for sure
(but it is the default / preferred servlet engine in JBoss.  I like it
because it takes me less screwing around with jar clashes between
applications and what the server itself uses (making me less dependent
on their support cycle and changes in where the JDK wants things).

Cheers,
Thor HW

On Saturday, February 8, 2003, at 01:05  PM, Robert Simmons wrote:

 I use JBoss but not jetty. Are you saying the Jetty-JBoss combo is
 superior
 to the Tomcat-JBoss combo? If so, I will definitely go try it. Perhaps
 it
 will fix my classpath in XSP issue. Bugzilla Reference:
 http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16580.

 Kodo JDO is an implementation of the JDO specification and MORE. It
 basically
 rules. Go through the tutorials and you will love it. Create an object
 model
 using your favorite problem domain. Then create the JDO mapping file
 (raw XML
 or with IDE plug-in) and then just say uhh, make a schema for me and
 it
 just does it. Its amazing! No more screwing around with persistence and
 schema manipulation.

 I have the commercial version of that product and will be talking
 about using
 it in the book that I am writing.

 -- Robert



 - Original Message -
 From: Thor Heinrichs-Wolpert [EMAIL PROTECTED]
 To: [EMAIL PROTECTED]
 Sent: Saturday, February 08, 2003 9:47 PM
 Subject: Re: A note about the best(?) (cocoon-) development
 environment ...


 Robert:

 Have a look at Jetty, or JBoss/Jetty (aka JBossWeb).  No nasty must
 copy things to endorsed directories, etc.).  You take Cocoon (2.0/2.1)
 and drop it in your deploy directory and POOF it's there.  It's nice
 when the servlet engine actually uses the libs you define and not its
 own first as the default ... isn't that in the spec ... and will be
 available in Tomcat at some point.

 If you want any extra libs in cocoon-2.1 you add them in the lib tree,
 add them to jars.xml and the cocoon build adds them to the Manifest ...
 Jetty/Jboss just eats 'em up in the right place.

 I'm off to look for Kudo JDO (which hopefully follows the ODMG JDO and
 not Sun's) ... how does this rank against Castor or Jakarta-OJB ?

 Cheers,
 Thor HW

 On Saturday, February 8, 2003, at 11:42  AM, Robert Simmons wrote:

 Hy, all;

 During the last months of activities i learned a lot from this
 mailing
 list. while i followed the discussions i started getting my
 development
 environment a bit up to date.  I plan to setup a Wiki page on this
 theme. Although this may be a bit off topic, it still would be great,
 if someone could comment on this issue.


 the tools collection
 
 Here is what i have put together so far. Of course this is driven
 at least partially by what i do for my customers...

 free tools:
 1.) OS: linux and solaris (maybe a mater of taste)

 Go linux. Instead of spending money on licenses, you spend money on
 support
 contracts. Cheaper. In addition, Solaris is primitive compared to
 Linux.

 2.) apache 1.3.26 (mod_jk2, mod_SSL)

 Duh ;)

 3.) tomcat 4.1.18

 Yes, but you can go one step further. Get JBoss with integrated
 tomcat. JBoss
 will handle all sorty of nasty things like deploying to clusters for
 you. As
 a bonus, you get the ability to integrate with EJB based programs.

 4.) cocoon-2.0.4

 2.1 Hopefully soon!

 5.) eclipse

 See my previous message about eclopse vs netbeans.

 6.) sunbow eclipse tools (xml/sitemap)

 URL ?

 7.) ant

 I have 15 million of them in my damn appartment, want a few? Oh ...
 you mean
 Jakarta ant? Ok, nevermind then. =) Im currently looking at Krysalis'
 extensions to ant. http://www.krysalis.org/centipede/quickstart.html


 8.) java-1.3.1 (sun JDK on all platforms)

 No no .. 1.4.1!! In 1.4 there are so many COOOL things that I
 couldnt
 live without anymore.

 9.) Secureway LDAP Server (i'll switch to Open LDAP soon)

 Im an LDAP idiot so Ill trust you there.

 Tools you didnt talk  about:

 CVS - Use it over clearcase. its powerful, free, and a pleasure to
 use.
 BugZilla - Great program! Lousy looking interface. We should start
 a
 project to port
 it to cocoon. =) However bugzilla is a great and free
 bugtracking system.

 commercial tools:
 10.) clearcase cms (see below)

 Garbage.

 11.) xml-spy

 Good but confusing.

 12.) several DB-Systems

 all you need is Mysql baby.

 Ones you didnt talk about:

 13) Together control center. If you can afford it, it absolutely kills
 any
 other

Re: Cocoon 2 with jboss-3.0.4_tomcat-4.1.12

[Robert Simmons]

The manifest is located, strangely enough, in the WEB-INF directory of the
latest release version of the war. You will have to use the entries in that
manifest to create your own war. Please look at the -m option to the jar
command or, better yet, the ant jar task.

-- Robert


 Hello!
 thx for your reply. can you post an example manifest file? and where do
 i have to put the manifest file? into the cocoon war file or into the
 ear file ?
 thx, Chris
 On Tue, Feb 04, 2003 at 11:28:06AM +0100, [EMAIL PROTECTED] wrote:

 The problem is that you need the manifest file that has the Cocoon-Libs
entry and the other entries for the Jars in the cocoon.war. If oyu dont build
using this manifest than cocoon will not be able to locate anything. If you
deploy as an exploded war than you will not have this problem.

 - Original Nachricht 
 
  has anybody cocoon 2 with jboss 3/tomcat 4.1 up and running?
 
  i have tried to deploy my c2 application which usually runs on jboss
  2.4.4/tomcat 3.2 (j2sdk1.3) to the newly installed jboss3.0.4/tomcat
  4.1.12 (j2sdk1.4) environment. i have also build an ear file with the c2
  war file and an application.xml descriptor.
 
  in both cases i got the following exception:
 
  type fatal
 
  message Language Exception
 
  description org.apache.cocoon.ProcessingException: Language Exception:
  org.apache.cocoon.components.language.LanguageException: Error compiling

- Original Message -
From: Christian Joelly [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Tuesday, February 04, 2003 12:03 PM
Subject: Re: Cocoon 2 with jboss-3.0.4_tomcat-4.1.12



-
Please check that your question  has not already been answered in the
FAQ before posting. http://xml.apache.org/cocoon/faq/index.html

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail:   [EMAIL PROTECTED]

Re: cocoon struts together

[Robert Simmons]

I dont think that using struts would be useful within an efficient cocoon
site. Cocoon takes another approach to web development that is, in my
opinion, superior to the jsp/struts approach. I do admit that the learnign
curve is high. in fact many on this list can tell you that ive been beatign
up cocoon over that issue a bit. However, I do think that it is worth it in
the end.

-- Robert

- Original Message -
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Monday, February 03, 2003 5:05 PM
Subject: AW: cocoon  struts together


Hi Matthew,

Yes of course ;-) There is some experience with struts allready. With cocoon
not so much. And this question is a study about the possibilities. I think
the synergy of both frameworks can (perhaps) realize very powerful
solutioons.

Juraj



-Ursprüngliche Nachricht-
Von: Matthew Langham [mailto:[EMAIL PROTECTED]]
Gesendet: Montag, 3. Februar 2003 16:58
An: [EMAIL PROTECTED]
Betreff: RE: cocoon  struts together


Hi Juraj,

 like SAP. On this connects a webapplication which should be done
 with with struts. Some areas of this application should be

why are you considering Struts (at all)? I am interested in this as we often
meet this kind of setup/discussion and we try to convince people to go for a
Cocoon-only solution (of course) :-)

Matthew

--
Open Source Group   Cocoon { Consulting, Training, Projects }
=
Matthew Langham, SN AG, Klingenderstrasse 5, D-33100 Paderborn
Tel:+49-5251-1581-30 [EMAIL PROTECTED] - http://www.s-und-n.de
-
Cocoon book:
  http://www.amazon.com/exec/obidos/ASIN/0735712352/needacake-20
Weblogs:
  http://radio.weblogs.com/0103021/
  http://www.oreillynet.com/weblogs/author/1014
=


 -Original Message-
 From: [EMAIL PROTECTED]
 [mailto:[EMAIL PROTECTED]]
 Sent: Monday, February 03, 2003 4:46 PM
 To: [EMAIL PROTECTED]
 Subject: cocoon  struts together


 Hi,

 has someone any experiences with the comosition of struts and cocoon?

 I have a middleware on EJB and JCA which connects to some Systems
 like SAP. On this connects a webapplication which should be done
 with with struts. Some areas of this application should be
 transformed by cocoon in different outputs. My idea was to run
 some views with cocoon. A struts action would connect a pipeline
 from cocoon and passe the file which has to be transformed and visualized.

 Any suggestions or practices?

 Juraj



 -
 Please check that your question  has not already been answered in the
 FAQ before posting. http://xml.apache.org/cocoon/faq/index.html

 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail:   [EMAIL PROTECTED]




-
Please check that your question  has not already been answered in the
FAQ before posting. http://xml.apache.org/cocoon/faq/index.html

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail:   [EMAIL PROTECTED]

-
Please check that your question  has not already been answered in the
FAQ before posting. http://xml.apache.org/cocoon/faq/index.html

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail:   [EMAIL PROTECTED]


-
Please check that your question  has not already been answered in the
FAQ before posting. http://xml.apache.org/cocoon/faq/index.html

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail:   [EMAIL PROTECTED]

Re: Simple example

[Robert Simmons]

Once more ? =)

Its in progress. Right now beginner documentation is a little thin.

-- Robert

- Original Message -
From: Stefan Riegel [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Monday, February 03, 2003 8:41 PM
Subject: Re: Simple example


 Alireza Fattahi wrote:
  Hi,
 
  The currently cocoon web application is very complex. Is there any light
  weight example out there; some thing like blank web application in
struts.
 
  Alireza.
 
  -
  Please check that your question  has not already been answered in the
  FAQ before posting. http://xml.apache.org/cocoon/faq/index.html
 
  To unsubscribe, e-mail: [EMAIL PROTECTED]
  For additional commands, e-mail:   [EMAIL PROTECTED]
 

 Alireza,

 I remember my first steps with cocoon some time ago. I removed step by
 step lines from the sitemap until I reached a minimal hello-world
 application. While removing lines, I did read the comments etc. I was a
 good exercise.

 I did plan doing the same with the cocoon.xconf, but I lost patience.

 Regards
 Stefan


 -
 Please check that your question  has not already been answered in the
 FAQ before posting. http://xml.apache.org/cocoon/faq/index.html

 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail:   [EMAIL PROTECTED]



-
Please check that your question  has not already been answered in the
FAQ before posting. http://xml.apache.org/cocoon/faq/index.html

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail:   [EMAIL PROTECTED]

Re: cocoon struts together

[Robert Simmons]

Actually I'm an EJB specialist and I don't generally work on projects
conducive to web interfaces. The complexity level of the stuff I do is too
high. (Pharmaceutical industry and genetic research). My customers generally
require a higher range of functionality than a web interface can provide.

That being said, I do, however, do some web work which is why I took up the
idea of cocoon. I use the same technique that I use for GUI programming.
Basically a command centric architecture. I hate to say struts is for
amateurs but it kind of is. It has low complexity and thus low
functionality. It also has high cost in terms of content delivery and
maintenance costs. I personally chose to avoid all that and let Java objects
do all the work and let the framework just concentrate on presentation. Enter
cocoon.

My programs consist of allot of specially designed generators that generate
pure data. Then I use XSLT to translate that into the appropriate media. I
also use XSLT to output the forms though I am experimenting with reflexive
techniques that I have used in GUI applications to make generation of forms
be based on reflexive command analysis.

Frameworks like struts mix functionality with presentation, which IMHO is a
very bad thing. Its a high maintenance cost solution with a low development
cost. That is the wrong way around. To be professional you want high
development cost and low maintenance cost. This causes your feature turn
around, post release, to be much faster. Since you are able to react quickly
to the demands of your users, your company or customers win. The guy that
slapped it together with low development costs may make some sales coming out
the door, but will bleed customers as they seek more stable solutions with
faster turn-around time for new features and fault correction.

I guess that is a long way of saying, put all your work into the back end.
Cocoon is perfect for this because you can develop custom generators to
deliver data and let a web designer with a couple weeks of training worry
about the XSLT translation. In the meantime your valuable programmer
resources are implementing new features and stabilizing the product.

Well that's my opinion on the matter.

-- Robert


- Original Message -
From: Antonio Gallardo [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Tuesday, February 04, 2003 11:48 PM
Subject: Re: cocoon  struts together


 Robert Simmons dijo:
  I dont think that using struts would be useful within an efficient
  cocoon site. Cocoon takes another approach to web development that is,
  in my opinion, superior to the jsp/struts approach.

 Thanks for the comment. I was trying to start learning about this stuff.

 As a bean specialist (a book writer) what tools you recommend to manage
 all the beans stuff (creation, changes, etc.)

 Thanks for the comments.

 Antonio Gallardo



 -
 Please check that your question  has not already been answered in the
 FAQ before posting. http://xml.apache.org/cocoon/faq/index.html

 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail:   [EMAIL PROTECTED]



-
Please check that your question  has not already been answered in the
FAQ before posting. http://xml.apache.org/cocoon/faq/index.html

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail:   [EMAIL PROTECTED]

Re: curious problem with new instalation--where are the XML files?

[Robert Simmons]

I'm afraid you are a bit confused.

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 Hello,

 I just installed Cocoon on my system and I have an interesting problem.

 I copied the war package into
 ~/jboss-3.0.4_tomcat-4.1.12/server/default/deploy and restarted the
 server using the script:

No need. Its a servlet. JBoss will do all the deployment for you.

 ~/jboss-3.0.4_tomcat-4.1.12/bin/run.sh. I got
 the welcome page at http://localhost:8080/cocoon/ and  I was very happy.

Happy is good. =)


 I ran through several of the samples and lthey seemed neat. This would
 be great for a personal web site. Anyway, I wanted to do some of the
 exercises so i entered http://localhost:8080/cocoon/mount and got an
 error. I decided to find the mount directory.

What error did you get ? Cocoon doesnt quite work this way. In cocoon you map
a URL to a pipeline, a combination of generator, 0 to n transformers, and a
serializer. So all URLS are blocked unless they are mapped to a pipeline.
Wheras mount may be mapped to a pipeline, that doesnt guarantee that it will
give you a directory view.


 This is where things get interesting. The cocoon directory was not
 under ~/jboss-3.0.4_tomcat-4.1.12/tomcat-4.1.x/webapps

Why should it be? Its in the WAR file you dropped in the deploy directory.
Unpack it and deploy it exploded and you will see what I mean.

 but under
 ~/jboss-3.0.4_tomcat-4.1.12/work/mainengine/localhost . I found some
 files under
 ~/jboss-3.0.4_tomcat-4.1.12/work/mainengine/localhost/cocoon-files/org/
 apache/cocoon/www/jndi_/localhost/cocoon/ but no xml source files

No no, thats just a tomcat work directory. Temporary files there. Cocoon
takes the sitemap and actually generates a java file and compiles it. It does
that stuff in this directory. The only time you should ever have to look here
is if you get some strange exception in a sitemap or XSP page and cant figure
it out from the XML. Then you can go to the work directory and look up the
source. Otherwise forget this directory.


 Where are the xml source files? Why did the war install Cocoon to such
 a weird directory? Is not this a strange problem?

The war isntalled to your deploy directory. Unpack it with the jar command
and you will see all the gory guts of cocoon. You can create a directory
named cocoon.war and unpack the actual war file into this directory. Then you
can move this directory to the deploy directory of JBoss and it will treat it
exactly as if it was a war file. Refer to the JBoss documentation on
deploying exploded archives. It is within this war that you will find what
you are lookign for.


 David Novogrodsky
 http://www.novogrodsky.net
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1.2.1 (Darwin)

-- Derisor


-
Please check that your question  has not already been answered in the
FAQ before posting. http://xml.apache.org/cocoon/faq/index.html

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail:   [EMAIL PROTECTED]

Re: Simple example / XML / XSLT In production

[Robert Simmons]

Comparing JAVA to XML is roughly like comparing a outhouse to a Ferrari. They
are two totally different things that are made to solve totally different
problems.

-- Robert

- Original Message -
From: Adrian Boston [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Wednesday, February 05, 2003 1:18 AM
Subject: RE: Simple example / XML / XSLT In production


Actually, I'm comparing xml to java, not product to product. And that
was not my opinion; I've been sold on xml for some time; however my
experience has been system to system, not webby front-end.

Btw. It seems most people like mopeds.

Adrian Boston


-Original Message-
From: Robert Simmons [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, February 04, 2003 3:59 PM
To: [EMAIL PROTECTED]
Subject: Re: Simple example / XML / XSLT In production

Huh? JSP has no object hierarchy. JSP is basically a way to write a
servlet
without having to implement the servlet interfaces. In short it is a
shortcut. The end result of JSP is always a servlet (one per JSP page).
XML/XSLT is a totally different paradigm.

In cocoon generators are used to deliver DATA. This data is in XML form.
There is no logic mixed into this data as is the case with JSP. Then The
XML
data is transformed (very mathematically) into content. This content can
be
HTML, another XML document such as a soap request, WML, PDF and so on.

So, as a matter of fact JSP mixes not only model and view but also model
view
AND controller. In the cocoon world the Generators and actions are
controllers. The XML is the model and the view is accomplished through
XSLT
transforms. Its the same for XSP. In this case an XSP is translated
into, not
a servlet like JSP, but a generator. So even though you write an XSP to
implement some functionality, this XSP is still going to be spitting out
XML
which must be transformed into content.

Comparing the two is like comparing a moped to a Ferrari. The cocoon way
is
CLEARLY superior for any number of project planning, resource management
and
software engineering reasons.

-- Derisor

- Original Message -
From: Adrian Boston [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Wednesday, February 05, 2003 12:45 AM
Subject: RE: Simple example / XML / XSLT In production



Ah, thanks for the linx.

I was debating xml, xslt versus jsp with a colleague. He noted that
although xml, xslt works well in a divided graphics/analyst/developer
big team, it eventually was scrapped for JSP. The lack of object
hierarchy and polymorphism made changes very difficult.
Can anyone provide tales of xml, xslt in a major production? (sans
company name, of course)

Thanks,

-Original Message-
From: Yves Vindevogel [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, February 04, 2003 3:31 PM
To: [EMAIL PROTECTED]
Subject: Re: Simple example

Jeremy Ashton, who recently published a book on Cocoon, wrote a very
good two
idots guide to Cocoon.  This document is still online somewhere.  I
guess
Jeremy can point it out, he's a frequent reader of this user-list.
That document gave me a lot of support and help, back in the days

 Re: Hopefully some encouragement

 An introductory document would prove extremely useful for the Cocoon
 cause, as it sounds great in both concept and implementation. Some of
us
 are in positions to recommend xml, xslt over the forsaken jsp, struts,
 ejb method, but cannot afford the time to master yet another complex
 st*nking framework.


 -Original Message-
 From: Robert Simmons [mailto:[EMAIL PROTECTED]]
 Sent: Tuesday, February 04, 2003 2:10 PM
 To: [EMAIL PROTECTED]
 Subject: Re: Simple example

 Once more ? =)

 Its in progress. Right now beginner documentation is a little thin.

 -- Robert

 - Original Message -
 From: Stefan Riegel [EMAIL PROTECTED]
 To: [EMAIL PROTECTED]
 Sent: Monday, February 03, 2003 8:41 PM
 Subject: Re: Simple example

  Alireza Fattahi wrote:
   Hi,
  
   The currently cocoon web application is very complex. Is there any

 light

   weight example out there; some thing like blank web application in

 struts.

   Alireza.

 -

   Please check that your question  has not already been answered in

 the

   FAQ before posting.

 http://xml.apache.org/cocoon/faq/index.html

   To unsubscribe, e-mail:

 [EMAIL PROTECTED]

   For additional commands, e-mail:

 [EMAIL PROTECTED]

  Alireza,
 
  I remember my first steps with cocoon some time ago. I removed step
by
  step lines from the sitemap until I reached a minimal hello-world
  application. While removing lines, I did read the comments etc. I
was

 a

  good exercise.
 
  I did plan doing the same with the cocoon.xconf, but I lost
patience.
 
  Regards
  Stefan
 
 
 
-
  Please check that your question  has not already been answered in
the
  FAQ before posting.
http://xml.apache.org/cocoon/faq/index.html
 
  To unsubscribe, e-mail:
[EMAIL PROTECTED

Re: Simple example / XML / XSLT In production

[Robert Simmons]

you can have the 100k Porsche, Ill take the half a million dollar Ferrari.

I have been doing XSL for quite a while. I'm relatively new to cocoon, not to
XML. People that use XML for logic and programming need to have their head
examined IMHO.

-- Robert

- Original Message -
From: Adrian Boston [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Wednesday, February 05, 2003 1:34 AM
Subject: RE: Simple example / XML / XSLT In production



Oh. OK. We shall see when you start programming in xml, xslt, xpath,
xthis, xthat.

Unless you're well endowed with a bushy moustache and still love disco,
I'd recommend stay away from Ferrari's. Move on up to a Porsche.


-Original Message-
From: Robert Simmons [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, February 04, 2003 4:27 PM
To: [EMAIL PROTECTED]
Subject: Re: Simple example / XML / XSLT In production

Comparing JAVA to XML is roughly like comparing a outhouse to a Ferrari.
They
are two totally different things that are made to solve totally
different
problems.

-- Robert

- Original Message -
From: Adrian Boston [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Wednesday, February 05, 2003 1:18 AM
Subject: RE: Simple example / XML / XSLT In production


Actually, I'm comparing xml to java, not product to product. And that
was not my opinion; I've been sold on xml for some time; however my
experience has been system to system, not webby front-end.

Btw. It seems most people like mopeds.

Adrian Boston


-Original Message-
From: Robert Simmons [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, February 04, 2003 3:59 PM
To: [EMAIL PROTECTED]
Subject: Re: Simple example / XML / XSLT In production

Huh? JSP has no object hierarchy. JSP is basically a way to write a
servlet
without having to implement the servlet interfaces. In short it is a
shortcut. The end result of JSP is always a servlet (one per JSP page).
XML/XSLT is a totally different paradigm.

In cocoon generators are used to deliver DATA. This data is in XML form.
There is no logic mixed into this data as is the case with JSP. Then The
XML
data is transformed (very mathematically) into content. This content can
be
HTML, another XML document such as a soap request, WML, PDF and so on.

So, as a matter of fact JSP mixes not only model and view but also model
view
AND controller. In the cocoon world the Generators and actions are
controllers. The XML is the model and the view is accomplished through
XSLT
transforms. Its the same for XSP. In this case an XSP is translated
into, not
a servlet like JSP, but a generator. So even though you write an XSP to
implement some functionality, this XSP is still going to be spitting out
XML
which must be transformed into content.

Comparing the two is like comparing a moped to a Ferrari. The cocoon way
is
CLEARLY superior for any number of project planning, resource management
and
software engineering reasons.

-- Derisor

- Original Message -
From: Adrian Boston [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Wednesday, February 05, 2003 12:45 AM
Subject: RE: Simple example / XML / XSLT In production



Ah, thanks for the linx.

I was debating xml, xslt versus jsp with a colleague. He noted that
although xml, xslt works well in a divided graphics/analyst/developer
big team, it eventually was scrapped for JSP. The lack of object
hierarchy and polymorphism made changes very difficult.
Can anyone provide tales of xml, xslt in a major production? (sans
company name, of course)

Thanks,

-Original Message-
From: Yves Vindevogel [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, February 04, 2003 3:31 PM
To: [EMAIL PROTECTED]
Subject: Re: Simple example

Jeremy Ashton, who recently published a book on Cocoon, wrote a very
good two
idots guide to Cocoon.  This document is still online somewhere.  I
guess
Jeremy can point it out, he's a frequent reader of this user-list.
That document gave me a lot of support and help, back in the days

 Re: Hopefully some encouragement

 An introductory document would prove extremely useful for the Cocoon
 cause, as it sounds great in both concept and implementation. Some of
us
 are in positions to recommend xml, xslt over the forsaken jsp, struts,
 ejb method, but cannot afford the time to master yet another complex
 st*nking framework.


 -Original Message-
 From: Robert Simmons [mailto:[EMAIL PROTECTED]]
 Sent: Tuesday, February 04, 2003 2:10 PM
 To: [EMAIL PROTECTED]
 Subject: Re: Simple example

 Once more ? =)

 Its in progress. Right now beginner documentation is a little thin.

 -- Robert

 - Original Message -
 From: Stefan Riegel [EMAIL PROTECTED]
 To: [EMAIL PROTECTED]
 Sent: Monday, February 03, 2003 8:41 PM
 Subject: Re: Simple example

  Alireza Fattahi wrote:
   Hi,
  
   The currently cocoon web application is very complex. Is there any

 light

   weight example out there; some thing like blank web application in

 struts.

   Alireza

Re: [OT] RE: cocoon struts together

[Robert Simmons]

Struts is a horrible basis for business logic for a thousand reasons.
Business logic best lives within an enterprise container and an application
server. The basis of concurrency, fault tolerance, transaction management,
clustering and the rest of the EJB contract make it pretty psycho to NOT use
it. I would NEVER EVER do anything important in any web framework, be it
cocoon or struts. No thanks the J2EE environment is the god of business logic
as cocoon is, IMHO, the god of web presentation. Cocoon should be a CONSUMER
of the J2EE functionality and not make any decisions whatsoever.

Many people whip up some struts-JSP based applications, which basically
become servlets, and then pretend that the problems are solved. I could list
a thousand ways this paradigm is garbage, but I really don't have to because
other books do it quite well for me.

My advice to you is to use EJB and J2EE on the back end, cocoon on the web
end, JDO for persistence and Swing for complex clients.

-- Robert

- Original Message -
From: Todd Pierce [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Wednesday, February 05, 2003 1:36 AM
Subject: [OT] RE: cocoon  struts together


 Re the comment Frameworks like struts mix functionality with
 presentation

 The presumption that functionality and presentation are mixed in Struts
 needs qualification. Struts is an application framework. It's most valuable
 component is the application layer. The presentation layer don't have to be
 JSP/taglib. You can serve out xml for presentation if you wish, or
(shudder)
 even Flash.

 Reasonable separation of functionality and presentation can be achieved
 using any framework, if you follow 2 simple rules: Rule 1 - ensure that the
 application layer does not generate any presentation. Rule 2 - ensure that
 the presentation layer does not make any decisions. I use a tiles-based
 template system, with screens defined in an XML doc, but y'know, what-ever.

 I'm not trying to sell Struts to hardened Cocoon users. I use both Cocoon
 and Struts, but not together. Cocoon for data delivery systems, because of
 its fantastic separation of content and presentation, and Struts for
 business applications simply because it's such a good application
framework.
 I don't believe either of these technologies should be considered to be a
 panacaea for the ills of the web world.

 -Original Message-
 From: Robert Simmons [mailto:[EMAIL PROTECTED]]
 Sent: Wednesday, 5 February 2003 10:43 AM
 To: [EMAIL PROTECTED]
 Subject: Re: cocoon  struts together


 Actually I'm an EJB specialist and I don't generally work on projects
 conducive to web interfaces. The complexity level of the stuff I do is too
 high. (Pharmaceutical industry and genetic research). My customers
generally
 require a higher range of functionality than a web interface can provide.

 That being said, I do, however, do some web work which is why I took up the
 idea of cocoon. I use the same technique that I use for GUI programming.
 Basically a command centric architecture. I hate to say struts is for
 amateurs but it kind of is. It has low complexity and thus low
 functionality. It also has high cost in terms of content delivery and
 maintenance costs. I personally chose to avoid all that and let Java
objects
 do all the work and let the framework just concentrate on presentation.
 Enter
 cocoon.

 My programs consist of allot of specially designed generators that generate
 pure data. Then I use XSLT to translate that into the appropriate media. I
 also use XSLT to output the forms though I am experimenting with reflexive
 techniques that I have used in GUI applications to make generation of forms
 be based on reflexive command analysis.

 Frameworks like struts mix functionality with presentation, which IMHO is a
 very bad thing. Its a high maintenance cost solution with a low development
 cost. That is the wrong way around. To be professional you want high
 development cost and low maintenance cost. This causes your feature turn
 around, post release, to be much faster. Since you are able to react
quickly
 to the demands of your users, your company or customers win. The guy that
 slapped it together with low development costs may make some sales coming
 out
 the door, but will bleed customers as they seek more stable solutions with
 faster turn-around time for new features and fault correction.

 I guess that is a long way of saying, put all your work into the back
end.
 Cocoon is perfect for this because you can develop custom generators to
 deliver data and let a web designer with a couple weeks of training worry
 about the XSLT translation. In the meantime your valuable programmer
 resources are implementing new features and stabilizing the product.

 Well that's my opinion on the matter.

 -- Robert


 - Original Message -
 From: Antonio Gallardo [EMAIL PROTECTED]
 To: [EMAIL PROTECTED]
 Sent: Tuesday, February 04, 2003 11:48 PM
 Subject: Re: cocoon  struts together

Re: cocoon struts together

[Robert Simmons]

It was a painful road and I'm still nursing the bruises. But ya, I see its
value.

-- Robert

- Original Message -
From: Antonio Gallardo [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Wednesday, February 05, 2003 1:55 AM
Subject: Re: cocoon  struts together


 Thanks for the answer. Good speach. I saw you now as a Cocoon fan! :-)
 You finally saw the light at the end of the pipeline. ;-)

 Best Regards,

 Antonio Gallardo.



 Robert Simmons dijo:
  Actually I'm an EJB specialist and I don't generally work on projects
  conducive to web interfaces. The complexity level of the stuff I do is
  too high. (Pharmaceutical industry and genetic research). My customers
  generally require a higher range of functionality than a web interface
  can provide.
 
  That being said, I do, however, do some web work which is why I took up
  the idea of cocoon. I use the same technique that I use for GUI
  programming. Basically a command centric architecture. I hate to say
  struts is for amateurs but it kind of is. It has low complexity and
  thus low
  functionality. It also has high cost in terms of content delivery and
  maintenance costs. I personally chose to avoid all that and let Java
  objects do all the work and let the framework just concentrate on
  presentation. Enter cocoon.
 
  My programs consist of allot of specially designed generators that
  generate pure data. Then I use XSLT to translate that into the
  appropriate media. I also use XSLT to output the forms though I am
  experimenting with reflexive techniques that I have used in GUI
  applications to make generation of forms be based on reflexive command
  analysis.
 
  Frameworks like struts mix functionality with presentation, which IMHO
  is a very bad thing. Its a high maintenance cost solution with a low
  development cost. That is the wrong way around. To be professional you
  want high development cost and low maintenance cost. This causes your
  feature turn around, post release, to be much faster. Since you are able
  to react quickly to the demands of your users, your company or customers
  win. The guy that slapped it together with low development costs may
  make some sales coming out the door, but will bleed customers as they
  seek more stable solutions with faster turn-around time for new features
  and fault correction.
 
  I guess that is a long way of saying, put all your work into the back
  end. Cocoon is perfect for this because you can develop custom
  generators to deliver data and let a web designer with a couple weeks of
  training worry about the XSLT translation. In the meantime your valuable
  programmer resources are implementing new features and stabilizing the
  product.
 
  Well that's my opinion on the matter.
 
  -- Robert
 
 
  - Original Message -
  From: Antonio Gallardo [EMAIL PROTECTED]
  To: [EMAIL PROTECTED]
  Sent: Tuesday, February 04, 2003 11:48 PM
  Subject: Re: cocoon  struts together
 
 
  Robert Simmons dijo:
   I dont think that using struts would be useful within an efficient
  cocoon site. Cocoon takes another approach to web development that
  is, in my opinion, superior to the jsp/struts approach.
 
  Thanks for the comment. I was trying to start learning about this
  stuff.
 
  As a bean specialist (a book writer) what tools you recommend to
  manage all the beans stuff (creation, changes, etc.)
 
  Thanks for the comments.
 
  Antonio Gallardo
 
 
 
  -
  Please check that your question  has not already been answered in the
  FAQ before posting. http://xml.apache.org/cocoon/faq/index.html
 
  To unsubscribe, e-mail: [EMAIL PROTECTED]
  For additional commands, e-mail:   [EMAIL PROTECTED]
 
 
 
  -
  Please check that your question  has not already been answered in the
  FAQ before posting. http://xml.apache.org/cocoon/faq/index.html
 
  To unsubscribe, e-mail: [EMAIL PROTECTED]
  For additional commands, e-mail:   [EMAIL PROTECTED]




 -
 Please check that your question  has not already been answered in the
 FAQ before posting. http://xml.apache.org/cocoon/faq/index.html

 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail:   [EMAIL PROTECTED]



-
Please check that your question  has not already been answered in the
FAQ before posting. http://xml.apache.org/cocoon/faq/index.html

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail:   [EMAIL PROTECTED]

Re: Simple example / XML / XSLT In production

[Robert Simmons]

What exactly does this attitude serve. If you don't want people's opinion,
don't post to a public mailing list. Enough of this topic, its quite clear
that you value your sarcasm over honest answers.

-- Robert

- Original Message -
From: Adrian Boston [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Wednesday, February 05, 2003 2:12 AM
Subject: RE: Simple example / XML / XSLT In production


Greaaat. Thanks for saving me a couple of weeks work. I'll make a note
in my documents, Robert said XML was OK.
It's fine to hold you responsible right?

Once again, as carefully noted in my first post:
a) not my opinion.
b) xml is cool.

If you want to comment on your xml success in your production systems,
great, otherwise, drsvp.



-Original Message-
From: Robert Simmons [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, February 04, 2003 4:44 PM
To: [EMAIL PROTECTED]
Subject: Re: Simple example / XML / XSLT In production

you can have the 100k Porsche, Ill take the half a million dollar
Ferrari.

I have been doing XSL for quite a while. I'm relatively new to cocoon,
not to
XML. People that use XML for logic and programming need to have their
head
examined IMHO.

-- Robert

- Original Message -
From: Adrian Boston [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Wednesday, February 05, 2003 1:34 AM
Subject: RE: Simple example / XML / XSLT In production



Oh. OK. We shall see when you start programming in xml, xslt, xpath,
xthis, xthat.

Unless you're well endowed with a bushy moustache and still love disco,
I'd recommend stay away from Ferrari's. Move on up to a Porsche.


-Original Message-
From: Robert Simmons [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, February 04, 2003 4:27 PM
To: [EMAIL PROTECTED]
Subject: Re: Simple example / XML / XSLT In production

Comparing JAVA to XML is roughly like comparing a outhouse to a Ferrari.
They
are two totally different things that are made to solve totally
different
problems.

-- Robert

- Original Message -
From: Adrian Boston [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Wednesday, February 05, 2003 1:18 AM
Subject: RE: Simple example / XML / XSLT In production


Actually, I'm comparing xml to java, not product to product. And that
was not my opinion; I've been sold on xml for some time; however my
experience has been system to system, not webby front-end.

Btw. It seems most people like mopeds.

Adrian Boston


-Original Message-
From: Robert Simmons [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, February 04, 2003 3:59 PM
To: [EMAIL PROTECTED]
Subject: Re: Simple example / XML / XSLT In production

Huh? JSP has no object hierarchy. JSP is basically a way to write a
servlet
without having to implement the servlet interfaces. In short it is a
shortcut. The end result of JSP is always a servlet (one per JSP page).
XML/XSLT is a totally different paradigm.

In cocoon generators are used to deliver DATA. This data is in XML form.
There is no logic mixed into this data as is the case with JSP. Then The
XML
data is transformed (very mathematically) into content. This content can
be
HTML, another XML document such as a soap request, WML, PDF and so on.

So, as a matter of fact JSP mixes not only model and view but also model
view
AND controller. In the cocoon world the Generators and actions are
controllers. The XML is the model and the view is accomplished through
XSLT
transforms. Its the same for XSP. In this case an XSP is translated
into, not
a servlet like JSP, but a generator. So even though you write an XSP to
implement some functionality, this XSP is still going to be spitting out
XML
which must be transformed into content.

Comparing the two is like comparing a moped to a Ferrari. The cocoon way
is
CLEARLY superior for any number of project planning, resource management
and
software engineering reasons.

-- Derisor

- Original Message -
From: Adrian Boston [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Wednesday, February 05, 2003 12:45 AM
Subject: RE: Simple example / XML / XSLT In production



Ah, thanks for the linx.

I was debating xml, xslt versus jsp with a colleague. He noted that
although xml, xslt works well in a divided graphics/analyst/developer
big team, it eventually was scrapped for JSP. The lack of object
hierarchy and polymorphism made changes very difficult.
Can anyone provide tales of xml, xslt in a major production? (sans
company name, of course)

Thanks,

-Original Message-
From: Yves Vindevogel [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, February 04, 2003 3:31 PM
To: [EMAIL PROTECTED]
Subject: Re: Simple example

Jeremy Ashton, who recently published a book on Cocoon, wrote a very
good two
idots guide to Cocoon.  This document is still online somewhere.  I
guess
Jeremy can point it out, he's a frequent reader of this user-list.
That document gave me a lot of support and help, back in the days

 Re: Hopefully some encouragement

 An introductory document would prove extremely useful for the Cocoon
 cause

Re: [OT] RE: cocoon struts together

[Robert Simmons]

Don't be so defensive. You cant infer anything that I didn't say. I have no
clue what you personally do. I merely commented on what I have seen others do
in some 7 years of professional consulting.

I don't advocate BMP because it doesn't take advantage of lazy loading. Its
an all or nothing approach. You either load the entire object or none of it.
If this object is a purchase order then it probably isn't a big deal. If its
a genetic research mouse that has over 300 properties including 90 sets, lazy
loading becomes IMPERATIVE. 99% of the time I just need 4 or 5 of those
attributes. Loading them all would be a waste of resources and slow things
down dramatically. JDO caching paradigm is heavily based on lazy loading.

--Robert

- Original Message -
From: Todd Pierce [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Wednesday, February 05, 2003 2:39 AM
Subject: RE: [OT] RE: cocoon  struts together


 Interesting set of inferences ; P

 Many people whip up some struts-JSP based applications, which basically
 become servlets, and then pretend that the problems are solved. I could
list
 a thousand ways this paradigm is garbage... - So that's what I do?

 Struts is a horrible basis for business logic for a thousand reasons. -
 Where did I say I use Struts for business logic?
 My advice to you is to use EJB and J2EE on the back end - Right on, baby
 Cocoon on the web - Hmm
 JDO for persistence  - BMP

 We use Struts for controlling requests, on web-tier, application layer. We
 use templated JSPs for presentation, web-tier, presentation layer. You can
 use Cocoon for this if you like, but I think cocoon's strength is
publishing
 data.

 -Original Message-
 From: Robert Simmons [mailto:[EMAIL PROTECTED]]
 Sent: Wednesday, 5 February 2003 11:49 AM
 To: [EMAIL PROTECTED]
 Subject: Re: [OT] RE: cocoon  struts together


 Struts is a horrible basis for business logic for a thousand reasons.
 Business logic best lives within an enterprise container and an application
 server. The basis of concurrency, fault tolerance, transaction management,
 clustering and the rest of the EJB contract make it pretty psycho to NOT
use
 it. I would NEVER EVER do anything important in any web framework, be it
 cocoon or struts. No thanks the J2EE environment is the god of business
 logic
 as cocoon is, IMHO, the god of web presentation. Cocoon should be a
CONSUMER
 of the J2EE functionality and not make any decisions whatsoever.

 Many people whip up some struts-JSP based applications, which basically
 become servlets, and then pretend that the problems are solved. I could
list
 a thousand ways this paradigm is garbage, but I really don't have to
because
 other books do it quite well for me.

 My advice to you is to use EJB and J2EE on the back end, cocoon on the web
 end, JDO for persistence and Swing for complex clients.

 -- Robert

 - Original Message -
 From: Todd Pierce [EMAIL PROTECTED]
 To: [EMAIL PROTECTED]
 Sent: Wednesday, February 05, 2003 1:36 AM
 Subject: [OT] RE: cocoon  struts together


  Re the comment Frameworks like struts mix functionality with
  presentation
 
  The presumption that functionality and presentation are mixed in Struts
  needs qualification. Struts is an application framework. It's most
 valuable
  component is the application layer. The presentation layer don't have to
 be
  JSP/taglib. You can serve out xml for presentation if you wish, or
 (shudder)
  even Flash.
 
  Reasonable separation of functionality and presentation can be achieved
  using any framework, if you follow 2 simple rules: Rule 1 - ensure that
 the
  application layer does not generate any presentation. Rule 2 - ensure
that
  the presentation layer does not make any decisions. I use a tiles-based
  template system, with screens defined in an XML doc, but y'know,
 what-ever.
 
  I'm not trying to sell Struts to hardened Cocoon users. I use both Cocoon
  and Struts, but not together. Cocoon for data delivery systems, because
of
  its fantastic separation of content and presentation, and Struts for
  business applications simply because it's such a good application
 framework.
  I don't believe either of these technologies should be considered to be a
  panacaea for the ills of the web world.
 
  -Original Message-
  From: Robert Simmons [mailto:[EMAIL PROTECTED]]
  Sent: Wednesday, 5 February 2003 10:43 AM
  To: [EMAIL PROTECTED]
  Subject: Re: cocoon  struts together
 
 
  Actually I'm an EJB specialist and I don't generally work on projects
  conducive to web interfaces. The complexity level of the stuff I do is
too
  high. (Pharmaceutical industry and genetic research). My customers
 generally
  require a higher range of functionality than a web interface can provide.
 
  That being said, I do, however, do some web work which is why I took up
 the
  idea of cocoon. I use the same technique that I use for GUI programming.
  Basically a command centric architecture. I hate to say struts

Re: [OT] RE: cocoon struts together

[Robert Simmons]

I dislike CMP for a number of reasons. Not the least of which is that it is a
sledgehammer solution to put a thumbtack in a wall. The other reasons run a
wide spectrum and include things like lack of dynamic searches, inability to
convert objects to transient state and then back to persistent, the primary
key mechanism, having no access to the property methods and therefore not
being able to perform data validation and on and on. IMHO CMP = total
garbage. Its the one part of J2EE that is so poorly conceived that it should
just be torn out completely.

-- Robert


- Original Message -
From: Ryan Hoegg [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Wednesday, February 05, 2003 2:37 AM
Subject: Re: [OT] RE: cocoon  struts together


 Robert Simmons wrote:

 My advice to you is to use EJB and J2EE on the back end, cocoon on the web
 end, JDO for persistence and Swing for complex clients.
 
 -- Robert
 
 After your previous comments I'm surprised you aren't pushing CMP 2 over
 JDO.

 --
 Ryan Hoegg
 ISIS Networks
 http://www.isisnetworks.net

 
 


 -
 Please check that your question  has not already been answered in the
 FAQ before posting. http://xml.apache.org/cocoon/faq/index.html

 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail:   [EMAIL PROTECTED]



-
Please check that your question  has not already been answered in the
FAQ before posting. http://xml.apache.org/cocoon/faq/index.html

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail:   [EMAIL PROTECTED]

To the Columbia and her crew.

[Robert Simmons]

Words cannot express the sorrow we feel at the loss 
of the Columbia. As scientists ourselves, we feel a kinship to those that died 
200,000 feet above the state of Texas. We should all take a moment to say 
farewell and then to push on with science and exploration so that their deaths 
were not in vain. As we mourn their loss, we should also remember that they all 
died living their childhood dream. It should be some solace that they all 
realized the pinnacle of their aspirations before leaving this world. 


To all of the families involved, words cannot 
express the sorrow we feel for the loss of their loved ones. We would only ask 
that in your moment of grief, you remember not how they died, but how they 
lived. 

-- Robert Simmons jr. 
-- Senior Software Engineer
-- American Living in Munich, 
Germany

Re: [XML EDITOR] Netbeans

[Robert Simmons]

I use NetBeans. It has a good XML editor built into it but it would do well
to add a WYSIWYG XSLT editor. So you can go write it. =)

-- Robert

- Original Message -
From: Antonio Gallardo [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Sunday, February 02, 2003 2:47 AM
Subject: [XML EDITOR] Netbeans


 Is anyone here using netbeans? more info at: http://www.netbeans.org

 It looks like netbeans has a built-in powerfull XML editor.

 Can someone share his own experience with this?

 Regards,

 Antonio Gallardo



 -
 Please check that your question  has not already been answered in the
 FAQ before posting. http://xml.apache.org/cocoon/faq/index.html

 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail:   [EMAIL PROTECTED]



-
Please check that your question  has not already been answered in the
FAQ before posting. http://xml.apache.org/cocoon/faq/index.html

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail:   [EMAIL PROTECTED]

2.1 ? Release date and stabiltiy?

[Robert Simmons]

I was wondering if there has been a target release 
date set for 2.1. Additionally what experiences have people had with the current 
CVS builds of 2.1 ? Is it stable in core functionality ? 

-- Robert

Sitemap Tag Reference

[Robert Simmons]

Is there a reference manualto the sitemap 
schema and tags ? If you, I would appreciate a link. 

-- Robert

Re: Cocoon Competence Center Updates

[Robert Simmons]

Fine ... I'm beginning to loose interest to be honest. Right now I cant do
anything with XSP with cocoon at all. because of the classpath bug it looks
like two weeks of my work are about to explode in my face. Sigh.

-- Robert

- Original Message -
From: SAXESS - Hussayn Dabbous [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Thursday, January 30, 2003 9:12 AM
Subject: Re: Cocoon Competence Center Updates


 Hy, Robert;

 Thank you very much for the contributions.

 I propose to move parts of your contrib into another page.

 reasons:

 1.) this page deals with deploying cocoon. it should not cover
  essentials of cocoon internals. this is the next story to be
  covered, once cocoon is deployed.

 2.) i want this document to be for beginning beginners, (we used
  to name them nebies ;-). Yes we should prepare a doc, that
  contains your hints and tips, but maybe this is an add on
  page ?

 if nobody complains, i will move your contribs to another page, but
 keep the super esssentials in the doc (and point to the new pages where
 relevant)

 is that ok for you Robert?

 regards, Hussayn

 Robert Simmons wrote:
  Greetings, I have added the following information to the cocoon
  competence center page on installing cocoon. Please feel free to review
  the following sections and smack me around if I said anything incorrect.
  The new sections are.
 
  * Deploying on an application server.
  * What is essential?
 
  -- Robert
 

 --
 Dr. Hussayn Dabbous
 SAXESS Software Design GmbH
 Neuenhöfer Allee 125
 50935 Köln
 Telefon: +49-221-56011-0
 Fax: +49-221-56011-20
 E-Mail:  [EMAIL PROTECTED]


 -
 Please check that your question  has not already been answered in the
 FAQ before posting. http://xml.apache.org/cocoon/faq/index.html

 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail:   [EMAIL PROTECTED]



-
Please check that your question  has not already been answered in the
FAQ before posting. http://xml.apache.org/cocoon/faq/index.html

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail:   [EMAIL PROTECTED]

Re: Cocoon Competence Center Updates

[Robert Simmons]

Is not cocoon's power or anything else that I'm arguing with. There is an
extremely serious bug in cocoon that is causing me to not be able to use it
at all. It is clear that cocoon was developed to be a single solution and to
not integrate with technologies such as application servers. The classloader
issue, http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16580,  would make
it ridiculous for me to do anything in cocoon. If I have to deploy all 100
EJB libs of the company I work for in cocoon as well as in the application
server, than my colleagues would rightly laugh themselves silly. In fact I
cant believe this issue even exists in a product this mature. I am looking at
probably 3 months to get this fixed, minimum, if it is ever fixed. At that
point I will have to wait for a release of the product, as my company would
throw me at the door for putting up a bleeding edge CVS build.

So basically I'm screwed when I comes to my book and when it comes to my
company. Cocoon is pretty much out. I guess I have to throw out 2 weeks of
agonizing work and I dot know how many emails and recode the whole damn thing
in JSP. Lovely.

Well, I suppose it could be worse. I dot see much market for Cocoon
developers anyway.

-- Robert

- Original Message -
From: SAXESS - Hussayn Dabbous [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Thursday, January 30, 2003 9:44 AM
Subject: Re: Cocoon Competence Center Updates


 Hy Robert,

 I appreciate your honesty.
 I hope, you keep with us. I think you can really help
 getting this into the next generation...

 just a few of my experiences if you don't mind ...

 0.) i use to install minimalistic components when
  i start investigating. in this sense i only
  needed tomcat-4.*.* to start. just installed it
  and ready to go...

 1.) When i started working with cocoon i first got
  very very frustrated:
  sitemap not working as i expected
  actions, uhh?
  logicsheets, sounds good, howto???
  and so on ...
  I even did not know, what to ask in detail.

 3.) very slowly i got a first overview. i only scratched
  the surface and one day (after about two weeks) i got
  hit by realizing the hidden mightiness of the beast.
  Hey that's great, this works fine,
   ahh what easy going here and there...
  Until now i still only was playing with the very
  basics (sitemap, generator, protocol handlers)

 4.) After reviewing my first experiences with cocoon i came
  to the conclusions:
  - its very complex
  - it has great oportunities
  - it is complex documented
  - it moves fast
  - it neads quality assurance to get mature

 My decisions:

  - use cocoon in my own projects
  - help cocoon users to get a clear understanding
with less frustrations

 I'm still happy with cocoon and im still only using the very
 basics. I am curious where i can get with XSP and ESQL ;-)

 regards, hussayn


 Robert Simmons wrote:
  Fine ... I'm beginning to loose interest to be honest. Right now I cant
do
  anything with XSP with cocoon at all. because of the classpath bug it
looks
  like two weeks of my work are about to explode in my face. Sigh.
 
  -- Robert
 
  - Original Message -
  From: SAXESS - Hussayn Dabbous [EMAIL PROTECTED]
  To: [EMAIL PROTECTED]
  Sent: Thursday, January 30, 2003 9:12 AM
  Subject: Re: Cocoon Competence Center Updates
 
 
 
 Hy, Robert;
 
 Thank you very much for the contributions.
 
 I propose to move parts of your contrib into another page.
 
 reasons:
 
 1.) this page deals with deploying cocoon. it should not cover
  essentials of cocoon internals. this is the next story to be
  covered, once cocoon is deployed.
 
 2.) i want this document to be for beginning beginners, (we used
  to name them nebies ;-). Yes we should prepare a doc, that
  contains your hints and tips, but maybe this is an add on
  page ?
 
 if nobody complains, i will move your contribs to another page, but
 keep the super esssentials in the doc (and point to the new pages where
 relevant)
 
 is that ok for you Robert?
 
 regards, Hussayn
 
 Robert Simmons wrote:
 
 Greetings, I have added the following information to the cocoon
 competence center page on installing cocoon. Please feel free to review
 the following sections and smack me around if I said anything incorrect.
 The new sections are.
 
 * Deploying on an application server.
 * What is essential?
 
 -- Robert
 
 
 --
 Dr. Hussayn Dabbous
 SAXESS Software Design GmbH
 Neuenhöfer Allee 125
 50935 Köln
 Telefon: +49-221-56011-0
 Fax: +49-221-56011-20
 E-Mail:  [EMAIL PROTECTED]
 
 
 -
 Please check that your question  has not already been answered in the
 FAQ before posting. http://xml.apache.org/cocoon/faq/index.html
 
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail:   [EMAIL PROTECTED

Time to go back to JSP. Cocoon just isnt ready.

[Robert Simmons]

I have reluctantly come to the conclusion that 
cocoon is not ready for professional development. Unlike tomcat, or Ant, this 
product has serious things blocking its use in production systems. I personally 
am completely and utterly stopped by the classpath bug indicated here: http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16580. 
Just another symptom of a product that needs more work to be used in 
professional products. That coupled with the lack of documentation makes the 
package difficult at best. I will possibly be back in a year or so when this 
technology has gone somewhere. This is assuming it is still alive by then. I 
have seen a plethora of new people come on this list and then just vanish. That 
doesn't bode well for its reputation. I don't want to take this step and throw 
away two weeks of work but the fact is that I also don't have time to wait for 
such massive bugs to be fixed and to spend another two weeks swimming through 
poor debugging tools. Its a massive bummer to me but in order to be true to 
myself I cant see alternatives. The fact is that however flawed JSPs are, I can 
crack together JSP pagers 40 times faster than cocoon pages. When it comes to 
deadlines, major bugs like this just stop a product cold. Anyway, Ill stop 
rambling now.

Comments are invited.

-- Robert

Re: Cocoon Competence Center Updates

[Robert Simmons]

 From: Robert Simmons [EMAIL PROTECTED]

  Is not cocoon's power or anything else that I'm arguing with. There is an
  extremely serious bug in cocoon that is causing me to not be able to use
 it
  at all. It is clear that cocoon was developed to be a single solution and
 to
  not integrate with technologies such as application servers.

 This is not true. If Cocoon does not integrate with a particular
application
 server then this doesn't mean that it was done intentionally. You can
easily
 see even from comments in the source that Cocoon were used with WebSphere,
 WebLogic, iPlanet and several other servers.

It is true. Noone in their right mind makign a large system woudl deploy
every damn jar in the WAR file. That would be psycho. The maintenance alone
to make sure you had the right versions in the appserver and war would be a
nightmare. Perhaps if you are developing a littly SQL app to keep track of
employess cocoon is fine. If you try doing anything serious,issues like hte
classloader issue bring it to its knees. And no, that isnt the only issue.


 The classloader
  issue, http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16580,  would
 make
  it ridiculous for me to do anything in cocoon. If I have to deploy all
100
  EJB libs of the company I work for in cocoon as well as in the
application
  server, than my colleagues would rightly laugh themselves silly. In fact
I
  cant believe this issue even exists in a product this mature. I am
looking
 at
  probably 3 months to get this fixed, minimum, if it is ever fixed. At
that
  point I will have to wait for a release of the product, as my company
 would
  throw me at the door for putting up a bleeding edge CVS build.

 The good thing in open source is that you always can take care of any bug
 yourself and provide a patch which would be definitely applied if it's of a
 good quality.

No no no... you dont get it. Im a consumer. Im a professional programmer. Im
not some guy hackign in his dorm room between classes. I dotn have TIME to
learn the detailed integrated architecture of every little product I use.
What really broke the proverbial camel's back was that bug beign reclassified
from high priority to normal. Its at that point that final irritation set in.
it woudl take me 3 months just ot figure out how the internals of cocoon
works. Lets face it, its not documented worth a damn. Even the API is
documented extremely poorly. Once I figured out how it worked I would have to
figure out a resolution to the problem and THEN get apache to accept the
resolution. All this before my product is done and my customers are looking
to download and use it. NOT.

  So basically I'm screwed when I comes to my book and when it comes to my
  company. Cocoon is pretty much out. I guess I have to throw out 2 weeks
of
  agonizing work and I dot know how many emails and recode the whole damn
 thing
  in JSP. Lovely.

 I'd recommend to use Struts in case you choose JSP. But of course, that
 depends on requirements to your project. If you have to deal with various
 output formats, need customizable pages, need integrations with external
XML
 datasources then it's worth trying to overcome Cocoon bug in some way: try
 to fix it, raise this issue on cocoon dev list, try to play with your app
 server settings (maybe declare those jars in Manifest - it's possible
 according to Servlet Spec), etc.

No, Im notgoing to mess with struts. That would be another 2 weeks to learn.
Im already severly bummed that it looks like ive wasted 2 weeks of work. Im
not going o make it worse. The first version in the book is going to have to
be straight JSP without frameworks. Do I like it? No. Do I have a choice? No.
Ive even tried to build it from source even though I have little clue what im
doing. You cant just jump into 500+ quasi documented source files and figure
out the problem in 15 minutes.


 --
   Konstantin

 
  Well, I suppose it could be worse. I dot see much market for Cocoon
  developers anyway.
 
  -- Robert
 
  - Original Message -
  From: SAXESS - Hussayn Dabbous [EMAIL PROTECTED]
  To: [EMAIL PROTECTED]
  Sent: Thursday, January 30, 2003 9:44 AM
  Subject: Re: Cocoon Competence Center Updates
 
 
   Hy Robert,
  
   I appreciate your honesty.
   I hope, you keep with us. I think you can really help
   getting this into the next generation...
  
   just a few of my experiences if you don't mind ...
  
   0.) i use to install minimalistic components when
i start investigating. in this sense i only
needed tomcat-4.*.* to start. just installed it
and ready to go...
  
   1.) When i started working with cocoon i first got
very very frustrated:
sitemap not working as i expected
actions, uhh?
logicsheets, sounds good, howto???
and so on ...
I even did not know, what to ask in detail.
  
   3.) very slowly i got a first overview. i only scratched
the surface and one day (after about two weeks) i

Re: Cocoon Competence Center Updates

[Robert Simmons]

my question is how other people can even use cocoon with this bug in it.
Certainly if you are just doing SQL to a little database, it will work fine
but has none before tried to integrate it with an enterprise development
system?

-- Robert

- Original Message -
From: Luca Morandini [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Thursday, January 30, 2003 1:27 PM
Subject: RE: Cocoon Competence Center Updates


  -Original Message-
  From: Robert Simmons [mailto:[EMAIL PROTECTED]]
  Sent: Thursday, January 30, 2003 1:08 PM
  To: [EMAIL PROTECTED]
  Subject: Re: Cocoon Competence Center Updates

  No no no... you dont get it. Im a consumer. Im a professional programmer.
Im
  not some guy hackign in his dorm room between classes. I dotn have TIME
to
  learn the detailed integrated architecture of every little product I use.
 ...
  Once I figured out how it worked I would have to
  figure out a resolution to the problem and THEN get apache to accept the
  resolution. All this before my product is done and my customers are
looking
  to download and use it. NOT.
 

 Robert,

 I agree on the sorry state of the doc in Cocoon; sorry state which I take,
partially, as a fault of mine, since I wrote only 3-4 FAQ
 entries and a couple pages... and I could have done more.

 I don't agree on the bug resolution part: I uncovered a couple problems
with the SQLTranformer: it was easy to fix them and have
 them (well, actually one) accepted by the committers.

 Compare that with a closed-source product: it would have taken me days
struggling with the tech support to just have the problem
 recognised as such; and then, I would have ended up waiting for the next
release.

 Regards,

 -
Luca Morandini
GIS Consultant
   [EMAIL PROTECTED]
 http://utenti.tripod.it/lmorandini/index.html
 -




 -
 Please check that your question  has not already been answered in the
 FAQ before posting. http://xml.apache.org/cocoon/faq/index.html

 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail:   [EMAIL PROTECTED]



-
Please check that your question  has not already been answered in the
FAQ before posting. http://xml.apache.org/cocoon/faq/index.html

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail:   [EMAIL PROTECTED]

Re: Time to go back to JSP. Cocoon just isnt ready.

[Robert Simmons]

 Robert Simmons wrote:

  I have seen a plethora of new people come on this list and then just
   vanish.

  Comments are invited.

 That's a quick decision for someone who has been around here for only 2
 weeks: http://marc.theaimsgroup.com/?a=10426232413r=1w=2

I have put in 14 to 16 hours a day for 2 weeks on this thing. Lets fuckign
add it up shall we. That would be 210 hours averaging at 15 hours a day.
Dividing by 40 hours (the standard workweek) means that i have put in nearly
5 weeks of work time compressed into 2 weeks. You can sit down and shut up
now.

Since you may havent gotten the picture yet, I dont like being flamed. If I
didnt care I wouldnt have bothered to post the damn mail.


 Then again, we should feel honoured because of the email avalanche you
 caused during that short period, in comparison with:


http://jboss.org/forums/search.jsp?search=trueq=forums=-1date=anyuser=der
isorrange=10

Avalanche? Oh well just sue me. If you would get off that high horse for 15
seconds, you might realize that that avalanche would have never had happened
if the product was documented properly. Fortunately most members of this list
are a bit more far sighted than you and have initiated a documentation effort
based on my comments. I would say that is a contribution. Im not interested
in your arrogant attitude.

Oh and if you would like to know why it is I have had so few posts on JBoss
forums, the answer is quite simple. The product works properly and well and
is very well documented.


 Anyway: http://forum.java.sun.com/thread.jsp?forum=31thread=243200 :

Oh you are steamed about that? Yes many of us on that forum are sick of kids
comming there asking people to do their homework for them. No, you didnt
really read the thread it seems or you would have seen our willingness to
answer questions as long as they arent my teacher said to do x, can someone
write it for me?

As for teaching yourself in cocoon, again I have an ace in the hole you have
forgotten. The documentation in cocoon is minimal at best. This has been
acknowledged by other more intelligent members of this mailing list.

 In 4 years of college I knew more about computers than all of
 my profs together. Why? Cause I taught myself. Teaching one's self is
 rewarding but difficult. You MUST struggle. You must figure things out
 the hard way.

Point out the documentation on the classpath issue. Show me the rich and
fully qualified API documentation. Ahem. There isnt any. Do you make a habbit
of flaming while firing blanks?

 Pardon me if I find your decisions somehow 'unstable'. I find it a pity
 to see you post this kind of judgement after so many people have been
 actively trying to help you (and still do). Sure there is stuff that
 Cocoon fails to do. I just think you are the type of person who will
 always find something that will warrant _not_ using something you
 haven't created yourself.

There have been several people willign to help and I appreciate their
assistance. These people have also recognized the shortcommings of cocoon and
have acknowledged my input as a pure user and non-cocoon hacker. Perhaps you
should hjoin them. I dont make the decision lightly and if I could find any
way of satisfying my requirements with cocoon in the time I have, than I
would change my mind. Unfortunately, real life is a tad more demanding.

 In case you start wondering why I'm so up-close and personal about this:

Like I care.

 you really seem to forget this is _not_ a product, but an open source
 _project_, envisioned, created and supported by a community of real
 people.

If its not a product why bother? Anythign worth doing is worth doing right.
If you arent intending to make somethign that can be widely used, why are you
bothering? Just idle curriosity? if so label it as such so people can say
oh, and move on to something that people intend to be real. I think,
however, the cocoon developers have a bit more vision.

 We are not being protective about our work, and we will readily
 admit its problems, but if all we get is yet another gee I'm gonna
 leave 'coz this sucks reply from you, I'm pretty sure I won't be the
 only one who just stops reading your mails.

Please do. You have nothing intelligent to contribute so please add me to my
ignore filter. That is assuming your monitor hasnt exploded from your flame
beign stuffed back into your face.

 Oh well - flame me, I can handle it. I'm sick of seeing nice people
 trying to help you, and you just spreading FUD in return. This is the
 third inflamatory email I composed to you during the past few days, and
 this time, I won't refrain from sending.

Feel free. If you ever come up with something intelligent to say, please flag
it as important. Others such as SAXESS have you beat by about 10,000 percent
in brain power and I appreciate their input. You, are just another dork
sittign in judgement of others. Shoo! Unfortunately for you, you caught me in
a particularly punchy mood where I am not going

Re: Time to go back to JSP. Cocoon just isnt ready.

[Robert Simmons]

Sorry. To say I've had a bad week would be a massive understatement. Today
was just not the right day to flame me. If he had done it yesterday I would
have ignored him. But my mail was just as uncalled for as his.

-- Robert


- Original Message -
From: Sorin Marti [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Thursday, January 30, 2003 2:22 PM
Subject: Re: Time to go back to JSP. Cocoon just isnt ready.


 Ooooh!!

 I have not followed the list in the last days and now this. What's going
 on? If you got a problem with each other why can't you be polite?

 This list is (AFAIK) NOT to curse at somebody. If you want to vituperate
 please do it per PM!!


 Sorin Marti


 -
 Please check that your question  has not already been answered in the
 FAQ before posting. http://xml.apache.org/cocoon/faq/index.html

 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail:   [EMAIL PROTECTED]



-
Please check that your question  has not already been answered in the
FAQ before posting. http://xml.apache.org/cocoon/faq/index.html

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail:   [EMAIL PROTECTED]

Re: Cocoon Competence Center Updates

[Robert Simmons]

My book has nothing to do with cocoon. Its a side 
issue at best. That's why I was so irritated about spending 2 weeks on it to 
draw a blank. Nothing like spending 2 weeks on something you consider to be 
trivial to your main line of work. 

-- Robert

  - Original Message - 
  From: 
  Irving Salisbury 
  
  To: [EMAIL PROTECTED] 
  
  Sent: Thursday, January 30, 2003 2:54 
  PM
  Subject: Re: Cocoon Competence Center 
  Updates
  You know, I have been coding in cocoon for about 2 years now, 
  and have gotten by quite happily without XSP pages at all. The bug you 
  are referring to only is a bug with XSP. Maybe you can look at cocoon 
  without using XSP pages? There may be a reason you have to use XSP, but 
  just wanted to chime in with this. I prefer to avoid using XSP pages and 
  stick with plain Java code, mostly using custom actions and transformers. 
  It has worked well on our projects. Sorry about your 
  book.IrvRobert Simmons wrote:
  Is not cocoon's power or anything else that I'm arguing with. There is an
extremely serious bug in cocoon that is causing me to not be able to use it
at all. It is clear that cocoon was developed to be a single solution and to
not integrate with technologies such as application servers. The classloader
issue, http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16580,  would make
it ridiculous for me to do anything in cocoon. If I have to deploy all 100
EJB libs of the company I work for in cocoon as well as in the application
server, than my colleagues would rightly laugh themselves silly. In fact I
cant believe this issue even exists in a product this mature. I am looking at
probably 3 months to get this fixed, minimum, if it is ever fixed. At that
point I will have to wait for a release of the product, as my company would
throw me at the door for putting up a bleeding edge CVS build.

So basically I'm screwed when I comes to my book and when it comes to my
company. Cocoon is pretty much out. I guess I have to throw out 2 weeks of
agonizing work and I dot know how many emails and recode the whole damn thing
in JSP. Lovely.

Well, I suppose it could be worse. I dot see much market for Cocoon
developers anyway.

-- Robert

- Original Message -
From: "SAXESS - Hussayn Dabbous" [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Thursday, January 30, 2003 9:44 AM
Subject: Re: Cocoon Competence Center Updates


  
Hy Robert,

I appreciate your honesty.
I hope, you keep with us. I think you can really help
getting this into the next generation...

just a few of my experiences if you don't mind ...

0.) i use to install minimalistic components when
 i start investigating. in this sense i only
 needed tomcat-4.*.* to start. just installed it
 and ready to go...

1.) When i started working with cocoon i first got
 very very frustrated:
 sitemap not working as i expected
 actions, uhh?
 logicsheets, sounds good, howto???
 and so on ...
 I even did not know, what to ask in detail.

3.) very slowly i got a first overview. i only scratched
 the surface and one day (after about two weeks) i got
 hit by realizing the hidden mightiness of the beast.
 "Hey that's great, this works fine,
  ahh what easy going here and there..."
 Until now i still only was playing with the very
 basics (sitemap, generator, protocol handlers)

4.) After reviewing my first experiences with cocoon i came
 to the conclusions:
 - its very complex
 - it has great oportunities
 - it is "complex documented"
 - it moves fast
 - it neads quality assurance to get mature

My decisions:

 - use cocoon in my own projects
 - help cocoon users to get a clear understanding
   with less frustrations

I'm still happy with cocoon and im still only using the very
basics. I am curious where i can get with XSP and ESQL ;-)

regards, hussayn


Robert Simmons wrote:

  Fine ... I'm beginning to loose interest to be honest. Right now I cant
  do
  

  anything with XSP with cocoon at all. because of the classpath bug it
  looks
  

  like two weeks of my work are about to explode in my face. Sigh.

-- Robert

- Original Message -
From: "SAXESS - Hussayn Dabbous" [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Thursday, January 30, 2003 9:12 AM
Subject: Re: Cocoon Competence Center Updates



  
Hy, Robert;

Thank you very much for the contributions.

I propose to move parts of your contrib into another page.

reasons:

1.) this page deals with deploying cocoon. it should not cover
essentials of cocoon internals. this is the next story to be
covered, once cocoon is deployed.

2.) i want this document to be for "beginning beginners", (we used
to name them nebies ;-). Yes we should prepare a doc, that
contains your hints and tips, but maybe this is an add on
page ?

if nobody complains, i

Form processign and control flow?

[Robert Simmons]

Well, my newbieness to cocoon continues as does my 
frustration. Anyway, another burning question. 

I have a series of forms with pseudo code such as 


if (user invokes edit) {
 open edit form;
 on submit of form {
 attempt to execute 
change.
 if (attempt succeeds) route to 
view page. 
 else route to error page with 
the given error message from the attempt. 
 }
}

Both the error page and the pages beign routed to 
are usign custom made generators. What I dont know how to do is to do the 
routing. I can always invoke one generator to process the command and return an 
error page if the command doesnt work. However, if the command doesnt work Id 
like the generator to cause a redirect that forwards the user's browser to 
another url. How in the world can I accomplish this? Im eagerly awaitign hearign 
your ideas. 

-- Robert

Cocoon Competence Center Updates

[Robert Simmons]

Greetings, I have added the following information 
to the cocoon competence center page on installing cocoon. Please feel free to 
review the following sections and smack me around if I said anything incorrect. 
The new sections are. 

*Deploying on an application server. 

*What is essential?

-- Robert

Re: Cocoon Competence Center Updates

[Robert Simmons]

On the same topic, I am more distressed at this 
editing policy. Someone could easily be malicious and log in and erase 
everything. Are we sure there isn't a better way to do this?

-- Robert

  - Original Message - 
  From: 
  Robert Simmons 
  
  To: Cocoon Users 
  Sent: Thursday, January 30, 2003 3:41 
  AM
  Subject: Cocoon Competence Center 
  Updates
  
  
  Greetings, I have added the following information 
  to the cocoon competence center page on installing cocoon. Please feel free to 
  review the following sections and smack me around if I said anything 
  incorrect. The new sections are. 
  
  *Deploying on an application server. 
  
  *What is essential?
  
  -- Robert
  

XSP Compiler Issue: Class Not found

[Robert Simmons]

Greetings. I decided that I wanted to try writing 
an XSP page. I know about logicsheets but just to start I figured Idgo the 
brute force approach. The following is theXSP page. 

?xml version="1.0" 
encoding="UTF-8"?xsp:page language="java" xmlns:xsp="http://apache.org/xsp" 
xmlns:jconfer="http://www.jconfer.org/" 
xsp:structure 
xsp:includejavax.naming.InitialContext/xsp:include 
xsp:includejavax.naming.NamingException/xsp:include 
xsp:includejavax.rmi.PortableRemoteObject/xsp:include 
xsp:includejava.util.Collection/xsp:include 
xsp:includejava.util.Set/xsp:include 
xsp:includejava.util.Iterator/xsp:include 
xsp:includejava.util.Properties/xsp:include 
xsp:includejconfer.data.Smiley/xsp:include 
xsp:includemirror.datafetch.DataFetch/xsp:include 
xsp:includemirror.datafetch.DataFetchHome/xsp:include 
/xsp:structure  
jconfer:page 
xsp:logic try 
{ InitialContext ictxt = new 
InitialContext(); 
messagexsp:exprictxt.getNameInNamespace()/xsp:expr/message 
 DataFetchHome dfHome = 
(DataFetchHome)PortableRemoteObject.narrow( 
ictxt.lookup("JConfer/DataFetch"), 
DataFetchHome.class); DataFetch 
dataFetch = dfHome.create(); 
Collection smileys = dataFetch.performQuery(Smiley.class, null, null, null, 
 
null, "code ascending"); Iterator 
iter = smileys.iterator(); Smiley 
tgtSmiley = null; 
xsp:element 
xsp:param 
name="name"xsp:expr"smiley"/xsp:expr/xsp:param 
while (iter.hasNext()) 
{ 
tgtSmiley = 
(Smiley)iter.next(); 
xsp:attribute 
name="code"xsp:exprtgtSmiley.getCode()/xsp:expr/xsp:attribute 
xsp:attribute 
name="code"xsp:exprtgtSmiley.getDescription()/xsp:expr/xsp:attribute 
} 
/xsp:element } catch (Exception ex) 
{ 
messagexsp:exprex.getMessage()/xsp:expr/message 
} /xsp:logic  
/jconfer:page
/xsp:page

This page is basically a copy of a generator that 
DOES work .. SHown below. 

package jconfer.client.generators;

import java.io.IOException;import 
java.util.Collection;import java.util.Date;import 
java.util.Enumeration;import java.util.Iterator;import 
java.util.Map;import javax.naming.InitialContext;import 
javax.naming.NamingException;import 
javax.rmi.PortableRemoteObject;import 
javax.servlet.http.HttpServletRequest;import jconfer.data.Smiley;import 
mirror.datafetch.DataFetch;import mirror.datafetch.DataFetchHome;import 
org.apache.avalon.framework.parameters.Parameters;import 
org.apache.cocoon.ProcessingException;import 
org.apache.cocoon.environment.ObjectModelHelper;import 
org.apache.cocoon.environment.Request;import 
org.apache.cocoon.environment.SourceResolver;import 
org.apache.cocoon.generation.AbstractGenerator;import 
org.w3c.dom.Document;import org.w3c.dom.Element;import 
org.xml.sax.SAXException;import 
org.xml.sax.helpers.AttributesImpl;

/** Handles a command for getting an admin screen 
for forum smileys.** pbsmallCurrent 
CVS Tag: $Name$/b/small/p* @version 
$Revision$* @author $author$*/public class 
SmileyAdminView extends GeneratorBase {

 /** {@inheritDoc} */ public void 
generateContent() throws Exception { DataFetchHome dfHome 
= (DataFetchHome)jndiLookup(DataFetchHome.class, 
 
"JConfer/DataFetch"); DataFetch dataFetch = 
dfHome.create(); // -- Collection 
smileys = dataFetch.performQuery(Smiley.class, null, null, null, 
 
null, "code ascending"); // -- 
AttributesImpl attributes = new AttributesImpl(); Smiley 
tgtSmiley = null; // -- Start the 
content this.contentHandler.startElement("", 
"smiley-admin-view", "smiley-admin-view", EMPTY_ATTRS); // 
-- Do internal elements. Iterator iter = 
smileys.iterator(); while (iter.hasNext()) 
{ tgtSmiley = 
(Smiley)iter.next(); 
attributes.clear(); 
attributes.addAttribute("", "code", "code", "", 
tgtSmiley.getCode()); 
attributes.addAttribute("", "description", "description", "", 
tgtSmiley.getDescription()); 
this.contentHandler.startElement("", "smiley", "smiley", 
attributes); 
this.contentHandler.endElement("", "smiley", "smiley"); 
} // -- End the document 
this.contentHandler.endElement("", "smiley-admin-view", 
"smiley-admin-view"); }}

The problem is that when I try to run the XSP page, 
the compiler freaks out and cannot find any of the Mirror or JConfer classes. It 
gives me a class not found on all of them. However the generator works. These 
classes are deployed in another package and therefore are available to the 
classloader of the application server but somehow cocoon isnt seeing them. Is 
there any way I can tell cocoon that they are there? We know they are available 
because the generator does in fact work. 

-- Robert

Re: XSP Compiler Issue: Class Not found

[Robert Simmons]

More information. I think this might have to do 
with the classpath setting on the compiler. It seems to be creating its own 
classpath instead of passing the current cocoon classpath to the compiler. The 
classloader, being different, cannot find any classes outside of the current WAR 
to compile. This would mean that you would have to deploy every single library 
you use in the WEB-INF/lib directory. That is untenable for large applications. 
Further, for applications that have to wire into EJB, it is even worse. This is 
because you will often have a set of interfaces for a server side component and 
need to redeploy them. With this limitation, my classes in cocoon could get out 
of synch with those deployed in the application server quite easily and cause 
all sorts of nastiness. 

Is this a bug perhaps? Has anyone else hit this? 


-- Robert

  - Original Message - 
  From: 
  Robert Simmons 
  
  To: Cocoon Users 
  Sent: Thursday, January 30, 2003 4:47 
  AM
  Subject: XSP Compiler Issue: Class Not 
  found
  
  Greetings. I decided that I wanted to try writing 
  an XSP page. I know about logicsheets but just to start I figured Idgo 
  the brute force approach. The following is theXSP page. 
  
  ?xml version="1.0" 
  encoding="UTF-8"?xsp:page language="java" xmlns:xsp="http://apache.org/xsp" 
  xmlns:jconfer="http://www.jconfer.org/" 
  xsp:structure 
  xsp:includejavax.naming.InitialContext/xsp:include 
  xsp:includejavax.naming.NamingException/xsp:include 
  xsp:includejavax.rmi.PortableRemoteObject/xsp:include 
  xsp:includejava.util.Collection/xsp:include 
  xsp:includejava.util.Set/xsp:include 
  xsp:includejava.util.Iterator/xsp:include 
  xsp:includejava.util.Properties/xsp:include 
  xsp:includejconfer.data.Smiley/xsp:include 
  xsp:includemirror.datafetch.DataFetch/xsp:include 
  xsp:includemirror.datafetch.DataFetchHome/xsp:include 
  /xsp:structure  
  jconfer:page 
  xsp:logic try 
  { InitialContext ictxt = new 
  InitialContext(); 
  messagexsp:exprictxt.getNameInNamespace()/xsp:expr/message 
   DataFetchHome dfHome = 
  (DataFetchHome)PortableRemoteObject.narrow( 
  ictxt.lookup("JConfer/DataFetch"), 
  DataFetchHome.class); DataFetch 
  dataFetch = dfHome.create(); 
  Collection smileys = dataFetch.performQuery(Smiley.class, null, null, null, 
   
  null, "code ascending"); 
  Iterator iter = 
  smileys.iterator(); Smiley 
  tgtSmiley = null; 
  xsp:element 
  xsp:param 
  name="name"xsp:expr"smiley"/xsp:expr/xsp:param 
  while (iter.hasNext()) 
  { 
  tgtSmiley = 
  (Smiley)iter.next(); 
  xsp:attribute 
  name="code"xsp:exprtgtSmiley.getCode()/xsp:expr/xsp:attribute 
  xsp:attribute 
  name="code"xsp:exprtgtSmiley.getDescription()/xsp:expr/xsp:attribute 
  } 
  /xsp:element } catch (Exception ex) 
  { 
  messagexsp:exprex.getMessage()/xsp:expr/message 
  } /xsp:logic  
  /jconfer:page
  /xsp:page
  
  This page is basically a copy of a generator that 
  DOES work .. SHown below. 
  
  package jconfer.client.generators;
  
  import java.io.IOException;import 
  java.util.Collection;import java.util.Date;import 
  java.util.Enumeration;import java.util.Iterator;import 
  java.util.Map;import javax.naming.InitialContext;import 
  javax.naming.NamingException;import 
  javax.rmi.PortableRemoteObject;import 
  javax.servlet.http.HttpServletRequest;import 
  jconfer.data.Smiley;import mirror.datafetch.DataFetch;import 
  mirror.datafetch.DataFetchHome;import 
  org.apache.avalon.framework.parameters.Parameters;import 
  org.apache.cocoon.ProcessingException;import 
  org.apache.cocoon.environment.ObjectModelHelper;import 
  org.apache.cocoon.environment.Request;import 
  org.apache.cocoon.environment.SourceResolver;import 
  org.apache.cocoon.generation.AbstractGenerator;import 
  org.w3c.dom.Document;import org.w3c.dom.Element;import 
  org.xml.sax.SAXException;import 
  org.xml.sax.helpers.AttributesImpl;
  
  /** Handles a command for getting an admin screen 
  for forum smileys.** 
  pbsmallCurrent CVS Tag: 
  $Name$/b/small/p* @version 
  $Revision$* @author $author$*/public class 
  SmileyAdminView extends GeneratorBase {
  
   /** {@inheritDoc} */ public void 
  generateContent() throws Exception { DataFetchHome 
  dfHome = (DataFetchHome)jndiLookup(DataFetchHome.class, 
   
  "JConfer/DataFetch"); DataFetch dataFetch = 
  dfHome.create(); // -- Collection 
  smileys = dataFetch.performQuery(Smiley.class, null, null, null, 
   
  null, "code ascending"); // -- 
  AttributesImpl attributes = new AttributesImpl(); Smiley 
  tgtSmiley = null; // -- Start the 
  content this.contentHandler.startElement("", 
  "smiley-admin-view", "smiley-admin-view", EMPTY_ATTRS); 
  // -- Do internal elements. Iterator iter = 
  smileys.iterator(); while (iter.hasNext()) 
  { tgtSmiley = 
  (Smiley)iter.next(

Re: Cocoon Job opps in Frankfurt, Germany

[Robert Simmons]

Strange that I did a search on gulp.de and monster.de for Cocoon and came up
empty. Where are you guys hearing about these contracts?

-- Robert

- Original Message -
From: Jeremy Aston [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Tuesday, January 28, 2003 3:32 PM
Subject: RE: Cocoon Job opps in Frankfurt, Germany


 The UK rate has dropped significantly.  You are really looking at something
 like £35-£40 per hour (as opposed to £60-£70 ph in the past couple of
years.
 $500ph is v. reasonable.

 At the end of the day these angencies never put a rate since they want to
 get as good a person as cheap as possible!

 jez

  -Original Message-
  From: Niclas Hedhman [mailto:[EMAIL PROTECTED]]
  Sent: 28 January 2003 05:13
  To: [EMAIL PROTECTED]
  Subject: Re: Cocoon Job opps in Frankfurt, Germany
 
 
  On Tuesday 28 January 2003 09:20, Jeremy Aston wrote:
   Hi,
  
   I keep seeing ads for contractors based in Frankfurt on a UK based job
   site...
  
  
  http://www.it.jobserve.com/jobserve/searchresults.asp?jobType=*d=
 5order=R
 a nkpage=1q=cocoon

 They almost all list Rate: Market. What is that roughly? Just curious
what
 it pays to be employed nowadays in this kind of field...

 Anyone willing to reveal?

 Me? I live in the low cost country so I charge only(?) around $500 per
 day,
 as consultant.

 Niclas

  I have tried to get in there as a UK based person (and Cocooon book
  co-author) but the company are 100% set on having an on site person and
no
  remote workers/software houses/cooperatives.  I can't move to Germany so
 am
  out of the picture - bah!  These people have advertised reguarly over the
  past 4-6 months so the work must be ongoing.
 
  If anyone does get in there and find they can put in a word for remote
  workers (I will go to a couple of times a month for a couple of days)
then
  I'm here!
 
  rgds
 
  Jeremy


 -
 Please check that your question  has not already been answered in the
 FAQ before posting. http://xml.apache.org/cocoon/faq/index.html

 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail:   [EMAIL PROTECTED]


 __
 Do You Yahoo!?
 Everything you'll ever need on one web page
 from News and Sport to Email and Music Charts
 http://uk.my.yahoo.com

 -
 Please check that your question  has not already been answered in the
 FAQ before posting. http://xml.apache.org/cocoon/faq/index.html

 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail:   [EMAIL PROTECTED]



-
Please check that your question  has not already been answered in the
FAQ before posting. http://xml.apache.org/cocoon/faq/index.html

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail:   [EMAIL PROTECTED]

Re: How to open 2 windows?

[Robert Simmons]

Just a warning. There has been a study recently that quite well confirms that
using popups in a commercial web site is a good way to drive traffic AWAY
from that site. Personally, they annoy the shit out of me. If I really needed
to get my penis enlarged Id look it up on google.de. Getting offered it from
half the web sites on the internet could be bad for self confidence. =)

-- Robert

- Original Message -
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Tuesday, January 28, 2003 10:27 AM
Subject: How to open 2 windows?


 Hi,

 I want to open 2 windows on one event. The xml/xsp (I mean the data)
 would be the same, but the output would be: first window html, second
 window pdf.

 e.g. my dummy sitemap:
 ...
 !-- on submit generate *.html and *.pdf output --
 map:match pattern=html-pdf
 map:generate type=serverpages src=html-pdf.xsp/
 !-- generate a window with html output
 map:transform src=html.xsl/
 map:serialize
  --
 !-- generate another window with pdf output
 map:transform src=pdf.xsl/
 map:serialize type=fo2pdf/
 --
 /map:match

 How can I manage this? Can I mange this from my sitemap?

 Cheers
 Jonny
 ---
-

 This electronic message contains information from the mmo2 plc Group which
 may be
 privileged or confidential. The information is intended to be for the use
 of the
 individual(s) or entity named above. If you are not the intended recipient
 be aware
 that any disclosure, copying, distribution or use of the contents of this
 information
 is prohibited. If you have received this electronic message in error,
 please notify
 us by telephone or email (to the numbers or address above) immediately.




 -
 Please check that your question  has not already been answered in the
 FAQ before posting. http://xml.apache.org/cocoon/faq/index.html

 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail:   [EMAIL PROTECTED]



-
Please check that your question  has not already been answered in the
FAQ before posting. http://xml.apache.org/cocoon/faq/index.html

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail:   [EMAIL PROTECTED]

Re: IDE for cocoon

[Robert Simmons]

Well I don't have money to buy any tools. Usually I have to get companies to
buy them. However as a suggestion, fi you are trying to get more customers,
Id investigate a way to integrate your concepts with open platforms like
NetBeans or eclipse. Breaking people off from their normal IDEs is tough.
Getting them to add new functionality to them is much easier.

-- Robert

- Original Message -
From: Alexandru COSTIN [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Tuesday, January 28, 2003 9:52 AM
Subject: RE: IDE for cocoon


 Hello,
 We have a very powerful IDE called KrysalIDE especially designed to
 understand the concept of XSP, taglibs and pipelines.
 It already provides some interesting features for our Cocoon clone -
 Krysalis, and we are considering porting it to coocon if there will be
 enough interest. (it is a commercial product)

 See more about KrysalIDE at http://www.interakt.ro/products/KrysalIDE/

 We have tag completion capability for any taglib and for XSLs, visual
 link between XML and XSL, etc,
 Alexandru

 On Wed, 2003-01-22 at 17:38, Geoff Howard wrote:
  While we're talking about sunbow, are there any plans to provide some
kind
  of support for xsp/xml editing?  Maybe I haven't found the right settings
or
  external plugins yet but xml editing doesn't seem very rich.  Jedit at
least
  has some tag completion capability etc.
 
  Have I missed something?
 
  Geoff
 
   -Original Message-
   From: Matthew Langham [mailto:[EMAIL PROTECTED]]
   Sent: Wednesday, January 22, 2003 9:34 AM
   To: [EMAIL PROTECTED]
   Subject: RE: IDE for cocoon
  
  
   Hi,
  
   the current free version of sunBow will remain free. At the moment we
   require a licence key (because we originally thought this a good idea)
and
   have not yet got round to removing the dependency.
  
   Hopefully we will find some time to do that...but until then :-).
  
   Matthew
  
   --
   Open Source Group   Cocoon { Consulting, Training, Projects }
   =
   Matthew Langham, SN AG, Klingenderstrasse 5, D-33100 Paderborn
   Tel:+49-5251-1581-30  [EMAIL PROTECTED] - http://www.s-und-n.de
   -
   Cocoon book:
 http://www.amazon.com/exec/obidos/ASIN/0735712352/needacake-20
   Weblogs:
 http://radio.weblogs.com/0103021/
 http://www.oreillynet.com/weblogs/author/1014
   =
  
  
   -Original Message-
   From: Jordi Valldaura [mailto:[EMAIL PROTECTED]]
   Sent: Wednesday, January 22, 2003 3:27 PM
   To: [EMAIL PROTECTED]
   Subject: Re: IDE for cocoon
  
  
   Hello,
  
   I agree with u that eclipse is a very good ide. But the sunbow
   plug in needs
   a registration
   key, I know they give it freely now but I don't think they will
   do it in the
   future.
  
  
   - Original Message -
   From: Geoff Howard [EMAIL PROTECTED]
   To: [EMAIL PROTECTED]
   Sent: Wednesday, January 22, 2003 2:27 PM
   Subject: RE: IDE for cocoon
  
  
I've recently started using eclipse and have been very impressed.
The
information it provides helps make sense of what can seem like
   a rats nest
of dependencies.  I have brought in avalon and avalon-excalibur as
   projects
alongside cocoon and my own cocoon-based projects which has been very
helpful in tracking down information that crosses the border
   between the
projects.
   
All of that would be true with any good IDE, but this one's free and
has
   the
added benefit of the sunBow stuff.
   
Hope that helps,
Geoff
   
 -Original Message-
 From: Martin Dulisch [mailto:[EMAIL PROTECTED]]
 Sent: Wednesday, January 22, 2003 4:20 AM
 To: [EMAIL PROTECTED]
 Subject: Re: IDE for cocoon


 Hi Reza,

 sunBow is a plugin for eclipse (www.eclipse.org). It contributes
some
 Cocoon/XML/XSLT features to eclipse. You can find the download and
 documentation here: http://radio.weblogs.com/0108489/

 Martin

 - Original Message -
 From: Reza Aliakbari [EMAIL PROTECTED]
 To: [EMAIL PROTECTED]
 Sent: Wednesday, January 22, 2003 10:11 AM
 Subject: IDE for cocoon


  Dears,
 
  I am new in cocoon.
  I need some tools and IDE for cocoon.
  Also I am waiting for any advise that could be useful for new
cocoon
  developers.
 
  Thanks,
  Reza.
 

 
 -
  Please check that your question  has not already been answered in
 the
  FAQ before posting.
 http://xml.apache.org/cocoon/faq/index.html
 
  To unsubscribe, e-mail:
 [EMAIL PROTECTED]
  For additional commands, e-mail:
 [EMAIL PROTECTED]
 


   
 -
 Please check 

Re: proposal: The Newbies Competence Center

[Robert Simmons]

Id be happy to write up some stuff on connecting to EJB servers now that I
have actually figured out how to do it.

-- Robert

- Original Message -
From: Niclas Hedhman [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Tuesday, January 28, 2003 8:02 AM
Subject: Re: proposal: The Newbies Competence Center


On Tuesday 28 January 2003 15:00, Derek Hohls wrote:
 The First Steps chapter listed below is the one that needs
 some thought and attention.  My feeling is that we need to
 focus on the problems that needs to be solved, rather than
 a lengthy description of what is *possible* with Cocoon.

Good point!

If that is also made from the background of user aspect, so that;

You know XML/XSL and want to publish static content - click here

You are a DB developer who wants to expose XML data - click here

You are Stefano Mazzocchi and want to - you are in the wrong area


Base it on use cases and add 1 hour or less exercises.
I assume that a pre-condition here is a suitable distro to start from.

Niclas

-
Please check that your question  has not already been answered in the
FAQ before posting. http://xml.apache.org/cocoon/faq/index.html

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail:   [EMAIL PROTECTED]


-
Please check that your question  has not already been answered in the
FAQ before posting. http://xml.apache.org/cocoon/faq/index.html

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail:   [EMAIL PROTECTED]

Re: proposal: The Newbies Competence Center

[Robert Simmons]

I don't think that the word newbie is such a stigma. People know when they
are newbies and not. Rarely do people take it offensively unless its an
outside person telling them that they are a newbie. In fact people can take
it tongue in cheek as the for Dummies or Idiots guide to ...  books show.
Despite their tongue in cheek titles they are amazingly popular. However, the
documentation we are proposing is not just targeted at newbies but eventually
will span the spectrum of users. For this reason I think the title you
proposed is the right one. As to using Wiki, I never have but I will state
that id like the documentation to actually be served by cocoon. The benefits
to that is the multi-content publishing framework at its best. Users can get
PDFs or post script or any number of other types of content as well as the
surfed content.

What I would like to see now is a style guide for XML documents that will be
common to all published cocoon info. In this manner we can apply a standard
XSLT transform to all documents and the writers would just be using XML to
accomplish the task. This would give us allot of flexibility. What I am
talking about is a custom schema (or borrowed one) that all of the
documentation authors can validate against and that the template authors can
use to transform. Then I would suggest that the full cocoon samples and
documentation be put through this framework. It would take some thought
because you want the ability to have it referencable and indexable. For
example, I should be able to create a sitemap entry that will combine all
cocoon docs into one big page and transform it into PDF.

Its always best if you start with architecture and start filling things in.

-- Robert

- Original Message -
From: SAXESS - Hussayn Dabbous [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Tuesday, January 28, 2003 11:48 AM
Subject: Re: proposal: The Newbies Competence Center


 seems as if my round up generqted even more input ;-)
 thanks to all of you.

 so what do we have now? i reround up here:

 1.) there is a strong push towards role based documentation
 2.) there is a strong recommendation to use cocoon-wiki
 3.) the discussion roles on over the whole documentation set

 hmm... seems so as if this gets a bigger task, than expected ;-)

 by the way, i looked up the word newbie. It may be of interst,
 that this is the short from of new boy. Hey, we can't do that ...

 I'd recommend to rename this to The Cocoon Competence Center
 and start with the beginners section on the cocoon wiki...

 any doubts ?

 regards, Hussayn


 Derek Hohls wrote:
  This is getting periously close to documentation ;-)
  Seriously, this is the kind of description that is incredibly
  useful to have up front - never mind arguing over who should
  have what skills and how they should work together ... that
  is a project/company issue and will differ from case-case
  (the current view is that most people are multi-skilled anyway)
  BUT we can all agree on what skills are needed to work
  with Cocoon and can link our documentation (see other mail
  on wiki classifications) to those skills; what Peter elsewhere
  has called role based documentation.
 
  It will be of great help to the new user to see what he/she might
  be expected to know (or learn) before getting up in the
  intricacies of sitemaps, generators and the rest of the jargon!
 
[EMAIL PROTECTED] 27/01/2003 11:59:41 
  Tony Collen wrote:
 
   For instance, with a typical installation of Cocoon, we could define
the
   following roles:
   
   - Content Creator.  This person authors XML for the site to be
   transformed.  This role works when most of the content is static.
   However, if a lot of the data is being pulled out of a database, they
   would be in charge of something like data entry into the database, etc.
   
 
  I've been seeing this role work out well in practice.  There is
  grumbling when they can't mark up their content significantly like they
  used to in Frontpage or Dreamweaver, but after seeing a demo, they
  usually acquiesce.
 
   - Graphic/Web designer.  This person is in charge of the style of
   the site.  Not only do they come up with how the site looks through the
   design of the final HTML, but they also write the XSL to transform the
   content into the desired format.  Sometimes this person is also the
   content creator.
   
 
  This role, however, falls apart quickly.  There are three roles here and
  it's rare that any one person satisfies all of the roles successfully.
 
  1) The graphic designer:
   The artist/production manager who is a whiz with Photoshop/Paint
  Shop Pro/The GIMP.  They design the overall look and feel for the site.
  Anyone who has seen a good graphic artist can attest to the fact that
  not everyone can do the job.
 
  2) The HTML/CSS web monkey (term of endearment -- not meant to offend):
   Can take the layout design from the graphic artist and turn it into
  clean and useable 

Re: proposal: The Newbies Competence Center

[Robert Simmons]

Hmm .. where do I find this?

-- Robert

- Original Message -
From: SAXESS - Hussayn Dabbous [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Tuesday, January 28, 2003 3:49 PM
Subject: Re: proposal: The Newbies Competence Center


 Hy,

 the Cocoon Competence Center is Born ;-)

 I have changed the link on the WIki leftMenu
 from new to cocoon? into For Beginners and
 added the cocoon in 15 minutes: page.

 I invented a first set of metadata:

 - TARGET-AUDIENCE: beginners
 - COCOON-RELEASES: 2.0.3, 2.0.4
 - AUTHOR: Hussayn Dabbous
 - AUTHOR-CONTACT: [EMAIL PROTECTED]
 - REVIEWED-BY:
 - REVIEWER-CONTACT:

 Maybe this needs review.

 regards, hussayn
 --
 Dr. Hussayn Dabbous
 SAXESS Software Design GmbH
 Neuenhöfer Allee 125
 50935 Köln
 Telefon: +49-221-56011-0
 Fax: +49-221-56011-20
 E-Mail:  [EMAIL PROTECTED]


 -
 Please check that your question  has not already been answered in the
 FAQ before posting. http://xml.apache.org/cocoon/faq/index.html

 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail:   [EMAIL PROTECTED]



-
Please check that your question  has not already been answered in the
FAQ before posting. http://xml.apache.org/cocoon/faq/index.html

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail:   [EMAIL PROTECTED]

Preloading parts of cocoon.

[Robert Simmons]

Greetings. Whenever I change a page in my sitemap 
and redeploy, I notice that the first time I hit a page it takes cocoon a few 
seconds to start the page. Is there any way we can get cocoon to preprocess this 
stuff at deployment time so that the users only see instant results 
?

-- Robert

Re: proposal: The Newbies Competence Center

[Robert Simmons]

Incidentally, I find that when I hit the Wiki page, I don't see half of the 
left menu until I pass my mouse over the links. IE6 problem?

-- Robert

  - Original Message - 
  From: 
  Derek Hohls 
  
  To: [EMAIL PROTECTED] 
  
  Sent: Tuesday, January 28, 2003 8:00 
  AM
  Subject: Re: proposal: "The Newbies 
  Competence Center"
  
  I think that Miles' outline below reflects a very good way
  of organising the primary Cocoon site. I am not sure that
  it is completely appropriate for new users (yes, I still 
  think there is a distinction between a user and a 'hard core'
  developer - see later replies). 
  The "First Steps" chapter listed below is the one that needs
  some thought and attention. My feeling is that we need to
  focus on the problems that needs to be solved, rather than
  a lengthy description of what is *possible* with Cocoon. 
  This should be difficult to draw up; there are many common 
  problems for web developers and it should not be that hard
  to create some example solutions.
  
  Comes back to what I am comfortable with "learning by seeing
  and then doing"... the light of in-depth understanding usually
  dawns a little later on.
   [EMAIL PROTECTED] 27/01/2003 10:10:48 
  Tony Collen wrote:On Mon, 27 Jan 2003, SAXESS - 
  Hussayn Dabbous wrote: o There was 
  an idea to redesign the cocoon documentation entry 
  page and provide chapters 
  like: 1) First 
  steps 2) User's Manual 3) 
  User's Reference 4) 
  Architecture 5) Developer's 
  Guide This is good. 
  HOWEVER, occasionally the line between "user" and"developer" gets 
  blurred, especially when a user realizes they need todevelop a custom 
  component.All too often, I've gone to the developer section 
  looking for informationthat was actually in the user guide, and vice 
  versa.I totally agree. In fact, this is an item that I took 
  issue with in Lajos and Jeremy's book: which "Generators" section should I 
  be looking in? I also don't know that a quick reference and a manual 
  must be distinct items. For a printed book, this makes a lot of 
  sense. But the web is inherently a quick reference -- bouncing from 
  relevant topic to relevant topic. This is an area where I think the 
  existing documentation (for some components) shines. If you take a 
  look at the Request XSP logicsheet (http://xml.apache.org/cocoon/userdocs/xsp/request.html), 
  this is an example of what I mean. If the page simply had quick, 
  in-page links to description, usage, examples, and quick reference, you 
  would be done. A user looking up information says, "Hmmm, I know I 
  want to use a serializer so I'll go to the serializer section." From 
  there, they can select if they want an example, an API lookup, etc. 
  Quick references exist because no one wants to haul around five hundred 
  page books. But if you are on the web, you already have access to a 
  million page book. The same rules don't apply.However, I 
  think the above list has merit if you clearly define what "development" 
  is. I tend to think that *anyone* who installs Cocoon and edits 
  something to be a developer rather than a user. The users, in my 
  mind, are the folks using the web browser. There are, however, 
  different classes of developer. For example, if you write an XSP 
  document, you've in essense written a generator. No, they didn't 
  call javac themselves, but it's only slightly different. The 
  difference mainly lies in its relative ease, not in the intent. If 
  you set up a pipeline in the sitemap, what are you if not a developer 
  assembling components together?On the other hand, making changes 
  to the Flow engine, the cache store, the sitemap parser, etc. are 
  definitely different from writing your own transformer. The 
  distinction in the documentation should be "here are things you can do for 
  your own benefit that affect no one else" and "here are things that 
  fundamentally affect the requirements for other components."For 
  example:1) Architecture Overview/Primer/First Steps a) Why 
  Cocoon exists b) Quick start installation c) Hello World 
  (XSP document going through a simple transformer and serializing to 
  HTML) d) Very brief introduction to sitemaps, generators, etc. by 
  explaining Hello World2) The Cocoon servlet a) 
  Installation instructions i) 
  Tomcat ii) Jetty iii) 
  JBoss iv) etc. b) Web app 
  layout i) Configuration locations (logkit.xconf, 
  cocoon.xconf, etc.) a. 
  cocoon.xconf b. 
  logkit.xconf c. etc. 
  ii) Library locations and itemization a. 
  lib b. classes iii) 
  Other3) Architecture in depth a) 
  Generators i) What they are and why they 
  exist ii) Listing of existing generators, their usage, 
  and examples iii) How to write a custom generator (with 
  a reference to XSP) b) Transformers i) What 
  they are and why they exist ii) Listing of existing 
  transformers, their usage, and examples iii) How to 
  write a custom transformer ...repeat this model for the other 
  

XML - XSL Editors?

[Robert Simmons]

What are the best XML and XSLT editors on the 
market. I'm looking for something that is easy to use and offers the chance to 
edit XSL in a WYSIWYG style. I tried XML Spy but it is not so easy to use. I 
couldn't even figure out how to get an XSL preview to work properly. It wanted 
me to create an sps file in order to show the transformation but in their sps 
editor I couldn't even tell it to use a file that I had already written. Way 
weird. I also tried eXcelon with is much easier to use. I want to know what 
other options are out there. 

-- Robert

Re: Cocoon Job opps in Frankfurt, Germany

[Robert Simmons]

Interesting. Well I wouldn't have enough cocoon knowledge quite yet to do a
contract in it. Perhaps in a couple more months of study. I'm getting
decidedly sick of working for pennies for some stupid company more interested
in politics than product. I'm seriously considering branching out into
contracting when my book hits the market.

-- Robert

- Original Message -
From: Jeremy Aston [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Wednesday, January 29, 2003 1:33 AM
Subject: RE: Cocoon Job opps in Frankfurt, Germany


 These roles come up on jobserve.com, a UK based service for recruitment
 agencies.  I just have a savedsearch that emails me if Cocoon comes up as a
 keyword in each day's listings. If you follow the link below then you will
 note that all the agencies are UK based.  It is possible the client is
using
 agencies based in other European countries but Jobserve only really covers
 the UK and Australia based agencies.  Of course many of the UK agencies
have
 international sections, plus seeing as the role is in Frankfurt there is a
 good chance that the client may be an international org in the financial
 sector and thus might use UK based agencies by default.

  -Original Message-
  From: Robert Simmons [mailto:[EMAIL PROTECTED]]
  Sent: 28 January 2003 21:17
  To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
  Subject: Re: Cocoon Job opps in Frankfurt, Germany
 
 
  Strange that I did a search on gulp.de and monster.de for Cocoon
  and came up
  empty. Where are you guys hearing about these contracts?
 
  -- Robert
 
  - Original Message -
  From: Jeremy Aston [EMAIL PROTECTED]
  To: [EMAIL PROTECTED]
  Sent: Tuesday, January 28, 2003 3:32 PM
  Subject: RE: Cocoon Job opps in Frankfurt, Germany
 
 
   The UK rate has dropped significantly.  You are really looking
  at something
   like £35-£40 per hour (as opposed to £60-£70 ph in the past couple of
  years.
   $500ph is v. reasonable.
  
   At the end of the day these angencies never put a rate since
  they want to
   get as good a person as cheap as possible!
  
   jez
  
-Original Message-
From: Niclas Hedhman [mailto:[EMAIL PROTECTED]]
Sent: 28 January 2003 05:13
To: [EMAIL PROTECTED]
Subject: Re: Cocoon Job opps in Frankfurt, Germany
   
   
On Tuesday 28 January 2003 09:20, Jeremy Aston wrote:
 Hi,

 I keep seeing ads for contractors based in Frankfurt on a
  UK based job
 site...


http://www.it.jobserve.com/jobserve/searchresults.asp?jobType=*d=
   5order=R
   a nkpage=1q=cocoon
  
   They almost all list Rate: Market. What is that roughly? Just curious
  what
   it pays to be employed nowadays in this kind of field...
  
   Anyone willing to reveal?
  
   Me? I live in the low cost country so I charge only(?) around $500
per
   day,
   as consultant.
  
   Niclas
  
I have tried to get in there as a UK based person (and Cocooon book
co-author) but the company are 100% set on having an on site
  person and
  no
remote workers/software houses/cooperatives.  I can't move to
  Germany so
   am
out of the picture - bah!  These people have advertised
  reguarly over the
past 4-6 months so the work must be ongoing.
   
If anyone does get in there and find they can put in a word for
remote
workers (I will go to a couple of times a month for a couple of days)
  then
I'm here!
   
rgds
   
Jeremy
  
  
   -
   Please check that your question  has not already been answered in the
   FAQ before posting. http://xml.apache.org/cocoon/faq/index.html
  
   To unsubscribe, e-mail: [EMAIL PROTECTED]
   For additional commands, e-mail:   [EMAIL PROTECTED]
  
  
   __
   Do You Yahoo!?
   Everything you'll ever need on one web page
   from News and Sport to Email and Music Charts
   http://uk.my.yahoo.com
  
   -
   Please check that your question  has not already been answered in the
   FAQ before posting. http://xml.apache.org/cocoon/faq/index.html
  
   To unsubscribe, e-mail: [EMAIL PROTECTED]
   For additional commands, e-mail:   [EMAIL PROTECTED]
  
 
 
  -
  Please check that your question  has not already been answered in the
  FAQ before posting. http://xml.apache.org/cocoon/faq/index.html
 
  To unsubscribe, e-mail: [EMAIL PROTECTED]
  For additional commands, e-mail:   [EMAIL PROTECTED]
 


 __
 Do You Yahoo!?
 Everything you'll ever need on one web page
 from News and Sport to Email and Music Charts
 http://uk.my.yahoo.com

 -
 Please check that your question  has not already been answered in the
 FAQ before posting. http://xml.apache.org

Re: XML - XSL Editors?

[Robert Simmons]

Hmm, well my book has very little to do with cocoon. Its an advanced java
book. id be suprised if I mentioned more than a couple pages on cocoon.
Basically the book will talk about various java enterprise programing and I
will be using cocoon for the interface to the remote ejbs.

-- Robert

- Original Message -
From: Antonio Gallardo [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Wednesday, January 29, 2003 2:24 AM
Subject: Re: XML - XSL Editors?


 Hey?!

 Maybe and this article can be usefull for you and your work on the book:


http://community.jedit.org/modules.php?op=modloadname=newsfile=articlesid=
202

 By the way, what is the name of your future book?

 Antonio Gallardo.

 Antonio Gallardo dijo:
  Robert Simmons dijo:
  What are the best XML and XSLT editors on the market. I'm looking for
  something that is easy to use and offers the chance to edit XSL in a
  WYSIWYG style. I tried XML Spy but it is not so easy to use. I
  couldn't even figure out how to get an XSL preview to work properly.
  It wanted me to create an sps file in order to show the transformation
  but in their sps editor I couldn't even tell it to use a file that I
  had already written. Way weird. I also tried eXcelon with is much
  easier to use. I want to know what other options are out there.
 
  I dont know if this is the best. But I use jEdit to write Cocoon
  projects. It has a plug-in for XML, XSL highlighting and another plug-in
  for XSLT tranformation that make it very easy to check what your XSLT
  stylesheet do. Best of all is OpenSource and because it is coded in Java
  runs in any platform. Also for file Save you can configure the diferents
  char formats:
 
  ISO-8859-1, UTF-8 and more.
 
  There is also a plug-in to manage all your project.
 
  more info:
 
  http://www.jedit.org/
 
 
  Antonio Gallardo
 
 
 
  -
  Please check that your question  has not already been answered in the
  FAQ before posting. http://xml.apache.org/cocoon/faq/index.html
 
  To unsubscribe, e-mail: [EMAIL PROTECTED]
  For additional commands, e-mail:   [EMAIL PROTECTED]




 -
 Please check that your question  has not already been answered in the
 FAQ before posting. http://xml.apache.org/cocoon/faq/index.html

 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail:   [EMAIL PROTECTED]



-
Please check that your question  has not already been answered in the
FAQ before posting. http://xml.apache.org/cocoon/faq/index.html

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail:   [EMAIL PROTECTED]

Re: Cocoon Job opps in Frankfurt, Germany

[Robert Simmons]

Ahhh ... well ... Im a tad more expensive than that. =) I was gettign 80 USD
per hour in colorado before I moved to germany and took a perm job.

-- Robert

- Original Message -
From: Niclas Hedhman [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Wednesday, January 29, 2003 3:28 AM
Subject: Re: Cocoon Job opps in Frankfurt, Germany


On Tuesday 28 January 2003 22:32, Jeremy Aston wrote:
 The UK rate has dropped significantly.  You are really looking at something
 like £35-£40 per hour (as opposed to £60-£70 ph in the past couple of
 years. $500ph is v. reasonable.

Not ph, per day

Well, I live in a low-cost country (Malaysia) which is 50-75% lower cost of
living than northern Europe (Sweden, Germany is my experience) at large. On
top of that, I don't pay much income tax (5%).
Can really recommend it...


 At the end of the day these angencies never put a rate since they want to
 get as good a person as cheap as possible!

So do I ;o)  A average programmer here would cost me ~USD1000 a month, a top
notch one with special competency would be about twice that.


Niclas

 jez

  -Original Message-
  From: Niclas Hedhman [mailto:[EMAIL PROTECTED]]
  Sent: 28 January 2003 05:13
  To: [EMAIL PROTECTED]
  Subject: Re: Cocoon Job opps in Frankfurt, Germany
 
  On Tuesday 28 January 2003 09:20, Jeremy Aston wrote:
   Hi,
  
   I keep seeing ads for contractors based in Frankfurt on a UK based job
   site...
 
  http://www.it.jobserve.com/jobserve/searchresults.asp?jobType=*d=

 5order=R

 a nkpage=1q=cocoon

 They almost all list Rate: Market. What is that roughly? Just curious
 what it pays to be employed nowadays in this kind of field...

 Anyone willing to reveal?

 Me? I live in the low cost country so I charge only(?) around $500 per
 day,
 as consultant.

 Niclas

  I have tried to get in there as a UK based person (and Cocooon book
  co-author) but the company are 100% set on having an on site person and
  no remote workers/software houses/cooperatives.  I can't move to Germany
  so

 am

  out of the picture - bah!  These people have advertised reguarly over the
  past 4-6 months so the work must be ongoing.
 
  If anyone does get in there and find they can put in a word for remote
  workers (I will go to a couple of times a month for a couple of days)
  then I'm here!
 
  rgds
 
  Jeremy

 -
 Please check that your question  has not already been answered in the
 FAQ before posting. http://xml.apache.org/cocoon/faq/index.html

 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail:   [EMAIL PROTECTED]


 __
 Do You Yahoo!?
 Everything you'll ever need on one web page
 from News and Sport to Email and Music Charts
 http://uk.my.yahoo.com

 -
 Please check that your question  has not already been answered in the
 FAQ before posting. http://xml.apache.org/cocoon/faq/index.html

 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail:   [EMAIL PROTECTED]


-
Please check that your question  has not already been answered in the
FAQ before posting. http://xml.apache.org/cocoon/faq/index.html

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail:   [EMAIL PROTECTED]


-
Please check that your question  has not already been answered in the
FAQ before posting. http://xml.apache.org/cocoon/faq/index.html

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail:   [EMAIL PROTECTED]

Re: How to open 2 windows?

[Robert Simmons]

I had a great page today. The dumb shits put a JavaScript action on closing
the page that popped up a dialog saying if you want to stay at our page,
press ok. If you don't want to leave press cancel. The only way you could
leave that page was to kill the browser with the task manager. They may think
that is smart but I know one thing, Ill never buy a single product from them.
I don't remember the URL though so don't ask. =)

-- Robert


- Original Message -
From: Niclas Hedhman [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Wednesday, January 29, 2003 3:31 AM
Subject: Re: How to open 2 windows?


On Wednesday 29 January 2003 05:21, Robert Simmons wrote:
 Just a warning. There has been a study recently that quite well confirms
 that using popups in a commercial web site is a good way to drive traffic
 AWAY from that site. Personally, they annoy the shit out of me. If I really
 needed to get my penis enlarged Id look it up on google.de. Getting offered
 it from half the web sites on the internet could be bad for self
 confidence. =)

I agree ( where do you can you get the enlargement, you said?? ;o) )

A lot of people disables pop-ups, or (like me) have the browser ask me if I
want it. First one on a site, I consider ok. If commercial, then permenantly
turned off for that site.

I can't turn it off all the time, since some sincere sites are using this
technique, for other things than adverts.

Niclas

-
Please check that your question  has not already been answered in the
FAQ before posting. http://xml.apache.org/cocoon/faq/index.html

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail:   [EMAIL PROTECTED]


-
Please check that your question  has not already been answered in the
FAQ before posting. http://xml.apache.org/cocoon/faq/index.html

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail:   [EMAIL PROTECTED]

Re: XML - XSL Editors?

[Robert Simmons]

Lol .. the community is really good I think. Lots I havent figured out yet
thats irritating me though. Like why the forms sample in the cocoon war
doesnt match the same constructs as the XMLForm tutorial at
http://xml.apache.org/cocoon/howto/xmlform-wizard/howto-xmlform-wizard-3.html
.

Prob is that the interface is pretty irrelevant to my book but now Ive spent
two weeks workign on it .. UGH Beginnign to think I shoulda jsut gone
quick and dirty with JSP.

-- Robert

- Original Message -
From: Antonio Gallardo [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Wednesday, January 29, 2003 3:58 AM
Subject: Re: XML - XSL Editors?


 Will you be checking jedit.org? Please almost include it as a usefull
 link. I saw many books about Java and XML and all they use windows. And
 they totally ignore some of the wonderfull applications that people can
 use for free.

 I hope you will speak good about Cocoon and is fabulous community with
 7-24 support on-line. in your book. ;-)

 Best Regards,

 Antonio Gallardo.

 Robert Simmons dijo:
  Hmm, well my book has very little to do with cocoon. Its an advanced
  java book. id be suprised if I mentioned more than a couple pages on
  cocoon. Basically the book will talk about various java enterprise
  programing and I will be using cocoon for the interface to the remote
  ejbs.

 
  -- Robert
 
  - Original Message -
  From: Antonio Gallardo [EMAIL PROTECTED]
  To: [EMAIL PROTECTED]
  Sent: Wednesday, January 29, 2003 2:24 AM
  Subject: Re: XML - XSL Editors?
 
 
  Hey?!
 
  Maybe and this article can be usefull for you and your work on the
  book:
 
 
 
http://community.jedit.org/modules.php?op=modloadname=newsfile=articlesid=
  202
 
  By the way, what is the name of your future book?
 
  Antonio Gallardo.
 
  Antonio Gallardo dijo:
   Robert Simmons dijo:
   What are the best XML and XSLT editors on the market. I'm looking
  for something that is easy to use and offers the chance to edit XSL
  in a WYSIWYG style. I tried XML Spy but it is not so easy to use. I
  couldn't even figure out how to get an XSL preview to work
  properly. It wanted me to create an sps file in order to show the
  transformation but in their sps editor I couldn't even tell it to
  use a file that I had already written. Way weird. I also tried
  eXcelon with is much easier to use. I want to know what other
  options are out there.
  
   I dont know if this is the best. But I use jEdit to write Cocoon
  projects. It has a plug-in for XML, XSL highlighting and another
  plug-in for XSLT tranformation that make it very easy to check what
  your XSLT stylesheet do. Best of all is OpenSource and because it is
  coded in Java runs in any platform. Also for file Save you can
  configure the diferents char formats:
  
   ISO-8859-1, UTF-8 and more.
  
   There is also a plug-in to manage all your project.
  
   more info:
  
   http://www.jedit.org/
  
  
   Antonio Gallardo
  
  
  
   -
  Please check that your question  has not already been answered in
  the FAQ before posting.
  http://xml.apache.org/cocoon/faq/index.html
  
   To unsubscribe, e-mail:
  [EMAIL PROTECTED] For additional commands,
  e-mail:   [EMAIL PROTECTED]
 
 
 
 
  -
  Please check that your question  has not already been answered in the
  FAQ before posting. http://xml.apache.org/cocoon/faq/index.html
 
  To unsubscribe, e-mail: [EMAIL PROTECTED]
  For additional commands, e-mail:   [EMAIL PROTECTED]
 
 
 
  -
  Please check that your question  has not already been answered in the
  FAQ before posting. http://xml.apache.org/cocoon/faq/index.html
 
  To unsubscribe, e-mail: [EMAIL PROTECTED]
  For additional commands, e-mail:   [EMAIL PROTECTED]




 -
 Please check that your question  has not already been answered in the
 FAQ before posting. http://xml.apache.org/cocoon/faq/index.html

 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail:   [EMAIL PROTECTED]



-
Please check that your question  has not already been answered in the
FAQ before posting. http://xml.apache.org/cocoon/faq/index.html

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail:   [EMAIL PROTECTED]

XMLForms Versus Traditional HTML forms.

[Robert Simmons]

Greetings. I would like to know what people favor 
using. 

By my, admittedly limited, knowledge, the 
traditional HTML forms will still work with cocoon as the request will still 
have access to the data. Alternatively if I use XMLForms, I'm not sure how much 
learning effort Id have to invest. I read the XMLForm tutorial at http://xml.apache.org/cocoon/howto/xmlform-wizard/howto-xmlform-wizard-3.htmland 
am still a but unclear how I define how the form will be rendered. Does the user 
have control over that at all? If I use HTML forms then I would be imbedding a 
form into an XSL transform which would print out the form for the user. 


So basically I am asking what reasons are there to 
use XMLForms. 

-- Robert

Re: XMLForms Versus Traditional HTML forms.

[Robert Simmons]

Well actually I already have some generators running to fetch data from the
database. I have put that data in manually. Now I want to do it dynamically.
Simplicity wise I should use conventional forms, but I am not sure if that
is the right way to do it.

-- Robert

- Original Message -
From: Niclas Hedhman [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Wednesday, January 29, 2003 4:39 AM
Subject: Re: XMLForms Versus Traditional HTML forms.


On Wednesday 29 January 2003 11:16, Robert Simmons wrote:
 Greetings. I would like to know what people favor using.

 By my, admittedly limited, knowledge, the traditional HTML forms will still
 work with cocoon as the request will still have access to the data.
 Alternatively if I use XMLForms, I'm not sure how much learning effort Id
 have to invest. I read the XMLForm tutorial at
 http://xml.apache.org/cocoon/howto/xmlform-wizard/howto-xmlform-wizard-3.ht
ml and am still a but unclear how I define how the form will be rendered.
 Does the user have control over that at all? If I use HTML forms then I
 would be imbedding a form into an XSL transform which would print out the
 form for the user.

Slightly beyond my experience (I also use 'conventional' approach), but I see
it as;

1. The XMLForm generator creates a XML document of the POST request.
2. You can aggregate that with other XML documents, static or dynamic.
3. Feed that to the transformer(s).
4. Output

Meaning, the main advantage would be that you can do a fair amount of logic
on
the posted request in XSL (XSL is Turing complete, right?), without writing
any Java/XSP code. For some people (those who know XSL better than Java) that
is more power with less hazzle.

Niclas

-
Please check that your question  has not already been answered in the
FAQ before posting. http://xml.apache.org/cocoon/faq/index.html

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail:   [EMAIL PROTECTED]


-
Please check that your question  has not already been answered in the
FAQ before posting. http://xml.apache.org/cocoon/faq/index.html

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail:   [EMAIL PROTECTED]

Re: XMLForms Versus Traditional HTML forms.

[Robert Simmons]

Lets not lump cocoon to XMLForms or no XMLForms. Nor should we pick out any
other one feature of cocoon and say that if you don't use this feature you
shouldn't use cocoon. Nor should we say something like if you aren't going
pure XML XSL XSP that you shouldn't use cocoon. Cocoon is a toolkit and you
should pick those tools appropriate to your use. I chose cocoon over JSP
because I get the multi format content and clear separation of logic and
presentation. To me, a form is presentation.

As for multi-content, I could easily write a transform that converts things
to WML based forms. Its a matter of taste. Its also a matter of necessity. I
have already spent too long working on the presentation layer to my project
and I don't care to invest another month. I am not merely a learner but a
professional with tight deadlines. I'm not sure its worth the extra effort.
But the not sure is why I posted the question. If I was sure, I wouldn't
have posted.

Another thing is if it is in draft than that would be one reason for me to do
it the old way. Real business applications require something that works. That
isn't always the same thing as something that is cool.

-- Robert

- Original Message -
From: Kirchhoff, Lars [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Wednesday, January 29, 2003 5:09 AM
Subject: AW: XMLForms Versus Traditional HTML forms.


But why you need then cocoon for? If you just use traditional html
isn't cocoon a bit to much? i'm just curios? Wouldn't it then better
just use jsp or something similar?

The main advantage of cocoon and xmlform for me is still to create
a xml document, which then can be transformed through the pipeline
in nearly every possible format. This means creating applications or
websites, which can serve multiple devices.

Especially for xmlforms  there is a strong seperation of concerns,
which in the first moment and for small application is a bit to
much, but helps to divide the programming of the actual dataflow and
business logic from the presentation layer and keeps the code
manageable. I don't like to mix up any program code with tags from
either xml or html. That's why I use and tried xmlform and don't
feel comfortable with xsp.

Of course you can transform the xmlform tags to html form tags,
as long as there are not to many browser out, which are
understanding xforms, which are still in draft.

BTW does anybody know an reference implementation of an xforms
browser?

regards
Lars


 -Ursprüngliche Nachricht-
 Von: Robert Simmons [mailto:[EMAIL PROTECTED]]
 Gesendet: Mittwoch, 29. Januar 2003 11:50
 An: [EMAIL PROTECTED]
 Betreff: Re: XMLForms Versus Traditional HTML forms.


 Well actually I already have some generators running to fetch
 data from the
 database. I have put that data in manually. Now I want to do
 it dynamically.
 Simplicity wise I should use conventional forms, but I am
 not sure if that
 is the right way to do it.

 -- Robert

 - Original Message -
 From: Niclas Hedhman [EMAIL PROTECTED]
 To: [EMAIL PROTECTED]
 Sent: Wednesday, January 29, 2003 4:39 AM
 Subject: Re: XMLForms Versus Traditional HTML forms.


 On Wednesday 29 January 2003 11:16, Robert Simmons wrote:
  Greetings. I would like to know what people favor using.
 
  By my, admittedly limited, knowledge, the traditional HTML
 forms will still
  work with cocoon as the request will still have access to the data.
  Alternatively if I use XMLForms, I'm not sure how much
 learning effort Id
  have to invest. I read the XMLForm tutorial at
 
 http://xml.apache.org/cocoon/howto/xmlform-wizard/howto-xmlfor
m-wizard-3.ht
ml and am still a but unclear how I define how the form will be rendered.
 Does the user have control over that at all? If I use HTML forms then I
 would be imbedding a form into an XSL transform which would print out the
 form for the user.

Slightly beyond my experience (I also use 'conventional' approach), but I
see
it as;

1. The XMLForm generator creates a XML document of the POST request.
2. You can aggregate that with other XML documents, static or dynamic.
3. Feed that to the transformer(s).
4. Output

Meaning, the main advantage would be that you can do a fair amount of logic
on
the posted request in XSL (XSL is Turing complete, right?), without writing
any Java/XSP code. For some people (those who know XSL better than Java)
that
is more power with less hazzle.

Niclas

-
Please check that your question  has not already been answered in the
FAQ before posting. http://xml.apache.org/cocoon/faq/index.html

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail:   [EMAIL PROTECTED]


-
Please check that your question  has not already been answered in the
FAQ before posting. http://xml.apache.org/cocoon/faq/index.html

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e

Re: XMLForms Versus Traditional HTML forms.

[Robert Simmons]

Well, if you want my advice stay away from entity beans. They are evil in the
extreme. As for forms being in draft, that bothers me. I do, however, have
allot of actions I need to write and some common method of outputting the
forms automatically based on the command being run would be interesting to
me. I might take a hybrid approach here.

What Id like to have happen is that a user decides to execute a command which
hits a generator with the name of the command and any initialization
parameters. Then the generator spits out a document containing the structure
of needed information from the form. Then the style sheets take over and
render the forms and then the user can submit them. To do this I might just
borrow the XML form namespace and have the generator spit out valid XML form
documents.

Just thinking out loud.

-- Robert


- Original Message -
From: Geoff Howard [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Wednesday, January 29, 2003 5:59 AM
Subject: RE: XMLForms Versus Traditional HTML forms.


  -Original Message-
  From: Robert Simmons [mailto:[EMAIL PROTECTED]]
 
  As for multi-content, I could easily write a transform that
  converts things
  to WML based forms. Its a matter of taste. Its also a matter of
  necessity. I
  have already spent too long working on the presentation layer to
  my project
  and I don't care to invest another month. I am not merely a learner but a
  professional with tight deadlines. I'm not sure its worth the
  extra effort.
  But the not sure is why I posted the question. If I was sure, I
wouldn't
  have posted.

 One potential upside is the fact that XMLForms uses beans for the datamodel
 (I think).  that being the case, I have assumed there'd be a way to let
 ejb's fill that role (which based on past discussions I assume you're using
 here) and you'd get the binding to/from the form for free as you can in
jsp.

 
  Another thing is if it is in draft than that would be one reason
  for me to do
  it the old way. Real business applications require something that
  works. That
  isn't always the same thing as something that is cool.

 I've not used xmlform yet because of the draft status and the time to
 learn - same issues you raise.  Looks quite promising though, especially if
 the bean hunch pans out.



 -
 Please check that your question  has not already been answered in the
 FAQ before posting. http://xml.apache.org/cocoon/faq/index.html

 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail:   [EMAIL PROTECTED]



-
Please check that your question  has not already been answered in the
FAQ before posting. http://xml.apache.org/cocoon/faq/index.html

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail:   [EMAIL PROTECTED]

Re: XMLForms Versus Traditional HTML forms.

[Robert Simmons]

Theoretically, but if you were trying to deliver an action driven system,
this would be difficult. You would have to validate inside the pipeline and
that would be problematic for a number of reasons. You would have to write
some sort of custom validator. The problem here is that configuration is
being done at the sitemap level and that is resource intensive. IT would be
much more efficient if you could drop in a set of beans, have a Java class
read them via introspection and then generate forms based upon the needs of
that command. Then you would have a command driven architecture that would be
quickly adaptable. all you have to do is drop in another command (a bean
object) and viola, a new form gets spit out the far end. I will screw with
this and see if I can get it to work. Call it reflexive form generation =)

-- Robert

- Original Message -
From: Geoff Howard [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Wednesday, January 29, 2003 6:06 AM
Subject: RE: XMLForms Versus Traditional HTML forms.


 also there's supposed to be support for validation, error handling, and
 persistence across calls, right?

  -Original Message-
  From: Geoff Howard [mailto:[EMAIL PROTECTED]]
  Sent: Tuesday, January 28, 2003 11:59 PM
  To: [EMAIL PROTECTED]
  Subject: RE: XMLForms Versus Traditional HTML forms.
 
 
   -Original Message-
   From: Robert Simmons [mailto:[EMAIL PROTECTED]]
  
   As for multi-content, I could easily write a transform that
   converts things
   to WML based forms. Its a matter of taste. Its also a matter of
   necessity. I
   have already spent too long working on the presentation layer to
   my project
   and I don't care to invest another month. I am not merely a
  learner but a
   professional with tight deadlines. I'm not sure its worth the
   extra effort.
   But the not sure is why I posted the question. If I was sure,
  I wouldn't
   have posted.
 
  One potential upside is the fact that XMLForms uses beans for the
  datamodel
  (I think).  that being the case, I have assumed there'd be a way to let
  ejb's fill that role (which based on past discussions I assume
  you're using
  here) and you'd get the binding to/from the form for free as you
  can in jsp.
 
  
   Another thing is if it is in draft than that would be one reason
   for me to do
   it the old way. Real business applications require something that
   works. That
   isn't always the same thing as something that is cool.
 
  I've not used xmlform yet because of the draft status and the time to
  learn - same issues you raise.  Looks quite promising though,
  especially if
  the bean hunch pans out.
 
 
 
  -
  Please check that your question  has not already been answered in the
  FAQ before posting. http://xml.apache.org/cocoon/faq/index.html
 
  To unsubscribe, e-mail: [EMAIL PROTECTED]
  For additional commands, e-mail:   [EMAIL PROTECTED]
 
 
 


 -
 Please check that your question  has not already been answered in the
 FAQ before posting. http://xml.apache.org/cocoon/faq/index.html

 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail:   [EMAIL PROTECTED]



-
Please check that your question  has not already been answered in the
FAQ before posting. http://xml.apache.org/cocoon/faq/index.html

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail:   [EMAIL PROTECTED]

Re: XMLForms Versus Traditional HTML forms.

[Robert Simmons]

Hmm .. I cant seem to even find the samples on my cocoon installation. Are
they not in the current binary distribution ?

-- Robert

- Original Message -
From: Kirchhoff, Lars [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Wednesday, January 29, 2003 5:09 AM
Subject: AW: XMLForms Versus Traditional HTML forms.


But why you need then cocoon for? If you just use traditional html
isn't cocoon a bit to much? i'm just curios? Wouldn't it then better
just use jsp or something similar?

The main advantage of cocoon and xmlform for me is still to create
a xml document, which then can be transformed through the pipeline
in nearly every possible format. This means creating applications or
websites, which can serve multiple devices.

Especially for xmlforms  there is a strong seperation of concerns,
which in the first moment and for small application is a bit to
much, but helps to divide the programming of the actual dataflow and
business logic from the presentation layer and keeps the code
manageable. I don't like to mix up any program code with tags from
either xml or html. That's why I use and tried xmlform and don't
feel comfortable with xsp.

Of course you can transform the xmlform tags to html form tags,
as long as there are not to many browser out, which are
understanding xforms, which are still in draft.

BTW does anybody know an reference implementation of an xforms
browser?

regards
Lars


 -Ursprüngliche Nachricht-
 Von: Robert Simmons [mailto:[EMAIL PROTECTED]]
 Gesendet: Mittwoch, 29. Januar 2003 11:50
 An: [EMAIL PROTECTED]
 Betreff: Re: XMLForms Versus Traditional HTML forms.


 Well actually I already have some generators running to fetch
 data from the
 database. I have put that data in manually. Now I want to do
 it dynamically.
 Simplicity wise I should use conventional forms, but I am
 not sure if that
 is the right way to do it.

 -- Robert

 - Original Message -
 From: Niclas Hedhman [EMAIL PROTECTED]
 To: [EMAIL PROTECTED]
 Sent: Wednesday, January 29, 2003 4:39 AM
 Subject: Re: XMLForms Versus Traditional HTML forms.


 On Wednesday 29 January 2003 11:16, Robert Simmons wrote:
  Greetings. I would like to know what people favor using.
 
  By my, admittedly limited, knowledge, the traditional HTML
 forms will still
  work with cocoon as the request will still have access to the data.
  Alternatively if I use XMLForms, I'm not sure how much
 learning effort Id
  have to invest. I read the XMLForm tutorial at
 
 http://xml.apache.org/cocoon/howto/xmlform-wizard/howto-xmlfor
m-wizard-3.ht
ml and am still a but unclear how I define how the form will be rendered.
 Does the user have control over that at all? If I use HTML forms then I
 would be imbedding a form into an XSL transform which would print out the
 form for the user.

Slightly beyond my experience (I also use 'conventional' approach), but I
see
it as;

1. The XMLForm generator creates a XML document of the POST request.
2. You can aggregate that with other XML documents, static or dynamic.
3. Feed that to the transformer(s).
4. Output

Meaning, the main advantage would be that you can do a fair amount of logic
on
the posted request in XSL (XSL is Turing complete, right?), without writing
any Java/XSP code. For some people (those who know XSL better than Java)
that
is more power with less hazzle.

Niclas

-
Please check that your question  has not already been answered in the
FAQ before posting. http://xml.apache.org/cocoon/faq/index.html

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail:   [EMAIL PROTECTED]


-
Please check that your question  has not already been answered in the
FAQ before posting. http://xml.apache.org/cocoon/faq/index.html

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail:   [EMAIL PROTECTED]

-
Please check that your question  has not already been answered in the
FAQ before posting. http://xml.apache.org/cocoon/faq/index.html

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail:   [EMAIL PROTECTED]


-
Please check that your question  has not already been answered in the
FAQ before posting. http://xml.apache.org/cocoon/faq/index.html

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail:   [EMAIL PROTECTED]

Re: XMLForms Versus Traditional HTML forms.

[Robert Simmons]

If there is any overlap, I'm not aware of it. Cocoon is XML centric and not
Java centric. What I'm thinking of is a way to drive XML with Java. So if you
had a bean like ...


public class ChangeAge extends Command {
  private int age;
  private String name;

 // getter and setters.
}

Than a java class would spit out the following:

xf:form id=ChangeAge view= action=ChangeAge.html

xf:captionRegistration/xf:caption

error
  xf:violations class=error/
/error

xf:textbox ref=/name
xf:captionName:/xf:caption
xf:violations class=error/
/xf:textbox

xf:textbox ref=/age
xf:captionage/xf:caption
xf:helpNew age/xf:help
xf:violations class=error/
/xf:textbox

 xf:submit id=submit class=button
  xf:captionChange Age/xf:caption
 /xf:submit

  /xf:form

And then the user could use XSLT to dynamically transform the form into what
they wanted.  The problem is that the sitemap could no longer be effectively
used to configure individual actions because they would largely depend upon
what actions exist in the object model of the beans. But I do have a few
ideas. ;)

-- Robert

- Original Message -
From: Geoff Howard [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Wednesday, January 29, 2003 6:29 AM
Subject: RE: XMLForms Versus Traditional HTML forms.


  As for forms being in draft, that bothers me.

 Don't rely on my word here - that is my memory of what I learned (and
 someone just said that tonight, too right?) looking into xmlform again
about
 2-3 months ago, so things may have moved on.

  I do, however, have
  allot of actions I need to write and some common method of outputting the
  forms automatically based on the command being run would be interesting
to
  me. I might take a hybrid approach here.

 I have recently been converted to the modular database actions which may
 provide some inspiration and groundwork for actions hitting session beans
 (assuming that's what you meant).  One xml config file with db table
 structure and a few other tidbits handles my insert, update and deletes
(for
 simple cases) with no coding.  I think they're in 2.0.4 but not positive.
 Modular in this case refers to the use of input modules.  Christian Haul
 on the list appears to be the author/resident guru on both.

 As a side note, I recently worked with Chris to make some trivial
 modifications that allow multipart form file uploads to populate db blobs
 automatically.

 
  What Id like to have happen is that a user decides to execute a
  command which
  hits a generator with the name of the command and any initialization
  parameters. Then the generator spits out a document containing
  the structure
  of needed information from the form. Then the style sheets take over and
  render the forms and then the user can submit them. To do this I
  might just
  borrow the XML form namespace and have the generator spit out
  valid XML form
  documents.

 This sounds great - is there no overlap with the current stuff?

 Geoff



 -
 Please check that your question  has not already been answered in the
 FAQ before posting. http://xml.apache.org/cocoon/faq/index.html

 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail:   [EMAIL PROTECTED]



-
Please check that your question  has not already been answered in the
FAQ before posting. http://xml.apache.org/cocoon/faq/index.html

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail:   [EMAIL PROTECTED]

Re: XMLForms Versus Traditional HTML forms.

[Robert Simmons]

Yeah .. well I meant the XMLForms samples. And I still haven't found those.
The other samples I found easily.

-- Robert

- Original Message -
From: Niclas Hedhman [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Wednesday, January 29, 2003 6:25 AM
Subject: Re: XMLForms Versus Traditional HTML forms.


On Wednesday 29 January 2003 13:11, Robert Simmons wrote:
 Hmm .. I cant seem to even find the samples on my cocoon installation. Are
 they not in the current binary distribution ?

Provided you have dropped the cocoon.war into $TOMCAT_HOME/webapps, you
should
find samples in;

$TOMCAT_HOME/webapps/cocoon/samples/


Niclas

 -- Robert

 - Original Message -
 From: Kirchhoff, Lars [EMAIL PROTECTED]
 To: [EMAIL PROTECTED]
 Sent: Wednesday, January 29, 2003 5:09 AM
 Subject: AW: XMLForms Versus Traditional HTML forms.


 But why you need then cocoon for? If you just use traditional html
 isn't cocoon a bit to much? i'm just curios? Wouldn't it then better
 just use jsp or something similar?

 The main advantage of cocoon and xmlform for me is still to create
 a xml document, which then can be transformed through the pipeline
 in nearly every possible format. This means creating applications or
 websites, which can serve multiple devices.

 Especially for xmlforms  there is a strong seperation of concerns,
 which in the first moment and for small application is a bit to
 much, but helps to divide the programming of the actual dataflow and
 business logic from the presentation layer and keeps the code
 manageable. I don't like to mix up any program code with tags from
 either xml or html. That's why I use and tried xmlform and don't
 feel comfortable with xsp.

 Of course you can transform the xmlform tags to html form tags,
 as long as there are not to many browser out, which are
 understanding xforms, which are still in draft.

 BTW does anybody know an reference implementation of an xforms
 browser?

 regards
 Lars

  -Ursprüngliche Nachricht-
  Von: Robert Simmons [mailto:[EMAIL PROTECTED]]
  Gesendet: Mittwoch, 29. Januar 2003 11:50
  An: [EMAIL PROTECTED]
  Betreff: Re: XMLForms Versus Traditional HTML forms.
 
 
  Well actually I already have some generators running to fetch
  data from the
  database. I have put that data in manually. Now I want to do
  it dynamically.
  Simplicity wise I should use conventional forms, but I am
  not sure if that
  is the right way to do it.
 
  -- Robert
 
  - Original Message -
  From: Niclas Hedhman [EMAIL PROTECTED]
  To: [EMAIL PROTECTED]
  Sent: Wednesday, January 29, 2003 4:39 AM
  Subject: Re: XMLForms Versus Traditional HTML forms.
 
  On Wednesday 29 January 2003 11:16, Robert Simmons wrote:
   Greetings. I would like to know what people favor using.
  
   By my, admittedly limited, knowledge, the traditional HTML
 
  forms will still
 
   work with cocoon as the request will still have access to the data.
   Alternatively if I use XMLForms, I'm not sure how much
 
  learning effort Id
 
   have to invest. I read the XMLForm tutorial at
 
  http://xml.apache.org/cocoon/howto/xmlform-wizard/howto-xmlfor

 m-wizard-3.ht

 ml and am still a but unclear how I define how the form will be rendered.
  Does the user have control over that at all? If I use HTML forms then I
  would be imbedding a form into an XSL transform which would print out the
  form for the user.

 Slightly beyond my experience (I also use 'conventional' approach), but I
 see
 it as;

 1. The XMLForm generator creates a XML document of the POST request.
 2. You can aggregate that with other XML documents, static or dynamic.
 3. Feed that to the transformer(s).
 4. Output

 Meaning, the main advantage would be that you can do a fair amount of logic
 on
 the posted request in XSL (XSL is Turing complete, right?), without writing
 any Java/XSP code. For some people (those who know XSL better than Java)
 that
 is more power with less hazzle.

 Niclas

 -
 Please check that your question  has not already been answered in the
 FAQ before posting. http://xml.apache.org/cocoon/faq/index.html

 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail:   [EMAIL PROTECTED]


 -
 Please check that your question  has not already been answered in the
 FAQ before posting. http://xml.apache.org/cocoon/faq/index.html

 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail:   [EMAIL PROTECTED]

 -
 Please check that your question  has not already been answered in the
 FAQ before posting. http://xml.apache.org/cocoon/faq/index.html

 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail:   [EMAIL PROTECTED]


 -
 Please check that your

Re: Cocoon Job opps in Frankfurt, Germany

[Robert Simmons]

Yes, my rates had to fall recently by about 12k Euros per year permanent. Its
really irritating. Don't worry, it will pick back up soon.

-- Robert

- Original Message -
From: Jeremy Aston [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Wednesday, January 29, 2003 6:49 AM
Subject: RE: Cocoon Job opps in Frankfurt, Germany




 snip/
 
  On Tuesday 28 January 2003 22:32, Jeremy Aston wrote:
   The UK rate has dropped significantly.  You are really looking
  at something
   like £35-£40 per hour (as opposed to £60-£70 ph in the past couple of
   years. $500ph is v. reasonable.
 
  Not ph, per day
 

 Yup - I meant per day.  $500 is approx £300 = £37.5ph based on 8hr day.
 Which for an experienced web app developer with Java/XML/XSLT and
experience
 of Cocoon is reasonable from an employers perspective.

 Having said that the best the same could hope to get at the moment in a
perm
 role would be around 35k per annum and they would be expected to do a lead
 role for that.  There is such a glut of coders, lack of roles and tight
 belts in the UK at the moment that even good guys might have to settle for
 less than 30k - the best could easily get twice that a couple of years
 ago...

 snip/


 jez


 __
 Do You Yahoo!?
 Everything you'll ever need on one web page
 from News and Sport to Email and Music Charts
 http://uk.my.yahoo.com

 -
 Please check that your question  has not already been answered in the
 FAQ before posting. http://xml.apache.org/cocoon/faq/index.html

 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail:   [EMAIL PROTECTED]



-
Please check that your question  has not already been answered in the
FAQ before posting. http://xml.apache.org/cocoon/faq/index.html

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail:   [EMAIL PROTECTED]

Getting a generator class to reload.

[Robert Simmons]

I am working to create a custom generator and I 
have deployed my WAR in exploded format. The problem is that now when I change 
the class file that the generator uses, cocoon keeps using the old class file. 
How can I get the classloader in cocoon to reload the class?

-- Robert

Re: Getting a generator class to reload.

[Robert Simmons]

Nope .. didn't work. Still has the old class cached. I hope I don have to
redeploy the whole damn thing every time I update a class.

-- Robert

- Original Message -
From: Niclas Hedhman [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Monday, January 27, 2003 9:20 AM
Subject: Re: Getting a generator class to reload.


On Monday 27 January 2003 16:21, Robert Simmons wrote:
 I am working to create a custom generator and I have deployed my WAR in
 exploded format. The problem is that now when I change the class file that
 the generator uses, cocoon keeps using the old class file. How can I get
 the classloader in cocoon to reload the class?

When that happens, I touch the sitemap. Always works.

-
Please check that your question  has not already been answered in the
FAQ before posting. http://xml.apache.org/cocoon/faq/index.html

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail:   [EMAIL PROTECTED]


-
Please check that your question  has not already been answered in the
FAQ before posting. http://xml.apache.org/cocoon/faq/index.html

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail:   [EMAIL PROTECTED]

Re: Getting a generator class to reload.

[Robert Simmons]

Hmm ... never needed to mess with tomcat settings before ... I will look
around. Since tomcat is bundled with JBoss, I don't know were this stuff
would be.

-- Robert

- Original Message -
From: Luca Morandini [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Monday, January 27, 2003 9:31 AM
Subject: RE: Getting a generator class to reload.


 Robert,

 I guess you've alread set the reloadable=true in the context element of
your Tomcat configuration (or something to that effect in
 the servlet container of choice), haven't you ?

 Regards,

 -
Luca Morandini
GIS Consultant
   [EMAIL PROTECTED]
 http://utenti.tripod.it/lmorandini/index.html
 -

 -Original Message-
 From: Robert Simmons [mailto:[EMAIL PROTECTED]]
 Sent: Monday, January 27, 2003 9:21 AM
 To: Cocoon Users
 Subject: Getting a generator class to reload.


 I am working to create a custom generator and I have deployed my WAR in
exploded format. The problem is that now when I change the
 class file that the generator uses, cocoon keeps using the old class file.
How can I get the classloader in cocoon to reload the
 class?

 -- Robert


 -
 Please check that your question  has not already been answered in the
 FAQ before posting. http://xml.apache.org/cocoon/faq/index.html

 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail:   [EMAIL PROTECTED]



-
Please check that your question  has not already been answered in the
FAQ before posting. http://xml.apache.org/cocoon/faq/index.html

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail:   [EMAIL PROTECTED]

Re: Getting a generator class to reload.

[Robert Simmons]

Hmm, well I'm running tomcat merges with JBoss so its probably a different
story here. I'm not even sure I can get to the tomcat reload mechanism. I
tried the link the user posted on my machine and it didn't go. Additionally,
I don't even want the entire cocoon app to restart when I change one
generator class. That's what I was trying to avoid by having an exploded war.
If I wanted it to reload every time, Id deploy an unexploded war. I just want
cocoon to reload this particular class.

-- Robert


- Original Message -
From: SAXESS - Hussayn Dabbous [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Monday, January 27, 2003 10:13 AM
Subject: Re: Getting a generator class to reload.


 Assuming you run tomcat:

 When you enable reloadable='true' in your Context the
 whole webapp should restart every time a class is changed.
 Once in a while i get unpredictable behaviour like
 webapp doesnt restart, or hangs during restart or even
 VM exits.
 I never figured out, what my container complains about,
 but in general i'm happy with reloadable='true' during
 development. For production it would be a very bad idea
 to enable this feature ;-)

 I heard rumours about the possibility with tomcat to
 only reload the changed resources while keeping the webapp
 up and running, but i never found the howto...

 regards, hussayn


 Robert Simmons wrote:
  Nope .. didn't work. Still has the old class cached. I hope I don have to
  redeploy the whole damn thing every time I update a class.
 
  -- Robert
 
  - Original Message -
  From: Niclas Hedhman [EMAIL PROTECTED]
  To: [EMAIL PROTECTED]
  Sent: Monday, January 27, 2003 9:20 AM
  Subject: Re: Getting a generator class to reload.
 
 
  On Monday 27 January 2003 16:21, Robert Simmons wrote:
 
 I am working to create a custom generator and I have deployed my WAR in
 exploded format. The problem is that now when I change the class file
that
 the generator uses, cocoon keeps using the old class file. How can I get
 the classloader in cocoon to reload the class?
 
 
  When that happens, I touch the sitemap. Always works.
 
  -
  Please check that your question  has not already been answered in the
  FAQ before posting. http://xml.apache.org/cocoon/faq/index.html
 
  To unsubscribe, e-mail: [EMAIL PROTECTED]
  For additional commands, e-mail:   [EMAIL PROTECTED]
 
 
  -
  Please check that your question  has not already been answered in the
  FAQ before posting. http://xml.apache.org/cocoon/faq/index.html
 
  To unsubscribe, e-mail: [EMAIL PROTECTED]
  For additional commands, e-mail:   [EMAIL PROTECTED]
 

 --
 Dr. Hussayn Dabbous
 SAXESS Software Design GmbH
 Neuenhöfer Allee 125
 50935 Köln
 Telefon: +49-221-56011-0
 Fax: +49-221-56011-20
 E-Mail:  [EMAIL PROTECTED]


 -
 Please check that your question  has not already been answered in the
 FAQ before posting. http://xml.apache.org/cocoon/faq/index.html

 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail:   [EMAIL PROTECTED]



-
Please check that your question  has not already been answered in the
FAQ before posting. http://xml.apache.org/cocoon/faq/index.html

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail:   [EMAIL PROTECTED]

Re: Cocoon 2.1 the usability release?

[Robert Simmons]

Oh well, I don't mean to be caustic but developers that work for me that
don't document get yelled at allot. I don't tolerate it. Its quite easy to
javadoc as you go and a massive pain in the ass to do it after the fact. With
the lack of documentation though, it does make one wonder what is lurking in
there that isn't needed anymore. But then I still think a usability focused
release would be a good thing. Hell, Id be willing to do the Log4j conversion
when I get done with my current project.

-- Robert


- Original Message -
From: Jeff Turner [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Monday, January 27, 2003 1:00 PM
Subject: Re: Cocoon 2.1 the usability release?


 On Mon, Jan 27, 2003 at 01:28:30AM +0100, Robert Simmons wrote:
  One other feature would be more extensive documentation in the API. To
  see what I mean, look at the class level documentation on
  LinkSerializer. Hrmm ... I still don't know what it does. Perhaps its
  time to bust people's chops to document things.

 I'm glad to see you consider good documentation a priority.  I have
 commit access to the relevant repositories, and I am willing to document
 anything you like for a very reasonable $A10/class.  Please contact me
 offlist for further information.

 Of course... I ASSUME you'd be willing to pay someone, because how else
 could you get volunteers to scratch YOUR particular itch? :)


 --Jeff

  What I meant about the component documentation, by the way, is
  basically what is listed if you look at the package page in the API for
  the various components.
 
  -- Robert
 ...

 -
 Please check that your question  has not already been answered in the
 FAQ before posting. http://xml.apache.org/cocoon/faq/index.html

 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail:   [EMAIL PROTECTED]



-
Please check that your question  has not already been answered in the
FAQ before posting. http://xml.apache.org/cocoon/faq/index.html

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail:   [EMAIL PROTECTED]

Re: Cocoon User Meeting - Wuerzburg - Germany

[Robert Simmons]

I currently live in Munich and I believe in this technology enough to
consider beating it in the head until its user friendly. =) After I get my
book done (almost damnit!!!) I will be volunteering to work on some usability
stuff if they will have me.

-- Robert

- Original Message -
From: Michael Mertel [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Monday, January 27, 2003 9:46 AM
Subject: Cocoon User Meeting - Wuerzburg - Germany


 Hi there,

 are there any cocoon users in the wuerzburg area to meet
 on a regular/nonregular base ... we can provide the space
 for up to 10-15 people.

 Beginners (like me) and advanced users are more than welcome.

 If this sounds good to anyone, please drop me a note at
 [EMAIL PROTECTED]

 Sorry for bothering all the other cocoon users around, but
 thats currently all what I can give back to the community.

 --Michael


 -
 Please check that your question  has not already been answered in the
 FAQ before posting. http://xml.apache.org/cocoon/faq/index.html

 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail:   [EMAIL PROTECTED]



-
Please check that your question  has not already been answered in the
FAQ before posting. http://xml.apache.org/cocoon/faq/index.html

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail:   [EMAIL PROTECTED]

Re: newbies documentation - yet another wiki?

[Robert Simmons]

What I don't get is why not put the new documentation in cocoon distribution?
Everything else is in there: *smirk* Cocoon is built for web publishing, we
could conspire to write volumes right in the product. Which reminds me,
anyone know a word processor that saves primarily in XML and is good?

-- Robert

- Original Message -
From: Bertrand Delacretaz [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Monday, January 27, 2003 10:14 AM
Subject: Re: newbies documentation - yet another wiki?


 Hi Hussayn,

 I mostly agree with your point of view, except on the separate wiki
 thing. (And by the way, thanks a lot for your less talking, more doing
 approach!)

 What worries me *a lot* with starting yet another documentation site is
 the dispersion of resources - wouldn't it be much more efficient to have
 you, Derek and possibly others joing the (mythical) Cocoon docs team
 with the aim of creating these newbies docs?

 See also http://wiki.cocoondev.org/Wiki.jsp?page=CocoonDocsPlan, I think
 your concept can fit nicely into this.

 I'm convinced that it is possible to create the newbies competence
 center that you mention *inside* the existing wiki - a well-designed
 start page and navigation should help newbies find their way.

 Maybe this needs some improvements to the existing wiki system, to help
 newbies find pages that are targeted for them, namely:

 a) Being able to search the wiki for NCC pages only or everything so
 that newbies are not distracted by deep technical discussions.

 b) Being able to clearly label pages as being part of the NCC, different
 color, icons or something.

 This might well be possible with JSPwiki, maybe by writing some kind of
 extension? We need to ask Steven or the JSPWiki folks if you think this
 is worth studying.

 What do you think?
 Join the party, or throw yet another one? :-)

 -Bertrand


 -
 Please check that your question  has not already been answered in the
 FAQ before posting. http://xml.apache.org/cocoon/faq/index.html

 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail:   [EMAIL PROTECTED]



-
Please check that your question  has not already been answered in the
FAQ before posting. http://xml.apache.org/cocoon/faq/index.html

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail:   [EMAIL PROTECTED]

Re: Single JAR with all the libs?

[Robert Simmons]

Does anyone know how, in Ant, to take a fileset and convert it to a space
delimited list of files?

-- Robert

- Original Message -
From: Luca Morandini [EMAIL PROTECTED]
To: Cocoon-users [EMAIL PROTECTED]
Sent: Sunday, January 26, 2003 10:45 AM
Subject: RE: Single JAR with all the libs?


 Robert,

 well, if I were you I'd tweak the build.xml to tailor it to your needs, and
just tell the readers to:

 1) replace the native build.xml with yours
 2) run it
 3) deploy the resulting WAR.

 I have no idea of alternative approaches... sorry :(

 Regards,

 -
Luca Morandini
GIS Consultant
   [EMAIL PROTECTED]
 http://utenti.tripod.it/lmorandini/index.html
 -


  -Original Message-
  From: Robert Simmons [mailto:[EMAIL PROTECTED]]
  Sent: Sunday, January 26, 2003 9:57 AM
  To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
  Subject: Re: Single JAR with all the libs?
 
 
  Ya I know that. I'm not talking about the prebuilt, distributed web
  application. I am trying to develop a strategy for other users to be able
to
  use cocoon from within JBoss without having to leap through 15 hoops. So
I
  basically want a way I can build cocoon libs and then in each war file I
make
  that uses cocoon, I merely need the config files and only things
pertaining
  to my stuff and not to cocoon in general.
 
  Getting the kitchen sink build working was a matter of just dropping it
in
  JBoss. Now I want to go further and make other applications with the
product.
  Right now Id have to resort to telling readers to download cocoon, unpack
it,
  rewrite their manifests to include the Cocoon-Libs section, then run the
  build which should convert the old libs to the new location and then
install
  cocoon.
 
  Picture this scenario. You want to use cocoon for a front end to a
powerful
  EJB based system. Your readers of your book want to download your source
code
  and install it and get it running. They need a simple process. Right now
the
  process is download the kitchen sink version, figure out what the hell
you
  don't need, repack everything and deploy it. Not functional for users of
the
  product.
 
  Therefore I keep rolling back around to having a single jar that I can
drop
  in JBoss like an oversized golf ball and call cocoon installed and
ready
  for users to deploy their OWN war files that use cocoon rather than
asking
  them to modify cocoon's war.
 
  I'm not sure if I'm making sense here.
 
  -- Robert
 
 
  - Original Message -
  From: Luca Morandini [EMAIL PROTECTED]
  To: [EMAIL PROTECTED]
  Sent: Sunday, January 26, 2003 9:41 AM
  Subject: RE: Single JAR with all the libs?
 
 
   Robert,
  
   I'm not sure I've understood your question, but I like to give it a
try.
  
   When you build Cocoon, it produces a WAR file, you just:
  
   1) put the WAR under the webapps of your servlet container
   2) re-start the container
  
   The you can deploy your Cocoon app under the mount directory, hence
avoid
  editing the general sitemap.xmap (the one in
   webapps/cocoon).
  
   Regards,
  
   -
  Luca Morandini
  GIS Consultant
 [EMAIL PROTECTED]
   http://utenti.tripod.it/lmorandini/index.html
   -
  
   -Original Message-
   From: Robert Simmons [mailto:[EMAIL PROTECTED]]
   Sent: Sunday, January 26, 2003 9:07 AM
   To: Cocoon Users
   Subject: Single JAR with all the libs?
  
  
   Is there a way to compress all the cocoon jars into one jar so I can
just
  drop in my application server like a golf ball and all
   cocoon deployments will have access to it ?
  
   -- Robert
  
  
   -
   Please check that your question  has not already been answered in the
   FAQ before posting. http://xml.apache.org/cocoon/faq/index.html
  
   To unsubscribe, e-mail: [EMAIL PROTECTED]
   For additional commands, e-mail:   [EMAIL PROTECTED]
  
 

 -
 Please check that your question  has not already been answered in the
 FAQ before posting. http://xml.apache.org/cocoon/faq/index.html

 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail:   [EMAIL PROTECTED]



-
Please check that your question  has not already been answered in the
FAQ before posting. http://xml.apache.org/cocoon/faq/index.html

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail:   [EMAIL PROTECTED]

Re: [OT] Re: Single JAR with all the libs?

[Robert Simmons]

Ya I looked at that .. the problem is that I don't want the directories that
they are coming from, just the file names.

-- Robert

- Original Message -
From: Jeff Turner [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Monday, January 27, 2003 1:33 PM
Subject: [OT] Re: Single JAR with all the libs?


 On Mon, Jan 27, 2003 at 01:17:07PM +0100, Robert Simmons wrote:
  Does anyone know how, in Ant, to take a fileset and convert it to a space
  delimited list of files?

 Something like:

 pathconvert property=list dirsep= 
   path refid=...
 /pathconvert

 --Jeff

  -- Robert
 

 -
 Please check that your question  has not already been answered in the
 FAQ before posting. http://xml.apache.org/cocoon/faq/index.html

 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail:   [EMAIL PROTECTED]



-
Please check that your question  has not already been answered in the
FAQ before posting. http://xml.apache.org/cocoon/faq/index.html

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail:   [EMAIL PROTECTED]

Re: newbies documentation - yet another wiki?

[Robert Simmons]

Ya, I know MSoffice can save into HTML. I want it to save into XML.

-- Robert

- Original Message -
From: Emmanuil Batsis (Manos) [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Monday, January 27, 2003 1:31 PM
Subject: Re: newbies documentation - yet another wiki?


 Star/OpenOffice as well as the new MSOffice.

 Then again, WYSIWYG HTML Editors - Tidy works great too.

 Manos

 Robert Simmons wrote:
  What I don't get is why not put the new documentation in cocoon
distribution?
  Everything else is in there: *smirk* Cocoon is built for web publishing,
we
  could conspire to write volumes right in the product. Which reminds me,
  anyone know a word processor that saves primarily in XML and is good?
 
  -- Robert
 
  - Original Message -
  From: Bertrand Delacretaz [EMAIL PROTECTED]
  To: [EMAIL PROTECTED]
  Sent: Monday, January 27, 2003 10:14 AM
  Subject: Re: newbies documentation - yet another wiki?
 
 
 
 Hi Hussayn,
 
 I mostly agree with your point of view, except on the separate wiki
 thing. (And by the way, thanks a lot for your less talking, more doing
 approach!)
 
 What worries me *a lot* with starting yet another documentation site is
 the dispersion of resources - wouldn't it be much more efficient to have
 you, Derek and possibly others joing the (mythical) Cocoon docs team
 with the aim of creating these newbies docs?
 
 See also http://wiki.cocoondev.org/Wiki.jsp?page=CocoonDocsPlan, I think
 your concept can fit nicely into this.
 
 I'm convinced that it is possible to create the newbies competence
 center that you mention *inside* the existing wiki - a well-designed
 start page and navigation should help newbies find their way.
 
 Maybe this needs some improvements to the existing wiki system, to help
 newbies find pages that are targeted for them, namely:
 
 a) Being able to search the wiki for NCC pages only or everything so
 that newbies are not distracted by deep technical discussions.
 
 b) Being able to clearly label pages as being part of the NCC, different
 color, icons or something.
 
 This might well be possible with JSPwiki, maybe by writing some kind of
 extension? We need to ask Steven or the JSPWiki folks if you think this
 is worth studying.
 
 What do you think?
 Join the party, or throw yet another one? :-)
 
 -Bertrand
 
 
 -
 Please check that your question  has not already been answered in the
 FAQ before posting. http://xml.apache.org/cocoon/faq/index.html
 
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail:   [EMAIL PROTECTED]
 
 
 
  -
  Please check that your question  has not already been answered in the
  FAQ before posting. http://xml.apache.org/cocoon/faq/index.html
 
  To unsubscribe, e-mail: [EMAIL PROTECTED]
  For additional commands, e-mail:   [EMAIL PROTECTED]
 
 
 
 


 -
 Please check that your question  has not already been answered in the
 FAQ before posting. http://xml.apache.org/cocoon/faq/index.html

 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail:   [EMAIL PROTECTED]



-
Please check that your question  has not already been answered in the
FAQ before posting. http://xml.apache.org/cocoon/faq/index.html

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail:   [EMAIL PROTECTED]

Fantastic!!!! My first Generator that connects to an EJB.

[Robert Simmons]

This sucker connects to an EJB which runs the given 
JDO query and returns the set of found objects from the database. Best of all it 
works See the two attached files. Next thing you know I will be writing 
something useful. O_O

-- Robert


SmileyAdminView.java
Description: Binary data


GeneratorBase.java
Description: Binary data
-
Please check that your question  has not already been answered in the
FAQ before posting. http://xml.apache.org/cocoon/faq/index.html

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail:   [EMAIL PROTECTED]

Re: newbies documentation - yet another wiki?

[Robert Simmons]

Nice software. Too bad I don't have a thousand Euros to blow to buy it.

-- Robert


- Original Message -
From: SAXESS - Hussayn Dabbous [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Monday, January 27, 2003 1:37 PM
Subject: Re: newbies documentation - yet another wiki?


 i personally enjoy XML-SPY, although it's tied to MS...
 regards, hussayn

 Robert Simmons wrote:
  Ya, I know MSoffice can save into HTML. I want it to save into XML.
 
  -- Robert
 
  - Original Message -
  From: Emmanuil Batsis (Manos) [EMAIL PROTECTED]
  To: [EMAIL PROTECTED]
  Sent: Monday, January 27, 2003 1:31 PM
  Subject: Re: newbies documentation - yet another wiki?
 
 
 
 Star/OpenOffice as well as the new MSOffice.
 
 Then again, WYSIWYG HTML Editors - Tidy works great too.
 
 Manos
 
 Robert Simmons wrote:
 
 What I don't get is why not put the new documentation in cocoon
 
  distribution?
 
 Everything else is in there: *smirk* Cocoon is built for web publishing,
 
  we
 
 could conspire to write volumes right in the product. Which reminds me,
 anyone know a word processor that saves primarily in XML and is good?
 
 -- Robert
 
 - Original Message -
 From: Bertrand Delacretaz [EMAIL PROTECTED]
 To: [EMAIL PROTECTED]
 Sent: Monday, January 27, 2003 10:14 AM
 Subject: Re: newbies documentation - yet another wiki?
 
 
 
 
 Hi Hussayn,
 
 I mostly agree with your point of view, except on the separate wiki
 thing. (And by the way, thanks a lot for your less talking, more
doing
 approach!)
 
 What worries me *a lot* with starting yet another documentation site is
 the dispersion of resources - wouldn't it be much more efficient to
have
 you, Derek and possibly others joing the (mythical) Cocoon docs team
 with the aim of creating these newbies docs?
 
 See also http://wiki.cocoondev.org/Wiki.jsp?page=CocoonDocsPlan, I
think
 your concept can fit nicely into this.
 
 I'm convinced that it is possible to create the newbies competence
 center that you mention *inside* the existing wiki - a well-designed
 start page and navigation should help newbies find their way.
 
 Maybe this needs some improvements to the existing wiki system, to help
 newbies find pages that are targeted for them, namely:
 
 a) Being able to search the wiki for NCC pages only or everything
so
 that newbies are not distracted by deep technical discussions.
 
 b) Being able to clearly label pages as being part of the NCC,
different
 color, icons or something.
 
 This might well be possible with JSPwiki, maybe by writing some kind of
 extension? We need to ask Steven or the JSPWiki folks if you think this
 is worth studying.
 
 What do you think?
 Join the party, or throw yet another one? :-)
 
 -Bertrand
 
 
 -
 Please check that your question  has not already been answered in the
 FAQ before posting. http://xml.apache.org/cocoon/faq/index.html
 
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail:   [EMAIL PROTECTED]
 
 
 -
 Please check that your question  has not already been answered in the
 FAQ before posting. http://xml.apache.org/cocoon/faq/index.html
 
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail:   [EMAIL PROTECTED]
 
 
 
 
 
 -
 Please check that your question  has not already been answered in the
 FAQ before posting. http://xml.apache.org/cocoon/faq/index.html
 
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail:   [EMAIL PROTECTED]
 
 
 
  -
  Please check that your question  has not already been answered in the
  FAQ before posting. http://xml.apache.org/cocoon/faq/index.html
 
  To unsubscribe, e-mail: [EMAIL PROTECTED]
  For additional commands, e-mail:   [EMAIL PROTECTED]
 

 --
 Dr. Hussayn Dabbous
 SAXESS Software Design GmbH
 Neuenhöfer Allee 125
 50935 Köln
 Telefon: +49-221-56011-0
 Fax: +49-221-56011-20
 E-Mail:  [EMAIL PROTECTED]


 -
 Please check that your question  has not already been answered in the
 FAQ before posting. http://xml.apache.org/cocoon/faq/index.html

 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail:   [EMAIL PROTECTED]



-
Please check that your question  has not already been answered in the
FAQ before posting. http://xml.apache.org/cocoon/faq/index.html

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail:   [EMAIL PROTECTED]

Re: proposal: The Newbies Competence Center

[Robert Simmons]

In my opinion cocoon needs to start architecting itself towards four types of
cocoon consumers:

Presentation Developer:
This person uses editors to define style sheets for transforming data into
presentation layers. This user should not be concerned with the extension
mechanism of cocoon. In a real company, this user would be a graphic
designer. Should this user need some special kind of transformation, they
would ask the next a Content Developer.

Administrator:
This person is responsible for maintaining the health of the cocoon instance.
This user would typically be a network engineer at a company. They should
have functionality to track throughput and performance and get an idea of the
kind of volume being handled by cocoon via some statistics pages.

Content Developer:
Data is the prime responsibility for the content developer. He builds data
engines using custom generator classes, static XML and various other
mechanisms of cocoon. This user is served by a programmer in a company. The
developer Is concerned only with the interface to cocoon and not with any of
the internals. He doesn't need to know why things work, he just needs to know
that if he implements interface x and generates content via sax events, then
cocoon magically spits out his XML.

Cocoon Developer:
This is a consumer that is concerned with altering the cocoon distribution.
This person has varying levels of knowledge of the internals of cocoon and
seeks to contribute to the general product via commits to CVS.

---

To accomplish this we need, IMHO, to implement a few things in cocoon. The
suggestions are annotated with the target roles indicated below their title.
it is for these target roles that we do the task.

Document the API:
For (Cocoon Developer, Content Developer)
Developers of cocoon should go through the entire API and document it. Using
a tool like Jalopy, all of the source code can be formatted to standards set
in the jalopy options. For each entry that is not documented, a todo list can
be generated and worked through to remove all of the todo tag entries. Cocoon
can be used to parse the javadoc files and, using XSLT, extract all of the
todo entries. This would give the consumers the ability to use the API more
effectively.

Abstract Out References to third party libraries:
(Cocoon Developer)
Anytime the Cocoon Developer needs to build a new custom extension to cocoon,
he should have to only import the cocoon.jar file into his classpath to
compile. All of these interfaces will then be documented in one API document
set for easy consumption. This would be accomplished by identifying all entry
points and facading them with interfaces. So the avalon request object would
instead be org.apache.cocoon.api.Request. The user deals only with the
interfaces and not with anything internal.

Convert logging to use Log4j:
(Administrator, Content Developer, Cocoon Developer)
This would involve converting Logikit logging to Log4j logging mechanisms.
Although pervasive throughout the code, the changes are mostly a bunch of
search and replace activities. It can hardly be denied that Log4j has won the
Java logging market. There are already a number of professional tools used
for viewing Log4j output. Such tools as those used in consuming JMS logging
events are used by network engineers all over to monitor health of the
system. There is little point trying to fight the tide. Making Cocoon use
Log4j would have the advantage of allowing these network admins to configure
single Log4j property files for their whole platform.

Build documentation specifically targeted at each user role:
(all)
This documentation should include getting started guides for all four types
of users and varying levels of tutorials. For instance Presentation
Developers might get a tutorial on XSL and XML. Content Developers would get
current tutorials such as making your own generator and introduction to forms
in XSL. In addition, other tutorials such as the sitemap tutorial would be
common to all roles. This documentation should be sectioned appropriate to
the roles.

Create a distribution stripped of every example except a single XML-XSL
transform welcome page for use as a starter point.
(Content Developer)

Change the Libs format:
(Content Developer)
The libs should all be packaged into one big jar containing each of the other
library jars. This library would contain a classpath for each of the entries
in the big jar file. This would hide internals from the cocoon developers.

A new jar called cocoon-ext.jar.
(Content Developer)
This jar would contain only the needed classes for compiling extensions (such
as generators) to cocoon. It would be for users to mount in their development
IDEs instead of having to mount the entire cocoon-all.jar. In the
distribution, a new directory called dev-libs would be created and this jar
would be placed in there.

All properties and xconf files that the user doesn't need to routinely edit
would be 

Single JAR with all the libs?

[Robert Simmons]

Is there a way to compress all the cocoon jars into 
one jar so I can just drop in my application server like a golf ball and all 
cocoon deployments will have access to it ?

-- Robert

Re: Single JAR with all the libs?

[Robert Simmons]

Ya I know that. I'm not talking about the prebuilt, distributed web
application. I am trying to develop a strategy for other users to be able to
use cocoon from within JBoss without having to leap through 15 hoops. So I
basically want a way I can build cocoon libs and then in each war file I make
that uses cocoon, I merely need the config files and only things pertaining
to my stuff and not to cocoon in general.

Getting the kitchen sink build working was a matter of just dropping it in
JBoss. Now I want to go further and make other applications with the product.
Right now Id have to resort to telling readers to download cocoon, unpack it,
rewrite their manifests to include the Cocoon-Libs section, then run the
build which should convert the old libs to the new location and then install
cocoon.

Picture this scenario. You want to use cocoon for a front end to a powerful
EJB based system. Your readers of your book want to download your source code
and install it and get it running. They need a simple process. Right now the
process is download the kitchen sink version, figure out what the hell you
don't need, repack everything and deploy it. Not functional for users of the
product.

Therefore I keep rolling back around to having a single jar that I can drop
in JBoss like an oversized golf ball and call cocoon installed and ready
for users to deploy their OWN war files that use cocoon rather than asking
them to modify cocoon's war.

I'm not sure if I'm making sense here.

-- Robert


- Original Message -
From: Luca Morandini [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Sunday, January 26, 2003 9:41 AM
Subject: RE: Single JAR with all the libs?


 Robert,

 I'm not sure I've understood your question, but I like to give it a try.

 When you build Cocoon, it produces a WAR file, you just:

 1) put the WAR under the webapps of your servlet container
 2) re-start the container

 The you can deploy your Cocoon app under the mount directory, hence avoid
editing the general sitemap.xmap (the one in
 webapps/cocoon).

 Regards,

 -
Luca Morandini
GIS Consultant
   [EMAIL PROTECTED]
 http://utenti.tripod.it/lmorandini/index.html
 -

 -Original Message-
 From: Robert Simmons [mailto:[EMAIL PROTECTED]]
 Sent: Sunday, January 26, 2003 9:07 AM
 To: Cocoon Users
 Subject: Single JAR with all the libs?


 Is there a way to compress all the cocoon jars into one jar so I can just
drop in my application server like a golf ball and all
 cocoon deployments will have access to it ?

 -- Robert


 -
 Please check that your question  has not already been answered in the
 FAQ before posting. http://xml.apache.org/cocoon/faq/index.html

 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail:   [EMAIL PROTECTED]



-
Please check that your question  has not already been answered in the
FAQ before posting. http://xml.apache.org/cocoon/faq/index.html

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail:   [EMAIL PROTECTED]

Re: Single JAR with all the libs?

[Robert Simmons]

Hmm  one question though. This huge manifest attribute called
Cocoon-Libs. Where is it used in the application? Can I leave it out ?

- Original Message -
From: Luca Morandini [EMAIL PROTECTED]
To: Cocoon-users [EMAIL PROTECTED]
Sent: Sunday, January 26, 2003 10:45 AM
Subject: RE: Single JAR with all the libs?


 Robert,

 well, if I were you I'd tweak the build.xml to tailor it to your needs, and
just tell the readers to:

 1) replace the native build.xml with yours
 2) run it
 3) deploy the resulting WAR.

 I have no idea of alternative approaches... sorry :(

 Regards,

 -
Luca Morandini
GIS Consultant
   [EMAIL PROTECTED]
 http://utenti.tripod.it/lmorandini/index.html
 -


  -Original Message-
  From: Robert Simmons [mailto:[EMAIL PROTECTED]]
  Sent: Sunday, January 26, 2003 9:57 AM
  To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
  Subject: Re: Single JAR with all the libs?
 
 
  Ya I know that. I'm not talking about the prebuilt, distributed web
  application. I am trying to develop a strategy for other users to be able
to
  use cocoon from within JBoss without having to leap through 15 hoops. So
I
  basically want a way I can build cocoon libs and then in each war file I
make
  that uses cocoon, I merely need the config files and only things
pertaining
  to my stuff and not to cocoon in general.
 
  Getting the kitchen sink build working was a matter of just dropping it
in
  JBoss. Now I want to go further and make other applications with the
product.
  Right now Id have to resort to telling readers to download cocoon, unpack
it,
  rewrite their manifests to include the Cocoon-Libs section, then run the
  build which should convert the old libs to the new location and then
install
  cocoon.
 
  Picture this scenario. You want to use cocoon for a front end to a
powerful
  EJB based system. Your readers of your book want to download your source
code
  and install it and get it running. They need a simple process. Right now
the
  process is download the kitchen sink version, figure out what the hell
you
  don't need, repack everything and deploy it. Not functional for users of
the
  product.
 
  Therefore I keep rolling back around to having a single jar that I can
drop
  in JBoss like an oversized golf ball and call cocoon installed and
ready
  for users to deploy their OWN war files that use cocoon rather than
asking
  them to modify cocoon's war.
 
  I'm not sure if I'm making sense here.
 
  -- Robert
 
 
  - Original Message -
  From: Luca Morandini [EMAIL PROTECTED]
  To: [EMAIL PROTECTED]
  Sent: Sunday, January 26, 2003 9:41 AM
  Subject: RE: Single JAR with all the libs?
 
 
   Robert,
  
   I'm not sure I've understood your question, but I like to give it a
try.
  
   When you build Cocoon, it produces a WAR file, you just:
  
   1) put the WAR under the webapps of your servlet container
   2) re-start the container
  
   The you can deploy your Cocoon app under the mount directory, hence
avoid
  editing the general sitemap.xmap (the one in
   webapps/cocoon).
  
   Regards,
  
   -
  Luca Morandini
  GIS Consultant
 [EMAIL PROTECTED]
   http://utenti.tripod.it/lmorandini/index.html
   -
  
   -Original Message-
   From: Robert Simmons [mailto:[EMAIL PROTECTED]]
   Sent: Sunday, January 26, 2003 9:07 AM
   To: Cocoon Users
   Subject: Single JAR with all the libs?
  
  
   Is there a way to compress all the cocoon jars into one jar so I can
just
  drop in my application server like a golf ball and all
   cocoon deployments will have access to it ?
  
   -- Robert
  
  
   -
   Please check that your question  has not already been answered in the
   FAQ before posting. http://xml.apache.org/cocoon/faq/index.html
  
   To unsubscribe, e-mail: [EMAIL PROTECTED]
   For additional commands, e-mail:   [EMAIL PROTECTED]
  
 

 -
 Please check that your question  has not already been answered in the
 FAQ before posting. http://xml.apache.org/cocoon/faq/index.html

 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail:   [EMAIL PROTECTED]



-
Please check that your question  has not already been answered in the
FAQ before posting. http://xml.apache.org/cocoon/faq/index.html

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail:   [EMAIL PROTECTED]

Re: Smileys Cocoon sample

[Robert Simmons]

Hmm well that is what im getting to .. im pretty much on today tinkering with
cocoon trying to get a build that will be a bit more deployable to the newb.
What i want is for readers of my book (which Im writing on SERVER side issues
(as in EJB) to be able to download everything and run the sucker. Right now
id have to package in soem 30 jars and that would be just too much. If i can
find a way to pack it into one jar and have cocoon still work then I w ould
be a long way towards my goal. Then I would be debating using a custom
generator or exploring actions (possibly, I dotn know) or just straight xsp.
The smileys are the first thing ive done since it is the easiest to implement
what we like to call the thin row.

-- robert

- Original Message -
From: Luca Morandini [EMAIL PROTECTED]
To: Cocoon-users [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Sunday, January 26, 2003 10:52 AM
Subject: Smileys Cocoon sample


 Robert,

 I've taken a look at your code and I'm tinkering with the idea of re-write
it using Cocoon... could you be of assistance today ?

 BTW, there is any other poster who'd like to replicate this example in
Cocoon ?

 Regards,

 -
Luca Morandini
GIS Consultant
   [EMAIL PROTECTED]
 http://utenti.tripod.it/lmorandini/index.html
 -


 -
 Please check that your question  has not already been answered in the
 FAQ before posting. http://xml.apache.org/cocoon/faq/index.html

 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail:   [EMAIL PROTECTED]



-
Please check that your question  has not already been answered in the
FAQ before posting. http://xml.apache.org/cocoon/faq/index.html

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail:   [EMAIL PROTECTED]

Re: Single JAR with all the libs?

[Robert Simmons]

Ok I yanked the manifest file from WEB-INF and it all still seems to work,
though I don't know about in the full cocoon deployment. Is there any JUnit
built into this sucker?

-- Robert
- Original Message -
From: Robert Simmons [EMAIL PROTECTED]
To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Sent: Sunday, January 26, 2003 1:12 PM
Subject: Re: Single JAR with all the libs?


 Hmm  one question though. This huge manifest attribute called
 Cocoon-Libs. Where is it used in the application? Can I leave it out ?

 - Original Message -
 From: Luca Morandini [EMAIL PROTECTED]
 To: Cocoon-users [EMAIL PROTECTED]
 Sent: Sunday, January 26, 2003 10:45 AM
 Subject: RE: Single JAR with all the libs?


  Robert,
 
  well, if I were you I'd tweak the build.xml to tailor it to your needs,
and
 just tell the readers to:
 
  1) replace the native build.xml with yours
  2) run it
  3) deploy the resulting WAR.
 
  I have no idea of alternative approaches... sorry :(
 
  Regards,
 
  -
 Luca Morandini
 GIS Consultant
[EMAIL PROTECTED]
  http://utenti.tripod.it/lmorandini/index.html
  -
 
 
   -Original Message-
   From: Robert Simmons [mailto:[EMAIL PROTECTED]]
   Sent: Sunday, January 26, 2003 9:57 AM
   To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
   Subject: Re: Single JAR with all the libs?
  
  
   Ya I know that. I'm not talking about the prebuilt, distributed web
   application. I am trying to develop a strategy for other users to be
able
 to
   use cocoon from within JBoss without having to leap through 15 hoops.
So
 I
   basically want a way I can build cocoon libs and then in each war file
I
 make
   that uses cocoon, I merely need the config files and only things
 pertaining
   to my stuff and not to cocoon in general.
  
   Getting the kitchen sink build working was a matter of just dropping it
 in
   JBoss. Now I want to go further and make other applications with the
 product.
   Right now Id have to resort to telling readers to download cocoon,
unpack
 it,
   rewrite their manifests to include the Cocoon-Libs section, then run
the
   build which should convert the old libs to the new location and then
 install
   cocoon.
  
   Picture this scenario. You want to use cocoon for a front end to a
 powerful
   EJB based system. Your readers of your book want to download your
source
 code
   and install it and get it running. They need a simple process. Right
now
 the
   process is download the kitchen sink version, figure out what the hell
 you
   don't need, repack everything and deploy it. Not functional for users
of
 the
   product.
  
   Therefore I keep rolling back around to having a single jar that I can
 drop
   in JBoss like an oversized golf ball and call cocoon installed and
 ready
   for users to deploy their OWN war files that use cocoon rather than
 asking
   them to modify cocoon's war.
  
   I'm not sure if I'm making sense here.
  
   -- Robert
  
  
   - Original Message -
   From: Luca Morandini [EMAIL PROTECTED]
   To: [EMAIL PROTECTED]
   Sent: Sunday, January 26, 2003 9:41 AM
   Subject: RE: Single JAR with all the libs?
  
  
Robert,
   
I'm not sure I've understood your question, but I like to give it a
 try.
   
When you build Cocoon, it produces a WAR file, you just:
   
1) put the WAR under the webapps of your servlet container
2) re-start the container
   
The you can deploy your Cocoon app under the mount directory, hence
 avoid
   editing the general sitemap.xmap (the one in
webapps/cocoon).
   
Regards,
   
-
   Luca Morandini
   GIS Consultant
  [EMAIL PROTECTED]
http://utenti.tripod.it/lmorandini/index.html
-
   
-Original Message-
From: Robert Simmons [mailto:[EMAIL PROTECTED]]
Sent: Sunday, January 26, 2003 9:07 AM
To: Cocoon Users
Subject: Single JAR with all the libs?
   
   
Is there a way to compress all the cocoon jars into one jar so I can
 just
   drop in my application server like a golf ball and all
cocoon deployments will have access to it ?
   
-- Robert
   
   
-
Please check that your question  has not already been answered in the
FAQ before posting. http://xml.apache.org/cocoon/faq/index.html
   
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail:   [EMAIL PROTECTED]
   
  
 
  -
  Please check that your question  has not already been answered in the
  FAQ before posting. http://xml.apache.org/cocoon/faq/index.html
 
  To unsubscribe, e-mail: [EMAIL PROTECTED]
  For additional commands, e-mail

Re: Smileys Cocoon sample... the sequel

[Robert Simmons]

I do all my database work in the EJBs on the server side using JDO. JDO is
basically god for persisting Java objects. =)

I can probably figure out how to connect the suckers. In fact if I'm  not too
far off I can drop them in the container and just grab an initial context.
However what I'm trying to envision is my reader deploying this and shot of
reproducing the build file or telling my users to unpack the cocoon war, I
don't know what to do exactly. If there was one jar they could include, it
would be perfect. I envision a user being able to download a jar file that
has every one of the classes all jared into one cocoon-all.jar and then
dropping it as one unit in their WEB-INF/lib directory but I'm not sure how
to accomplish that. I would also need to know if the path to the cocoon
properties file and the xconf files are hardcoded as I would like to file
them away too. but now I'm talking about developing on cocoon and that's what
I was trying to avoid. Sigh.

-- Robert.


- Original Message -
From: Luca Morandini [EMAIL PROTECTED]
To: Cocoon-users [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Sunday, January 26, 2003 1:35 PM
Subject: Smileys Cocoon sample... the sequel


 Robert,

 I've developed a tentative Cocoon implemtation of your sample.

 1) I've defined a suitable selector in order to switch to different
contents according to its value:
 map:selector name=command-selector
 src=org.apache.cocoon.selection.RequestParameterSelector
 parameter-namecommand/parameter-name
 /map:selector

 2) Then use it to make the actual switching:
 map:match name=wildcard pattern=*.html
 map:select type=command-selector
 map:when test=SysAdminView
 map:generate type=file src=cocoon:/sp-getall-smileys.xml/
 /map:when
 map:when test=SmileyEditView
 map:generate type=file src=cocoon:/sp-get-smiley.xml/
 /map:when
 map:otherwise
 map:generate type=file src=documents/smileys.xml/
 /map:otherwise
 /map:select
 map:transform src=stylesheets/jconfer-page.xsl/
 map:serialize type=html/
 /map:match

 You may notice that now you don't have to aearch the servlets to understand
how the content-reading switching works, it is all in
 one place: the pipeline.

 This begs the question: where can you get your content from ? Or, better,
how Cocoon deals with RDBMS (which are the most common
 persistence mechanism around).

 Well, I use (as you may infer from the names I gave to contents URIs),
Stored Procedures via SQLTransformer. Probably not the
 fastest way, but sure the most flexible and SoC-oriented.

 You can use DatabaseActions, ESQL, or EJBs... which is the option appealing
most to you, I guess.
 How to get an EJB from Cocoon... no idea sorry, I steered well clear of
JSP, Servlets and EJBs.

 Regards,

 -
Luca Morandini
GIS Consultant
   [EMAIL PROTECTED]
 http://utenti.tripod.it/lmorandini/index.html
 -



 -
 Please check that your question  has not already been answered in the
 FAQ before posting. http://xml.apache.org/cocoon/faq/index.html

 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail:   [EMAIL PROTECTED]



-
Please check that your question  has not already been answered in the
FAQ before posting. http://xml.apache.org/cocoon/faq/index.html

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail:   [EMAIL PROTECTED]

Re: Smileys Cocoon sample... the sequel

[Robert Simmons]

dont forget that this is jsut a very small part of the application and a
refactoring usign the sitemap is a good thing. But yes, the data will be
retrieved from EJBs as that is my specialty and what has proven to be ubver
powerful in the server side. Client side I think cocooncould lay all others
to waste if I could just get it going down the road im thinkign of.

-- Robert

- Original Message -
From: Luca Morandini [EMAIL PROTECTED]
To: Cocoon-users [EMAIL PROTECTED]
Sent: Sunday, January 26, 2003 2:01 PM
Subject: RE: Smileys Cocoon sample... the sequel



 Robert,

 I think I misunderstood you.

 Did you want the same approach (servlets + EJB + XSL) to work In Cocoon ?
It could be done, it's only a configuration problem... but
 what's the point ?

 I mean, if you want to show how Cocoon could help developing apps you
should go the Cocoon way a little.

 This is why I thought useful re-factoring your sample using the sitemap...
did you need something else, or what ?

 Regards,

 -
Luca Morandini
GIS Consultant
   [EMAIL PROTECTED]
 http://utenti.tripod.it/lmorandini/index.html
 -


  -Original Message-
  From: Robert Simmons [mailto:[EMAIL PROTECTED]]
  Sent: Sunday, January 26, 2003 1:55 PM
  To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
  Subject: Re: Smileys Cocoon sample... the sequel
 
 
  I do all my database work in the EJBs on the server side using JDO. JDO
is
  basically god for persisting Java objects. =)
 
  I can probably figure out how to connect the suckers. In fact if I'm  not
too
  far off I can drop them in the container and just grab an initial
context.
  However what I'm trying to envision is my reader deploying this and shot
of
  reproducing the build file or telling my users to unpack the cocoon war,
I
  don't know what to do exactly. If there was one jar they could include,
it
  would be perfect. I envision a user being able to download a jar file
that
  has every one of the classes all jared into one cocoon-all.jar and then
  dropping it as one unit in their WEB-INF/lib directory but I'm not sure
how
  to accomplish that. I would also need to know if the path to the cocoon
  properties file and the xconf files are hardcoded as I would like to file
  them away too. but now I'm talking about developing on cocoon and that's
what
  I was trying to avoid. Sigh.
 
  -- Robert.
 
 


 -
 Please check that your question  has not already been answered in the
 FAQ before posting. http://xml.apache.org/cocoon/faq/index.html

 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail:   [EMAIL PROTECTED]



-
Please check that your question  has not already been answered in the
FAQ before posting. http://xml.apache.org/cocoon/faq/index.html

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail:   [EMAIL PROTECTED]

Re: Smileys Cocoon sample... the sequel

[Robert Simmons]

Ahh, perhaps I'm not making myself clear. Enterprise programmers have a sort
of different view of server and client side. To us, anything requesting
services of an EJB that isn't an EJB itself is a client. My vision is the
following

EJBs implementing complex logic in a distributed manner. These Components
will have a number of clients, some clients are things like the web and
wireless devices (where I think cocoon might apply) other clients are things
like GUI's, other businesses, other software and so on. Cocoon is a powerful
presentation tier but I would never want to drop business logic into it.
First of all it constrains me that all of my clients are web based. Second of
all, its not scalable when talking about thousands of transactions per second
(my normal ballpark in EJB systems) third of all its limiting in its scope.
For these and other reasons I wouldn't use cocoon for more than a
presentation tier.

-- Robert

- Original Message -
From: Luca Morandini [EMAIL PROTECTED]
To: Cocoon-users [EMAIL PROTECTED]
Sent: Sunday, January 26, 2003 2:45 PM
Subject: RE: Smileys Cocoon sample... the sequel


  -Original Message-
  From: Robert Simmons [mailto:[EMAIL PROTECTED]]
  Sent: Sunday, January 26, 2003 2:35 PM
  To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
  Subject: Re: Smileys Cocoon sample... the sequel
 
 
  dont forget that this is jsut a very small part of the application and a
  refactoring usign the sitemap is a good thing. But yes, the data will be
  retrieved from EJBs as that is my specialty and what has proven to be
ubver
  powerful in the server side. Client side I think cocooncould lay all
others
  to waste if I could just get it going down the road im thinkign of.

 Which I have not yet understood, I'm afraid.

 Anyway, I hold a different view: Cocoon can rule server-side, coupled with
some business-logic tier, like Stored Procedures or EJBs.

 After all, the content-switching mechanism I've showed you in my pipeline
belongs to the server-side, doesn't it ?

 Regards,

 -
Luca Morandini
GIS Consultant
   [EMAIL PROTECTED]
 http://utenti.tripod.it/lmorandini/index.html
 -



 -
 Please check that your question  has not already been answered in the
 FAQ before posting. http://xml.apache.org/cocoon/faq/index.html

 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail:   [EMAIL PROTECTED]



-
Please check that your question  has not already been answered in the
FAQ before posting. http://xml.apache.org/cocoon/faq/index.html

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail:   [EMAIL PROTECTED]

Re: Single JAR with all the libs? - rejar the distrib ...

[Robert Simmons]

Actually there is another option. Package all of the jars into a jar so that
the contents of that jar are all of the files. Then alter the manifest of the
containing jar (cocoon-all.jar) and add a Class-Path attribute with the names
of each of the sub jars. Now putting the cocoon-all.jar in the path will
cause them all to be in the classpath.

ie:

cocoon-all.jar
-- META-INF/MANIFEST.MF
-- avalon-framework-20020627.jar
-- batik-all-1.5b2.jar
-- bsf-2.2.jar
-- (etc ...)

MANIFEST.MF
Created-By: Cocoon Developer Comittee.
Class-Path: avalon-framework-20020627.jar batik-all-1.5b2.jar bsf-2.2.jar
(etc ...)

Viola .. one large jar containing many small jars. This would take a comitter
with good knowledge of the build.xml abotu 10 min to implement. Make it 20 to
test it. :)

-- Robert


- Original Message -
From: SAXESS - Hussayn Dabbous [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Sunday, January 26, 2003 1:43 PM
Subject: Re: Single JAR with all the libs? - rejar the distrib ...


 If i understand you correct, you simply want to avoid deploying
 several cocoon-based webapps all containing tons of the same
 jar files ?
 And in order to keep your customers happy, you want to simplify
 the deployment by bundling all cocoon jars into one big jar,
 deploying this golfball.jar independently from cocoon into your
 appserver?
 Then your webapps get significantly smaller because
 you only have to deploy the cocoon configs and the webapp
 specifics ...?

 If this is what you want, you can do it in two ways:


 WAY I
 -
 this is a very simplistic approach with some caveats, but
 it works. There may be a license problem here, but i
 don't know this for shure:

 1.) unwar your cocoon distribution to any convenient place
 2.) go to the WEB-INF/lib directory
 3.) Now for each jarfile in the directory simply do:
  jar xf thefile.jar
  Of course you may skip all jars you dont need for your
  distribution ...
 4.) throw away the .jar files
 5.) jar cf golfball.jar *

 Now you have one single jar file, that you can distribute to
 whereever your container needs it to serve as common cocoon
 classes for your webapps.

 Finally you could repack the cocoon.war from step 1.) without
 the lib/*.jar files, add your webapp specific data (config/files/
 programs) and deploy the result as co-webapps into your container ...


 But you have to keep one caveat in your mind:

 You may fall into strongly hidden compatibility issues when
 your webapps use other versions of the .jar modules you just
 have bundled to allclasses.jar

 If you take the single jars as they are, at least you can easier
 track down which module (.jar file) causes compatibility issues.
 And you can easier exchanche module jars if needed although i
 must admit, sometimes exchanging one jar out of a bunch may not
 be trivial at all ;-)
 The golfball.jar only allows to determine, which classes cause
 problems.


 WAY II
 --

 If you are under unix, you can reach your goal by clever use of
 softlinks.
 In my development environment we sometimes have to run 5 to 10
 cocoon-based webapps all across multiple platforms, multiple
 containers and so on. And we found a nice solution, that fits for
 our purposes. If this is something, anyone would be interested in,
 we could share knowledge here, but since this is kind of special
 i wouldn't bother this list and do this offline.
 just drop me an email.

 regards, hussayn

 hope, that helps


 Robert Simmons wrote:
  Is there a way to compress all the cocoon jars into one jar so I can
  just drop in my application server like a golf ball and all cocoon
  deployments will have access to it ?
 
  -- Robert

 --
 Dr. Hussayn Dabbous
 SAXESS Software Design GmbH
 Neuenhöfer Allee 125
 50935 Köln
 Telefon: +49-221-56011-0
 Fax: +49-221-56011-20
 E-Mail:  [EMAIL PROTECTED]


 -
 Please check that your question  has not already been answered in the
 FAQ before posting. http://xml.apache.org/cocoon/faq/index.html

 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail:   [EMAIL PROTECTED]



-
Please check that your question  has not already been answered in the
FAQ before posting. http://xml.apache.org/cocoon/faq/index.html

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail:   [EMAIL PROTECTED]

Re: Single JAR with all the libs? - rejar the distrib ...

[Robert Simmons]

Incidentally you should probably index that jar since it will have lots of
classes and make the classloader throw fits trying to find things.
Performance wise its best to index.

- Original Message -
From: Robert Simmons [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Sent: Sunday, January 26, 2003 11:55 PM
Subject: Re: Single JAR with all the libs? - rejar the distrib ...


 Actually there is another option. Package all of the jars into a jar so
that
 the contents of that jar are all of the files. Then alter the manifest of
the
 containing jar (cocoon-all.jar) and add a Class-Path attribute with the
names
 of each of the sub jars. Now putting the cocoon-all.jar in the path will
 cause them all to be in the classpath.

 ie:

 cocoon-all.jar
 -- META-INF/MANIFEST.MF
 -- avalon-framework-20020627.jar
 -- batik-all-1.5b2.jar
 -- bsf-2.2.jar
 -- (etc ...)

 MANIFEST.MF
 Created-By: Cocoon Developer Comittee.
 Class-Path: avalon-framework-20020627.jar batik-all-1.5b2.jar bsf-2.2.jar
 (etc ...)

 Viola .. one large jar containing many small jars. This would take a
comitter
 with good knowledge of the build.xml abotu 10 min to implement. Make it 20
to
 test it. :)

 -- Robert


 - Original Message -
 From: SAXESS - Hussayn Dabbous [EMAIL PROTECTED]
 To: [EMAIL PROTECTED]
 Sent: Sunday, January 26, 2003 1:43 PM
 Subject: Re: Single JAR with all the libs? - rejar the distrib ...


  If i understand you correct, you simply want to avoid deploying
  several cocoon-based webapps all containing tons of the same
  jar files ?
  And in order to keep your customers happy, you want to simplify
  the deployment by bundling all cocoon jars into one big jar,
  deploying this golfball.jar independently from cocoon into your
  appserver?
  Then your webapps get significantly smaller because
  you only have to deploy the cocoon configs and the webapp
  specifics ...?
 
  If this is what you want, you can do it in two ways:
 
 
  WAY I
  -
  this is a very simplistic approach with some caveats, but
  it works. There may be a license problem here, but i
  don't know this for shure:
 
  1.) unwar your cocoon distribution to any convenient place
  2.) go to the WEB-INF/lib directory
  3.) Now for each jarfile in the directory simply do:
   jar xf thefile.jar
   Of course you may skip all jars you dont need for your
   distribution ...
  4.) throw away the .jar files
  5.) jar cf golfball.jar *
 
  Now you have one single jar file, that you can distribute to
  whereever your container needs it to serve as common cocoon
  classes for your webapps.
 
  Finally you could repack the cocoon.war from step 1.) without
  the lib/*.jar files, add your webapp specific data (config/files/
  programs) and deploy the result as co-webapps into your container ...
 
 
  But you have to keep one caveat in your mind:
 
  You may fall into strongly hidden compatibility issues when
  your webapps use other versions of the .jar modules you just
  have bundled to allclasses.jar
 
  If you take the single jars as they are, at least you can easier
  track down which module (.jar file) causes compatibility issues.
  And you can easier exchanche module jars if needed although i
  must admit, sometimes exchanging one jar out of a bunch may not
  be trivial at all ;-)
  The golfball.jar only allows to determine, which classes cause
  problems.
 
 
  WAY II
  --
 
  If you are under unix, you can reach your goal by clever use of
  softlinks.
  In my development environment we sometimes have to run 5 to 10
  cocoon-based webapps all across multiple platforms, multiple
  containers and so on. And we found a nice solution, that fits for
  our purposes. If this is something, anyone would be interested in,
  we could share knowledge here, but since this is kind of special
  i wouldn't bother this list and do this offline.
  just drop me an email.
 
  regards, hussayn
 
  hope, that helps
 
 
  Robert Simmons wrote:
   Is there a way to compress all the cocoon jars into one jar so I can
   just drop in my application server like a golf ball and all cocoon
   deployments will have access to it ?
  
   -- Robert
 
  --
  Dr. Hussayn Dabbous
  SAXESS Software Design GmbH
  Neuenhöfer Allee 125
  50935 Köln
  Telefon: +49-221-56011-0
  Fax: +49-221-56011-20
  E-Mail:  [EMAIL PROTECTED]
 
 
  -
  Please check that your question  has not already been answered in the
  FAQ before posting. http://xml.apache.org/cocoon/faq/index.html
 
  To unsubscribe, e-mail: [EMAIL PROTECTED]
  For additional commands, e-mail:   [EMAIL PROTECTED]
 


 -
 Please check that your question  has not already been answered in the
 FAQ before posting. http://xml.apache.org/cocoon/faq/index.html

 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail

CatalogManager.properties in WEB-INF/classes ??

[Robert Simmons]

What is this file for and can it be omitted from 
the package? If it cant be omitted is it something that the user should be 
editing? 

-- Robert

Cocoon 2.1 the usability release?

[Robert Simmons]

Given the recent discussion about the difficulty 
getting into cocoon, I am wondering if we should start an initiative to make a 
maintenance release for cocoon that would have a focus on usability for new 
users. The following is a list of features I propose for this release. 


1) A binary distribution stripped of all examples 
and documentation. This distribution would have only a single static XML and XSL 
file in a subdirectory called welcome that would be set up as a welcome page. 
The main sitemap file in the cocoon root directory would have anything not 
needed to serve this page as HTML commented out or removed. It would contain the 
mount only for that part of the site. 

2) A all of the jars are filed into a single 
containing jar called cocoon-all.jar and placed in the WEB-INF/lib directory. 
This should remove "jar shock" from the users new to the system while retaining 
the modularity. A user can always unpack the cocoon-all.jar or replace a jar in 
the file if he chooses. 

3) A new jar called cocoon-ext.jar. This jar would 
contain only the needed classes for compiling extensions (such as generators) to 
cocoon. It would be for users to mount in their development IDEs instead of 
having to mount the entire cocoon-all.jar. In the distribution, a new directory 
called dev-libs would be created and this jar would be placed in there. 


4) All properties and xconf files that the user 
doesn't need to routinely edit would be packed into the cocoon-all.jar. The code 
loading these files would be adapted so that if a user chooses to provide his 
own xconf files (at his own risk), he can do so. Perhaps the code looks for 
custom-cocoon.xconf in the classpath and if it doesn't find it, then it 
loads the default one in the cocoon-all.jar. 

5) Creation of all of these parts would be in the 
build.xml file, perhaps we can use the target name "golfball" for building the 
whole cocoon-all.jar. *smirk*

6) Providing both the full documented kitchen sink 
as well as the stripped jar for binary distribution download. 

Features id like to see: 

a) Replacing logikit with Log4j. Log4j is by far 
the most widespread of the logging packages used today and users will typically 
want to have all of their logging functioning in one product. That way a network 
admin can use a Log4j viewer tool to monitor the health of the system instead of 
needing to parse several logs. 

b) A reference manual on all the included 
generators, actions,serializers and so on:and what they do. The 
target audience for this is the sitemap developer who just wants to wire 
together pipelines. 

b) Reorganization of the documentation to allow a 
more coherent approach to learning cocoon. Starting with including basic newbie 
guides to get hello-world up in 15 minutes or less. Users that can get it 
working fast get excited and go further and faster. Its the hook that draws them 
in. 

Keep in mind I am coming from a usability point 
only. My basic premise is that newbies coming here will mostly not have the 
tenaciousness that I do and will be under deadline guns. Hooking them on cocoon 
by getting them in the door can only be good for the project and its technology. 


-- Robert

Re: Single JAR with all the libs? - rejar the distrib ...

[Robert Simmons]

Attached is an incomplete attempt at building the jar. I don't have time to
figure out how to convert the fileset into the space delimited list of files
needed for the classpath attribute.

-- Robert

- Original Message -
From: Robert Simmons [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Sunday, January 26, 2003 11:56 PM
Subject: Re: Single JAR with all the libs? - rejar the distrib ...


 Incidentally you should probably index that jar since it will have lots of
 classes and make the classloader throw fits trying to find things.
 Performance wise its best to index.

 - Original Message -
 From: Robert Simmons [EMAIL PROTECTED]
 To: [EMAIL PROTECTED]
 Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
 Sent: Sunday, January 26, 2003 11:55 PM
 Subject: Re: Single JAR with all the libs? - rejar the distrib ...


  Actually there is another option. Package all of the jars into a jar so
 that
  the contents of that jar are all of the files. Then alter the manifest of
 the
  containing jar (cocoon-all.jar) and add a Class-Path attribute with the
 names
  of each of the sub jars. Now putting the cocoon-all.jar in the path will
  cause them all to be in the classpath.
 
  ie:
 
  cocoon-all.jar
  -- META-INF/MANIFEST.MF
  -- avalon-framework-20020627.jar
  -- batik-all-1.5b2.jar
  -- bsf-2.2.jar
  -- (etc ...)
 
  MANIFEST.MF
  Created-By: Cocoon Developer Comittee.
  Class-Path: avalon-framework-20020627.jar batik-all-1.5b2.jar bsf-2.2.jar
  (etc ...)
 
  Viola .. one large jar containing many small jars. This would take a
 comitter
  with good knowledge of the build.xml abotu 10 min to implement. Make it
20
 to
  test it. :)
 
  -- Robert
 
 
  - Original Message -
  From: SAXESS - Hussayn Dabbous [EMAIL PROTECTED]
  To: [EMAIL PROTECTED]
  Sent: Sunday, January 26, 2003 1:43 PM
  Subject: Re: Single JAR with all the libs? - rejar the distrib ...
 
 
   If i understand you correct, you simply want to avoid deploying
   several cocoon-based webapps all containing tons of the same
   jar files ?
   And in order to keep your customers happy, you want to simplify
   the deployment by bundling all cocoon jars into one big jar,
   deploying this golfball.jar independently from cocoon into your
   appserver?
   Then your webapps get significantly smaller because
   you only have to deploy the cocoon configs and the webapp
   specifics ...?
  
   If this is what you want, you can do it in two ways:
  
  
   WAY I
   -
   this is a very simplistic approach with some caveats, but
   it works. There may be a license problem here, but i
   don't know this for shure:
  
   1.) unwar your cocoon distribution to any convenient place
   2.) go to the WEB-INF/lib directory
   3.) Now for each jarfile in the directory simply do:
jar xf thefile.jar
Of course you may skip all jars you dont need for your
distribution ...
   4.) throw away the .jar files
   5.) jar cf golfball.jar *
  
   Now you have one single jar file, that you can distribute to
   whereever your container needs it to serve as common cocoon
   classes for your webapps.
  
   Finally you could repack the cocoon.war from step 1.) without
   the lib/*.jar files, add your webapp specific data (config/files/
   programs) and deploy the result as co-webapps into your container ...
  
  
   But you have to keep one caveat in your mind:
  
   You may fall into strongly hidden compatibility issues when
   your webapps use other versions of the .jar modules you just
   have bundled to allclasses.jar
  
   If you take the single jars as they are, at least you can easier
   track down which module (.jar file) causes compatibility issues.
   And you can easier exchanche module jars if needed although i
   must admit, sometimes exchanging one jar out of a bunch may not
   be trivial at all ;-)
   The golfball.jar only allows to determine, which classes cause
   problems.
  
  
   WAY II
   --
  
   If you are under unix, you can reach your goal by clever use of
   softlinks.
   In my development environment we sometimes have to run 5 to 10
   cocoon-based webapps all across multiple platforms, multiple
   containers and so on. And we found a nice solution, that fits for
   our purposes. If this is something, anyone would be interested in,
   we could share knowledge here, but since this is kind of special
   i wouldn't bother this list and do this offline.
   just drop me an email.
  
   regards, hussayn
  
   hope, that helps
  
  
   Robert Simmons wrote:
Is there a way to compress all the cocoon jars into one jar so I can
just drop in my application server like a golf ball and all cocoon
deployments will have access to it ?
   
-- Robert
  
   --
   Dr. Hussayn Dabbous
   SAXESS Software Design GmbH
   Neuenhöfer Allee 125
   50935 Köln
   Telefon: +49-221-56011-0
   Fax: +49-221-56011-20
   E-Mail:  [EMAIL PROTECTED]
  
  
   -
   Please

Re: Cocoon 2.1 the usability release?

[Robert Simmons]

One other feature would be more extensive 
documentation in the API. To see what I mean, look at the class level 
documentation on LinkSerializer. Hrmm ... I still don't know what it does. 
Perhaps its time to bust people's chops to document things. 

What I meant about the component documentation, by 
the way, is basically what is listed if you look at the package page in the API 
for the various components. 

-- Robert

  - Original Message - 
  From: 
  Robert Simmons 
  
  To: Cocoon Users 
  Sent: Monday, January 27, 2003 12:23 
  AM
  Subject: Cocoon 2.1 the usability 
  release? 
  
  Given the recent discussion about the difficulty 
  getting into cocoon, I am wondering if we should start an initiative to make a 
  maintenance release for cocoon that would have a focus on usability for new 
  users. The following is a list of features I propose for this release. 
  
  
  1) A binary distribution stripped of all examples 
  and documentation. This distribution would have only a single static XML and 
  XSL file in a subdirectory called welcome that would be set up as a welcome 
  page. The main sitemap file in the cocoon root directory would have anything 
  not needed to serve this page as HTML commented out or removed. It would 
  contain the mount only for that part of the site. 
  
  2) A all of the jars are filed into a single 
  containing jar called cocoon-all.jar and placed in the WEB-INF/lib directory. 
  This should remove "jar shock" from the users new to the system while 
  retaining the modularity. A user can always unpack the cocoon-all.jar or 
  replace a jar in the file if he chooses. 
  
  3) A new jar called cocoon-ext.jar. This jar 
  would contain only the needed classes for compiling extensions (such as 
  generators) to cocoon. It would be for users to mount in their development 
  IDEs instead of having to mount the entire cocoon-all.jar. In the 
  distribution, a new directory called dev-libs would be created and this jar 
  would be placed in there. 
  
  4) All properties and xconf files that the user 
  doesn't need to routinely edit would be packed into the cocoon-all.jar. The 
  code loading these files would be adapted so that if a user chooses to provide 
  his own xconf files (at his own risk), he can do so. Perhaps the code looks 
  for custom-cocoon.xconf in the classpath and if it doesn't find it, then 
  it loads the default one in the cocoon-all.jar. 
  
  5) Creation of all of these parts would be in the 
  build.xml file, perhaps we can use the target name "golfball" for building the 
  whole cocoon-all.jar. *smirk*
  
  6) Providing both the full documented kitchen 
  sink as well as the stripped jar for binary distribution download. 
  
  
  Features id like to see: 
  
  a) Replacing logikit with Log4j. Log4j is by far 
  the most widespread of the logging packages used today and users will 
  typically want to have all of their logging functioning in one product. That 
  way a network admin can use a Log4j viewer tool to monitor the health of the 
  system instead of needing to parse several logs. 
  
  b) A reference manual on all the included 
  generators, actions,serializers and so on:and what they do. The 
  target audience for this is the sitemap developer who just wants to wire 
  together pipelines. 
  
  b) Reorganization of the documentation to allow a 
  more coherent approach to learning cocoon. Starting with including basic 
  newbie guides to get hello-world up in 15 minutes or less. Users that can get 
  it working fast get excited and go further and faster. Its the hook that draws 
  them in. 
  
  Keep in mind I am coming from a usability point 
  only. My basic premise is that newbies coming here will mostly not have the 
  tenaciousness that I do and will be under deadline guns. Hooking them on 
  cocoon by getting them in the door can only be good for the project and its 
  technology. 
  
  -- Robert

URI of the Sitemap Schema?

[Robert Simmons]

Greetings, 

Is there a uri for a sitemap schema that users can 
use to validate the sitemap during development ? If so, Id like to have it. 


TIA

-- Robert

Re: Cocoon is complex, HOLD ON, WHY IS THIS BOILING UP ?

[Robert Simmons]

We might consider smacking the developers around to start commenting 
things. Pretend you are writing generator for the first time and you are looking 
at the API documentation for documentation on what the parameters are to the 
AbstractGenerator.setup() method. After you are done looking at the 0 
documentation there, look around and you will see that the API is very badly 
commented, if at all. 

-- Robert

  - Original Message - 
  From: 
  Derek Hohls 
  
  To: [EMAIL PROTECTED] 
  
  Sent: Monday, January 27, 2003 8:10 
  AM
  Subject: Re: Cocoon is complex, HOLD ON, 
  WHY IS THIS BOILING UP ?
  
  stop-lurking
  
  Hussayn is absolutely right here - there is a huge case that has 
  built
  up over the last year for givinga "newbie-friendly" face to 
  Cocoon.
  
  We can go on for hours (and have, before) about power and 
  scalability and performance and XSLT issues etc etc etc BUT
  all of those things should flow on *after* starting with Cocoon and
  NOT be part of the sales pitch. I am not saying Cocoon should 
  try
  and be all things to all people... but there is clearly starting to be 
  
  enough people who have picked up on the increased publicity around
  Cocoon and want to "give it a try" - for the most part their needs 
  are
  simple and so their "getting" started path should be as well... IF 
  we
  want to keep these users in the community (if only asusers ;-) 
  THEN
  there is a very strong case to get a section of the website devoted 
  solely
  with a newbie in mind (maybe once it is designed we can eat some 
  humble pie and go back to ask some of the previously critical 
  newbies
  to crit it for us) - ideally this should be quite separate from the main 
  
  site [with an equivalent "DONT PANIC" sign pointing clearly to it 
  from
  the index page]. Everything on that subsite should be geared 
  towards
  a promise of "3 hours (or whatever time frame seems reasonable) until 
  
  your first app" type of message.Work? Of course, but, maybe 
  not as
  much as we think - all the bits and pieces are there (some on wiki, 
  some
  on mailing list, some on main site) but just need to be assembled 
  with
  thought and care (eg. no confusing links to obsure and non-relevant 
  pages
  on the main site etc). Benefits? An influx of "new blood" 
  and, maybe 
  (dare I say it) some converts from the jsp/.net/php camps.
  
  Is xml/xsl really dead (as has been suggested)? If we don't think 
  so
  it should really be possible to demonstrate this in a straightforward 
  way!
  
  My 2c for the bonfire. 
  
  Derek
  
  PS And yes, I am willing to help with testing and critical review of 
  docs
  andinstalling etc - and, once it looks reasonable, willing to 
  coerce 2 of
  my newbie colleagues, who have previously expressed interest in 
  Cocoon,
  to try it out "cold".
  
  /stop-lurking [EMAIL PROTECTED] 26/01/2003 
  01:49:53 I wonder why sometimes when it comes to criticism of 
  cocoonthe arguments fly higher and higher until someone getsreally 
  pissed of and angry ...And why is it so many times a newbie who 
  becomes the centerof this game ? (Also one of my first newbie questions 
  boiledup beyond the limits, but i'm still there ...)Please dont 
  missunderstand me. In general i think the comunitytakes care of many many 
  questions and very valuable informationis flowing around, but we also 
  should take special care about anystrong criticism on cocoon. And 
  especially the newbies can giveso valuable insight, even if they seem to 
  be ignorant (theyaren't ignorant at all. They are new to this 
  !!!)Maybe we should calm down a bit and take this thread 
  reallyserious. It contains much of material to think about.And in many 
  senses the criticism here can't be discussedaway.regards, 
  hussayn-- Dr. Hussayn DabbousSAXESS Software Design 
  GmbHNeuenhöfer Allee 12550935 KölnTelefon: 
  +49-221-56011-0Fax: 
  +49-221-56011-20E-Mail: 
  [EMAIL PROTECTED]-Please 
  check that your question has not already been answered in theFAQ 
  before posting. http://xml.apache.org/cocoon/faq/index.htmlTo 
  unsubscribe, e-mail: 
  [EMAIL PROTECTED]For additional commands, 
  e-mail: 
  [EMAIL PROTECTED]-- This message 
  has been scanned for viruses and dangerous content by MailScanner, and is believed to 
  be clean. "The CSIR exercises no editorial control over E-mail 
  messages and/or attachments thereto/links referred to therein originating 
  in the organisation and the views in this message/attachments thereto are 
  therefore not necessarily those of the CSIR and/or its employees. The 
  sender of this e-mail is, moreover, in terms of the CSIR's Conditions of 
  Service, subject to compliance with the CSIR's internal E-mail and 
  Internet Policy." 

Re: Cocoon is too complex for consumption?

[Robert Simmons]

I think you might already be there. Currently the concept of cocoon is a great one. I 
create a piepline and cocoon shunts it from a
to b, applying the transforms and so on. Great development effort. Pardon the language 
but its a shitty user effort. Just look at
one of your paragraphs in the linked archive.

quote
If we don't do this, not only Cocoon will get bigger and bigger (and
start appearing more as a distribution of technologies, than a
framework), but users will find it harder and harder to modify it for
their specific needs.
/quote

And that is the crux of the problem. Whoever is heading the project seems a bit 
confused. People dont want to MODIFY cocoon. They
want to USE cocoon. They want to install cocoon's mechanics, then drop in their 
pipelines and go. Cocoon is now trying to do all
sorts of things that dont need to be done imho. The number of features is so 
staggering that gettign started is near impossible. But
as I get more into the product, I find myself saying, petulantly, But I just wanted 
the pipeline! And that is all that I wanted.
To have a pipeline. To be able to say to cocoon, Yeah, well ... in your pipeline 
whenever someone hits URL x, go to pipeline Z and
run my custom class (which connects to ejbs and so on) and transform it with 
stylesheet Y and give it back to the user.

But you arent understanding how cocoon works Robert! BINGO!! You hit it right there 
on the head. I dont want to understand how it
works. As a user Im not interested. When reading the JBoss documentation, I skip over 
all the architecture stuff and the development
stuff. As a user, this stuff is irrelevant to me. Object oriented programmign is 
supposed to guarantee to provide me with an
interface and then implement some functionality. How? Who the hell cares? Im a user of 
it. My prime computing expertise is in the
back end side of EJBs and issues that pertain to them. I want to USE cocoon, not 
develop on it.

Possible solutions to this.

1) Rearchitect cocoon to implement some sort of deployment mechanism, such as COB. The 
problem here is that then you have to get
that working with application servers and so on. The other problem is inertia. Gettign 
the masses of developers to learn a
new-unstandardized deployment mechanism.

2) MERGE it with tomcat in the way JBoss has merged with tomcat. I download JBoss and 
they are like well tomcat is included. I say
cool and drop in my wars and go. If cocoon had a basic mechanism install that could 
be installed into tomcat than the situation
would be aleviated. Users of the product drop their wars into tomcat as normal with a 
sitemap file in the WEB-INF directory and
their special generators an so on in the classes directory. Cocoon magically wires 
together the pipeline. No worrying about how to
configure cocoon or what properties to give it or so on. Thats left to advanced users 
under the heading of customizing your
install.

At any rate I can see the learning curve for this product is steep. And cocoon is 
mainly going o suffer from people like me. People
whoe would love to use it but dont have a month to blow trying to get a technology to 
work that is merely suppsed to be an EASY way
to develop a polymorphic presentation layer.

Lastly, flaming is not an option. These are the opinions from a newbie comming into 
cocoon. Readers of this list can flame all they
want but that is just hiding from the very real problems.

-- Robert

- Original Message -
From: Steven Noels [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Saturday, January 25, 2003 3:43 PM
Subject: Re: Cocoon is too complex for consumption?


 Jeff Turner wrote:

  http://wiki.cocoondev.org/Wiki.jsp?page=BlocksDefinition
  http://marc.theaimsgroup.com/?l=xml-cocoon-devm=101603335007960w=2
  http://marc.theaimsgroup.com/?l=xml-cocoon-devm=101732982704553w=2

 oh, but that is unfair since you are a Cocoon committer and you have
 easier access to such things... not! ;-)

 /Steven
 --
 Steven Noelshttp://outerthought.org/
 Outerthought - Open Source, Java  XML Competence Support Center
 Read my weblog athttp://blogs.cocoondev.org/stevenn/
 stevenn at outerthought.orgstevenn at apache.org


 -
 Please check that your question  has not already been answered in the
 FAQ before posting. http://xml.apache.org/cocoon/faq/index.html

 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail:   [EMAIL PROTECTED]



-
Please check that your question  has not already been answered in the
FAQ before posting. http://xml.apache.org/cocoon/faq/index.html

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail:   [EMAIL PROTECTED]

Re: Cocoon is too complex for consumption?

[Robert Simmons]

Well you are wrong. I know all of those and some of them QUITE well. And still getting 
cocoon going is a major hassle. Yes, I can
deploy the distribution but I mean getting my own application going. Just a 
hello-world app.

-- robert

- Original Message -
From: Gustavo Nalle Fernandes [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Saturday, January 25, 2003 5:56 PM
Subject: RES: Cocoon is too complex for consumption?


Cocoon is a powerfull _framework_ used to develop XML applications and
 not an out of the box product. As a framework, Cocoon architecture must be
 well understood in order provide extensions that satisfies a particular
 need.
 IMHO, Cocoon´s leaning curve is not steep, assuming that the -DEVELOPER-
 knows XML, XSL, Namespaces, DTD, SCHEMA, HTTP,Servlets and JAVA/OOP.



 -Mensagem original-
 De: Robert Simmons [mailto:[EMAIL PROTECTED]]
 Enviada em: sábado, 25 de janeiro de 2003 14:13
 Para: [EMAIL PROTECTED]
 Assunto: Re: Cocoon is too complex for consumption?


 I think you might already be there. Currently the concept of cocoon is a
 great one. I create a piepline and cocoon shunts it from a
 to b, applying the transforms and so on. Great development effort. Pardon
 the language but its a shitty user effort. Just look at
 one of your paragraphs in the linked archive.

 quote
 If we don't do this, not only Cocoon will get bigger and bigger (and
 start appearing more as a distribution of technologies, than a
 framework), but users will find it harder and harder to modify it for
 their specific needs.
 /quote

 And that is the crux of the problem. Whoever is heading the project seems a
 bit confused. People dont want to MODIFY cocoon. They
 want to USE cocoon. They want to install cocoon's mechanics, then drop in
 their pipelines and go. Cocoon is now trying to do all
 sorts of things that dont need to be done imho. The number of features is so
 staggering that gettign started is near impossible. But
 as I get more into the product, I find myself saying, petulantly, But I
 just wanted the pipeline! And that is all that I wanted.
 To have a pipeline. To be able to say to cocoon, Yeah, well ... in your
 pipeline whenever someone hits URL x, go to pipeline Z and
 run my custom class (which connects to ejbs and so on) and transform it with
 stylesheet Y and give it back to the user.

 But you arent understanding how cocoon works Robert! BINGO!! You hit it
 right there on the head. I dont want to understand how it
 works. As a user Im not interested. When reading the JBoss documentation, I
 skip over all the architecture stuff and the development
 stuff. As a user, this stuff is irrelevant to me. Object oriented
 programmign is supposed to guarantee to provide me with an
 interface and then implement some functionality. How? Who the hell cares? Im
 a user of it. My prime computing expertise is in the
 back end side of EJBs and issues that pertain to them. I want to USE cocoon,
 not develop on it.

 Possible solutions to this.

 1) Rearchitect cocoon to implement some sort of deployment mechanism, such
 as COB. The problem here is that then you have to get
 that working with application servers and so on. The other problem is
 inertia. Gettign the masses of developers to learn a
 new-unstandardized deployment mechanism.

 2) MERGE it with tomcat in the way JBoss has merged with tomcat. I download
 JBoss and they are like well tomcat is included. I say
 cool and drop in my wars and go. If cocoon had a basic mechanism install
 that could be installed into tomcat than the situation
 would be aleviated. Users of the product drop their wars into tomcat as
 normal with a sitemap file in the WEB-INF directory and
 their special generators an so on in the classes directory. Cocoon magically
 wires together the pipeline. No worrying about how to
 configure cocoon or what properties to give it or so on. Thats left to
 advanced users under the heading of customizing your
 install.

 At any rate I can see the learning curve for this product is steep. And
 cocoon is mainly going o suffer from people like me. People
 whoe would love to use it but dont have a month to blow trying to get a
 technology to work that is merely suppsed to be an EASY way
 to develop a polymorphic presentation layer.

 Lastly, flaming is not an option. These are the opinions from a newbie
 comming into cocoon. Readers of this list can flame all they
 want but that is just hiding from the very real problems.

 -- Robert

 - Original Message -
 From: Steven Noels [EMAIL PROTECTED]
 To: [EMAIL PROTECTED]
 Sent: Saturday, January 25, 2003 3:43 PM
 Subject: Re: Cocoon is too complex for consumption?


  Jeff Turner wrote:
 
   http://wiki.cocoondev.org/Wiki.jsp?page=BlocksDefinition
   http://marc.theaimsgroup.com/?l=xml-cocoon-devm=101603335007960w=2
   http://marc.theaimsgroup.com/?l=xml-cocoon-devm=101732982704553w=2
 
  oh, but that is unfair since you are a Cocoon committer and you have
  easier access

Re: Cocoon is too complex for consumption?

[Robert Simmons]

I don't forget that. Nor do I expect everyone to adapt to my way. Not at all. 
However I know for a fact that I am not the only new
user to cocoon having these issues. I can look at the mailing list archive a long way 
back and see people who have come, posted the
same opinions and then subsequently never posted again. You may say fine they can go 
to hell. but if you are trying to make a
technology not just be a little niche technology with a little tight club as members 
than you need to change this turnover. People
should come into cocoon, see its power and rapidly get a hello world up and start 
running with it. Only through this can you save
the technology from the heap where all the other failed ones went.

The fact is that JSP continues to gather momentum and the era of XML-XSLT has all but 
been forgotten. To what do you attribute this?
XML and XSLT and by extension cocoon has a very narrow window to get some serious 
press to make itself live. This window is passing
by. Sitting there and saying those damn newbies don't know anything! might satisfy 
your sense of self but doesn't promote the
technology. Similarly, replying to a mail such as mine and saying Don't expect 
everything to be _your_ way the moment you arrive,
doesn't accomplish anything except getting people to say, ok fair enough, and 
heading for the door.

In the end, cocoon has two choices. Adapt to the users or die. Its as simple as that. 
If you keep telling us to shut up for whining
about how hard it is to get started, that's fine. The technology will die.

If you ask me, the cocoon development effort should refocus itself from developing 
more features to getting the product in a state
such as tomcat is in. A state where people say cocoon? Oh that's easy to use. getting 
hello-world to work is like a 10 minute
affair. You only need to worry about all the fancy features if you need to use them, 
give it a shot.

Right now, to the newbie, cocoon only inspires three words. Those are, What the hell?

As for me, I don't screw with it any more. I have a book to write and publishing 
schedules to make and the book isn't even remotely
about client side stuff and therefore anything not easy on the client side has to be 
off the shelf.

-- Robert


- Original Message -
From: Steven Noels [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Saturday, January 25, 2003 7:03 PM
Subject: Re: Cocoon is too complex for consumption?


 Robert Simmons wrote:

  Lastly, flaming is not an option. These are the opinions from a
  newbie comming into cocoon. Readers of this list can flame all they
  want but that is just hiding from the very real problems.

 Robert, I can only give you one advise: don't forget human beings are
 sitting behind these MUAs. Don't expect everything to be _your_ way the
 moment you arrive.

 (ditto for the Jakarta Forums idea).

 /Steven
 --
 Steven Noelshttp://outerthought.org/
 Outerthought - Open Source, Java  XML Competence Support Center
 Read my weblog athttp://blogs.cocoondev.org/stevenn/
 stevenn at outerthought.orgstevenn at apache.org


 -
 Please check that your question  has not already been answered in the
 FAQ before posting. http://xml.apache.org/cocoon/faq/index.html

 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail:   [EMAIL PROTECTED]



-
Please check that your question  has not already been answered in the
FAQ before posting. http://xml.apache.org/cocoon/faq/index.html

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail:   [EMAIL PROTECTED]