RE: Cocoon is too complex for consumption?

[e nio]

  Imho, yeah the CTWIG is helpful as a starting point for a
newbie. The other tutorial that I thought that was helpful was
from the www.cocooncenter.de  topic auto-mount, except that it
needs a litle change instead of WildcardURIMatcherFactory it
should use WildcardURIMatcher on the sitemap.xmap. I believe
galatea.com have listed the minimum jar files required to make
up a working cocoon environment.  It sure do take lots of
efforts to  know where these goodies resources are.
  Jeremy and Lajos Cocoon Developer's handbook is excellent for
newbies (I am a newbie).  Chapter 11 is very insightful covering
the heart of Cocoon, sitemap.xmap.  The other two books imho is
more for framework designers and cocoon component developers.  I
did not get to read the two in depth but looking at the
samples(as a newbie I like to see lots of working samples) I
would say Jeremy & Lajos is by far the friendliest.

e nio


--- Jeremy Aston <[EMAIL PROTECTED]> wrote:
> There are good reasons why ctwig is hidden now, mainly because
> it fell out
> of step with documentation as that moved on.  I have intended
> for sometime
> to update the stuff so that it can go back into the
> "mainstream" examples
> but it has had to drop down my priority list for various
> reasons.  Having
> said that, IMHO there are a shed load of places (including the
> dist docs)
> that cover basic xml/xslt/xsp handling with Cocoon.  So why is
> it that
> people feel Cocoon is too difficult to get into?  Does ctwig
> still fill a
> gap?  Could we have even more simple examples, wars etc that
> people can just
> pick up and use?
> 
> I am personally very concerned that the perception is still of
> Cocoon as a
> difficult beast to get into.  The recent threads on this are a
> kick up the
> backside for me as far as getting ctwig up to date goes but it
> would be nice
> to know that that is still what is needed.  I promise to work
> on this in the
> very near future so let me know if you think anything else
> needs doing to
> make being a Cocoon newbie as welcoming a prospect as possible
> 
> rgds
> 
> Jeremy
> 
> 
> > -Original Message-
> > From: e nio [mailto:[EMAIL PROTECTED]]
> > Sent: 25 January 2003 07:22
> > To: [EMAIL PROTECTED]
> > Subject: Re: Cocoon is too complex for consumption?
> >
> >
> >
> >   At one time there was the CTWIG as part of the samples I
> > believed or maybe it was a link on the getting started
> > documentation. Yes it would be nice for us newbies to start
> with
> > that and get acquainted with cocoon.  Anyhow here is the
> link
> > from Jeremy's site:
> > http://www.pigbite.co.uk/ctwig/blddocs/index.html
> >
> > And if you do a search on the humongous cocoon source, you'd
> > find ctwig under documentation/xdocs/ctwig.
> >
> > enio
> >
> > __
> > Do you Yahoo!?
> > Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
> > http://mailplus.yahoo.com
> >
> >
>
-
> > Please check that your question  has not already been
> answered in the
> > FAQ before posting.
> 
> >
> > 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.
> 
> 
> To unsubscribe, e-mail:
> <[EMAIL PROTECTED]>
> For additional commands, e-mail:  
> <[EMAIL PROTECTED]>
> 


__
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com

-
Please check that your question  has not already been answered in the
FAQ before posting. 

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

set transformer source from generator

[Robert Sösemann]

Dear listmembers,

maybe its answer is easy but I couldn't find an answer in the archieves.

I need to dynamically set the transformer source based on a parameter set
inside the Generator.

Thats what my matcher should look like:








For some reasons I can't use a second generator calling this matcher as
CInclude. So, is there another solution to this?
Maybe you know and can help me.

Robert


-
Please check that your question  has not already been answered in the
FAQ before posting. 

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

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 ?
  
  
   
  Hussayn is absolutely right here - there is a huge case that has 
  built
  up over the last year for giving a "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 as users ;-) 
  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
  and installing 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".
   
  >>> [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. To 
  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 complex, HOLD ON, WHY IS THIS BOILING UP ?

[Derek Hohls]

 
Hussayn is absolutely right here - there is a huge case that has 
built
up over the last year for giving a "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 as users ;-) 
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
and installing 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".
 
>>> [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. To 
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."

How can i use RequestParamAction and match fields in parallel ?

[SAXESS - Hussayn Dabbous]

Hy;

I want to use the RequestParam action to pass a parameter into
an aggregation. In parallel the parts of the agregation shall
be assembled from the match parameters {1} {2} ...

My "original sitemap" leads to an  "Resource not found" error:

  

  
  
  
  

  

  

  
  


  



  


>From what i see in the logs i guess {1} is filled with blank or null.
i get an error stating "Resource 'menu' not found"
I can't see, whether {usercollection} is also blanked out...

first experiment:

If  i take out the action, the aggregation takes
place as expected ({useracollection} is now empty of course):

 

  
  



  

secnd experiment:
--
The flow works as expected when i keep the action but eliminate
the {1} reference as follows:

 

  
  


  



  

Can anyone explain me, what i am doing wrong in the "original sitemap" above ?
any hint would help...

regards, husayn

--
Dr. Hussayn Dabbous
SAXESS Software Design GmbH
Neuenhöfer Allee 125
D-50935 Köln
tel.:+49 221 56011 0
fax.:+49 221-56011 20
email:[EMAIL PROTECTED]



-
Please check that your question  has not already been answered in the
FAQ before posting. 

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

Re: Portal - Coplets / Sunlet

[Richard Reyes]

Hi Carsten,

Hope you could spare some time to explain on the solution 2 you have
suggested...

Thanks again


- Original Message -
From: "Richard Reyes" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, January 24, 2003 4:20 PM
Subject: Re: Portal - Coplets / Sunlet


> Hi Carsten,
>
> I am more interested in the second solution, since im planning to
include
> xmlforms as one of coplets
> and they would not be delivering xml streams but formatted xhtml's.
Assuming
> these xmlform can run independently on a separate browser. Will it be
> possible for you to please elaborate on the second solution as I am a
> beginner in cocoon and I cannot even visualized the idea.
>
> Thanks a lot.
> RICHARD
>
> 
> - Original Message -
> From: "Carsten Ziegeler" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Friday, January 24, 2003 4:05 PM
> Subject: RE: Portal - Coplets / Sunlet
>
>
> > Hi,
> >
> > yes, this is possible. You can either say that the source/content of
your
> > coplet is a remote resource or you can use a local resource that
includes
> > a remote resource.
> > First solution: instead of using the cocoon-protocol to specify the
source
> > of your coplet, you can say http://. as long as this remote
resource
> > delivers xml.
> > Second solution: you define a local pipeline, using the
cocoon-protocol
> > and either read via the generator the remote resource or use the
> > cinclude transformer. With the cinclude transformer you can include
> > complete sites, like your www.google.com, as they were running in a
frame.
> > There will be some minor problems to solve, but it's possible :)
> >
> > Carsten
> >

-
Please check that your question  has not already been answered in the
FAQ before posting. 

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

Re: Cocoon is too complex for consumption?

[Tony Collen]

In light of this ginormous thread, do we need more newbie guides to
getting started with Cocoon?  Obviously the CTWIG or whatever is out of
date, so perhaps there's a demand for something like a Busy Developer's
Guide to getting started with Cocoon?  I'd be more that willing to write
stuff up that for direct inclusion with the Cocoon documentation that is
distributed with the releases.

If so, I'll start writing up a Cocoon BDG (or even a series) in Document
1.1 format.

P.S. Docs team: Perhaps it's time to start assimilating Wiki content into
the distribution docs?


Tony

--
Cocoon: Internet Glue (A Cocoon Weblog)
http://manero.org/weblog/


-
Please check that your question  has not already been answered in the
FAQ before posting. 

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

Re: Cocoon is complex, but worth it! Some Answers to your dilemma

[Niclas Hedhman]

First of all, I generally agree with you Robert.
1. Cocoon is overly daunting at first sight.
2. MS get you going much faster.
3. Separation between User and Developer must be stronger.
4. Point-Click deployment tools should become a priority.

There are a few things I don't agree with;

1. I downloaded Cocoon for the first time in 2years in "binary" form and 
dropped the ready-made cocoon.war into Tomcat (also default config).
Worked straight out of the box, although the docs suggested otherwise. Since I 
was involved in discussing the sitemap concept in the first place, I knew how 
that mechanism work, and was within an hour able to publish my first 
document.

2. Everything can not be learnt in 10 minutes. I bet you spent a few weeks 
before mastering Java. How long for XML? Or why not the "MS friendly" Excel?
Certain things takes time, Cocoon is one where you probably need to "invest 
time". You talk about "real business". And I do "real business", no paycheck, 
no security, only what I produce.
The matter of fact, "investments" are almost always "upfront expenditure" for 
long-term "returns", a.k.a Return-On-Investment (ROI). Sometimes expressed in 
time, even for money. I invest $100,000, ROI=2years, meaning from now until 
24months it has cost more than it returned, after that it is "profit".
You do it all the time. Learn new things to be more productive. Why waste the 
time? It's up to you.

3. 61MB download is a problem??? The dozens of CDs that MSDN consists of is 
not? Try to download them, or a portion of it. What is the footprint of 
dotNet? Downloadable? I don't know, but I doubt it.
In fact, when I was shouting about the trouble to install Cocoon in the old 
days, requiring 10 separate downloads from almost as many sources, I was told 
that the bundle would be too big. I'm happy that people reconsidered it.

Finally,
There are efforts going on to improve the separation, and you come back in a 
year, and you will be able to create and deploy COBs (just learnt it) as easy 
as a WAR, and no need to "see", "hear" or "smell" internals of Cocoon.

I feel you have passed judgement already, but I recommend you to make it a 
"preliminary injunction", and re-evaluate your position, especially when you 
have a weekend to "invest". It should take much more...

Niclas

On Sunday 26 January 2003 10:47, Robert Simmons wrote:
> > Robert Simmons dijo:
> > >No professional dev wants, or has the time, to blow 2 to
> > > three weeks just to get separation of logic and presentation.
> >
> > How you think a Professional developer do that? I ended my Master Degree
> > in Computer Science in 1995 just before Java hits the streets and Windows
> > 95 was just at beta release? How do you think I am here now?
> >
> > > Too high of a price for too little gain.
> >
> > Please if you said that phrase you dont really understand what is in the
> > game. I recommend you to check how this little grain affect totally the
> > Web machinery at all. I recommend you to read the second chapter of the
> > Carsten Matthew book:  XML: Building XML Applications. You can find it at
> > amazon.com
>
> Well, I dont think you understand the pressures in professional circles to
> meet deadlines. In the open source world, you have all the time in the
> world to screw with things. When using a product in a working business
> deadlines get in the way of doing things the "right" way. This is an
> explanation of why .NET has been successful. Its a cheap piece of garbage,
> but its easy to get started. Noone wants to be an expert in 10 hours but
> they at leat want to have somethign of a clue.
>
> > > Powerful? I believe you. I believe its powerful. Scalable? I don't
> > > know.
> >
> > Scalable? Please, just check JBoss.org and answer yourself the question.
> >
> > > The Wiki page runs very slow for me and a tutorial linked to me from
> > > the IBM site (which was done in cocoon) was taking 10 to 15 seconds per
> > > page to render.
> >
> > This is an issue for your computer and/or Internet connection.
>
> I dont knwo the cuase but it isnt my isp.
>
> > I live in
> > Managua, Nicaragua. Maybe it is so far that you dont know where is it.
> > But the wiki takes me less that 3 secs. Of course I use Red Hat Linux 8.0
> > and Mozilla that is faster than MS IE. Sometimes I go down and use a
> > Windows machine, but I always use Mozilla, because it is faster.
> >
> > Check http://www.mozilla.org
>
> Great. You like mozilla. Do me a favor and go out there and convince all
> the bluechip companies to switch. You may not like microsoft but in a
> business world you have to deal with it. Whether that is bad or good is
> irrlevant.
>
> > > Put that in production and your company can kiss sales
> > > goodbye. Internet users are impatient and any guy with a DSL isn't
> > > going to wait 15 seconds for your page.
> >
> > This is a developers issue, not a Cocoon issue. There are many books
> > related about web design. How to improve performance using CSS, etc

RE: Cocoon is too complex for consumption?

[Geoff Howard]

> On Saturday 25 January 2003 21:05, Jeff Turner wrote:
> > On Sat, Jan 25, 2003 at 06:22:10PM +0800, Niclas Hedhman wrote:
> > > In fact, I think Cocoon is so powerful, that it has kind of
> grown out of
> > > its "servlet" image. It should traverse to the next level (or
> two), and
> > > has its own deployment system. Collect your stuff (sitemap
> and all) into
> > > a JAR and "hand it over". It is almost like that already, and
> should be a
> > > fairly easy addition to make, but the developer community is much more
> > > focused on additional features.
> >
> > http://wiki.cocoondev.org/Wiki.jsp?page=BlocksDefinition
> > http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=101603335007960&w=2
> > http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=101732982704553&w=2
>
> Implemented already?? or part of the upcoming 2.1?
>
> Niclas

Upcoming.  There is a beginning of "blocks" implementation in 2.1, but
not nearly the full extent of the vision.  At the moment, non-core code,
documentation, and samples are becoming modularized into separate areas
of the source tree, and the build system will include or exclude any of
these based on build-time parameters.  Features like remote download,
adding blocks to already compiled cocoon, blocks exposing services, etc.
are still in the works (and don't seem likely for even 2.1).  What is
there may not sound like much but it's already a big step forward in
my view.

Those involved in the development so far may wish to add to or correct that
summary but I think it's pretty accurate.

Geoff Howard

>
> -
> Please check that your question  has not already been answered in the
> FAQ before posting. 
>
> 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. 

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

Re: Cocoon is too complex for consumption?

[Niclas Hedhman]

On Saturday 25 January 2003 21:05, Jeff Turner wrote:
> On Sat, Jan 25, 2003 at 06:22:10PM +0800, Niclas Hedhman wrote:
> > In fact, I think Cocoon is so powerful, that it has kind of grown out of
> > its "servlet" image. It should traverse to the next level (or two), and
> > has its own deployment system. Collect your stuff (sitemap and all) into
> > a JAR and "hand it over". It is almost like that already, and should be a
> > fairly easy addition to make, but the developer community is much more
> > focused on additional features.
>
> http://wiki.cocoondev.org/Wiki.jsp?page=BlocksDefinition
> http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=101603335007960&w=2
> http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=101732982704553&w=2

Implemented already?? or part of the upcoming 2.1?

Niclas

-
Please check that your question  has not already been answered in the
FAQ before posting. 

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

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

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

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

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

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

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

RE: Smileys Cocoon sample... the sequel

[Geoff Howard]

> -Original Message-
> From: Robert Simmons [mailto:[EMAIL PROTECTED]]
> Sent: Sunday, January 26, 2003 7:55 AM
> 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.

Yes - though the details of how you were getting the initial context in your
servlet were not in the files I got and it bears some thinking.  Were you
relying
on properties declared in your container (which I guess if you're running
the
servlet in jboss that comes for free?) or are you doing a
properties.put(...) there?

When integrating JMS into cocoon for a project a year ago, I remember trying
to think through the best portable strategies for looking up JNDI resources
but have
forgotten some of the issues that surfaced.


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

Unpacking the war (or using a tar.gz or zip instead of war?) the most
straight forward I think, no?  Do I understand right
that the reader will have to do some cocoon user functions?  For example, do
they
need to edit a sitemap?

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

This is a very interesting idea and I think I see the appeal.  It bears
thought about whether it's possible, or feasible (or better than working on
the war).  Normally cocoon is deployed as a web application itself.  It may
share resources with other webapps, but I'm not sure there's much trail
blazed on integrating it into another webapp when it now has to share
web.xml, classloader (?), servlet mappings, etc.

Can you give an example of what kind of webapp you see it integrating into?
I guess an .ear?  What other servlets would need to be configured for the
webapp?

Without having done much deep thinking about this yet, I'd say the safe and
fast way is to use a strategy that involves deploying cocoon as a standalone
webapp that shares resources or referrs to others unless you can help me
understand more problems that presents in your use.

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

the location and name of cocoon.xconf is specified as an init param in
web.xml and can theoretically be changed (actually the default location was
changed at one point), though it would be interesting if it has been done -
there could be hidden gotchas since the vast majority have seen no need to
move it.  While I've heard a desire among the developers (by the way, I'm
just a user and contributor who pays a lot of attention to the development
issues) to get more user-level configuration out of cocoon.xconf, there are
still some important things to be set there for many users (datasources for
instance).  So far, not in your case though.

Not sure what other properties file you mean?  web.xml is part of the
servlet spec and probably can't be messed with/moved.  There is more
configuration in there than desired but no suggestion put forward as yet on
how to move it elsewhere.  The location and name of sitemap.xmap is
specified in cocoon.xconf and can be changed, though I think rarely done for
the "root" sitemap.

> but now I'm talking about developing on cocoon and
> that's what
> I was trying to avoid. Sigh.

Yes, you are now definitely talking about things that would be new, if
possible.  I still don't see the need.   Adding and editing a few files in a
webapp can be done simply.  You could provide a setup that involves only
adding files possibly which would make things less intimidating, no?

Geoff


>
> -- 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:
> >  > src="org.apache.cocoon.selection.RequestParameterSelector">
> > command
> > 
> >
> > 2) Then use it to make the actual switching:
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> >
> > 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:

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

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

AW: pass attributes to phpgenerator

[Marco Rolappe]

hi johannes,

I think you should be matching the request parameter(s) via the respective
matcher, i.e. RequestParameterMatcher. the default (WildcardURI) matcher
most probably only matches on the URI.

so (from the top of my head) it would be something like:





   

   
   

   
   



-Ursprüngliche Nachricht-
Von: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]Im Auftrag
von Johannes Stein
Gesendet: Sonntag, 26. Januar 2003 04:19
An: [EMAIL PROTECTED]
Betreff: pass attributes to phpgenerator


hello people!

after some hours of configuration, i finally got the c2 phpgenerator
set up correctly. next thing would be to pass http-attributes as
parameters to the php-script. i tried something like this in the sitemap:




   
  

   
   



then i called the url one2.php?myparam=three, but the variable myparam isn't
available
in the php-script, referring to it seems to result in a php errormessage
(which is no valid xml, therefore i do not see anything of it).

i'd be delighted if anyone had some experience to share on this problem!

Thank you,  johannes


-
Please check that your question  has not already been answered in the
FAQ before posting. 

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

RE: Smileys Cocoon sample... the sequel

[Luca Morandini]

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

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

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

RE: Smileys Cocoon sample... the sequel

[Luca Morandini]

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. 

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

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:
>  src="org.apache.cocoon.selection.RequestParameterSelector">
> command
> 
>
> 2) Then use it to make the actual switching:
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
>
> 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. 
>
> 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. 

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

Re: Single JAR with all the libs? -> rejar the distrib ...

[SAXESS - Hussayn Dabbous]

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. 

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

Smileys Cocoon sample... the sequel

[Luca Morandini]

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:

command


2) Then use it to make the actual switching:
















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. 

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

RE: Single JAR with all the libs?

[Luca Morandini]

> -Original Message-
> From: Robert Simmons [mailto:[EMAIL PROTECTED]]
> Sent: Sunday, January 26, 2003 1:23 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Single JAR with all the libs?
> 
> 
> 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?

have you looked into the the "test" build target ?

Regards,

P.S.
Don't call it a "sucker"... it ain't a sucker.

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

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. 
> > > >
> > > > To unsubscribe, e-m

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

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

To unsubscribe

i18n + XSLT transformation

[Cyril Vidal]

Hi,

Just to go more deeply into Cocoon's comprehension, I've yesterday built a
little example with the load of two differents stylesheets
(participantsFR.xsl and participantsEN.xsl) depending of the value of a
parameter passed in HTTP Request, and with the help of this mailing-list,
I've achieved this.

Now, I would like to perform exactly the same task, but by another way: via
the use of i18n Transformer.

To translate a static xml file, I've no difficult, and the following except
of sitemap.xmap, (supposed I've created a catalogue directory named
translation with message_en.xml and message_fr.xml) works well:















The following adresses
http://localhost:8080/cocoon/hellococoon/try_it?locale=fr and
http://localhost:8080/cocoon/hellococoon/try_it?locale=en display the
specified translation.



But now, I would like to mix a XSLT transformation with the i18n
Transformation. (I mean, the different

text to be translated  appear now in the XSLT file
participantsIN.xsl)

To perform this task, I've tried the following code (overlapping the i18n
transformation inside the XSLT transformation...):





















But when I try by example the following adress:

http://localhost:8080/cocoon/hellococoon/try_it1?locale=en

I receive no error message but nor is the i18n transformation done:

I the HTML result, I have all my text to be
translated elements, without any effective translation.

Waht I have to change in sitemap to fix the problem?

Thanks again for your help,

Cyril.


-
Please check that your question  has not already been answered in the
FAQ before posting. 

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

Smileys Cocoon sample

[Luca Morandini]

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. 

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

RE: Single JAR with all the libs?

[Luca Morandini]

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

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

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

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

Re: Cocoon is complex, HOLD ON, WHY IS THIS BOILING UP ?

[Nicola Ken Barozzi]

Robert Simmons wrote:

Having Hello-World up in 12 hours is not exactly a steep request.


I'm a cocoon developer and committer. I think I know what I'm saying.

Base Cocoon is not difficult. But given the current documentation and 
examples, even only understanding what a "base" Cocoon usage is... well, 
it's really difficult.

I feel and understand your frustration. It's justified.

But a JSP hello-world page I was able to get up and working in 15
minutes.


That's what we should do.
We have already put some additions in the latest Cocoon in CVS to put in 
a wevserver, so that nothing is needed to simply run a hello-world.
Unfortunately the last releases were hit by a samples refactoring that 
was never really finished, and now the blocks.

We have to repolish it all now.

Thanks for your pointers, they should remember us all that we have still 
work to do on this side.

Ciao.

--
Nicola Ken Barozzi   [EMAIL PROTECTED]
- verba volant, scripta manent -
   (discussions get forgotten, just code remains)
-


-
Please check that your question  has not already been answered in the
FAQ before posting. 

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

RE: Single JAR with all the libs?

[Luca Morandini]

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. 

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

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