Re: new wiki page CreateMinimalWebapp

[Steven Noels]

Geoff Howard wrote:


http://wiki.cocoondev.org/Wiki.jsp?page=CreateMinimalWebapp


the server running the wiki diff notifications has gone AWOL yesterday 
afternoon - going in the office to check what is going on today


--
Steven Noelshttp://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog athttp://blogs.cocoondev.org/stevenn/
stevenn at outerthought.orgstevenn at apache.org


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

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

Xindice1.1b and Pseudo-Protocol: HELP NEEDED

[Julian Klein]

HI,

I am trying to implement the psuedo-protocol for
xindice 1.1 beta in cocoon cvs version.  My previous
code however no longer works to access the database. 
I used to use xindice 1.0 as a standalone, but now I
have it mounted in Tomcat as a webapp running on port
8080.  I am running on red hat 8.0, tomcat 4.1.12,
cocoon cvs version, and java 1.4.  My code is as
below...thanks in advance,

Julian














   
 



 
   


STACK TRACE THROWN WHEN ACCESSING THIS URL 
ATTACHED***

=
Live simply so others may simply live.
 
-Ghandi
 
Pluralitas non est ponenda sine neccesitate.
"Entities should not be multiplied unneccesarily"
 
-William of Occam

__
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com
 The org.apache.cocoon.components.treeprocessor.sitemap.PipelineNode notifies that 
org.apache.cocoon.ProcessingException says:

Could not read resource xmldb:xindice://localhost:8080/db/

More precisely:

org.apache.cocoon.ProcessingException: Could not read resource 
xmldb:xindice://localhost:8080/db/: org.xmldb.api.base.XMLDBException: A connection to 
the Database instance 'db' could not be created. Error: Server returned HTTP response 
code: 500 for URL: http://localhost:8080/db_bootstrap.ior 



Original exception : org.xmldb.api.base.XMLDBException: A connection to the Database 
instance 'db' could not be created. Error: Server returned HTTP response code: 500 for 
URL: http://localhost:8080/db_bootstrap.ior
at org.apache.xindice.client.xmldb.DatabaseImpl.init(DatabaseImpl.java:386)
at org.apache.xindice.client.xmldb.DatabaseImpl.getCollection(DatabaseImpl.java:205)
at org.xmldb.api.DatabaseManager.getCollection(DatabaseManager.java:194)
at 
org.apache.cocoon.components.source.XMLDBSource.collectionToSAX(XMLDBSource.java:265)
at org.apache.cocoon.components.source.XMLDBSource.toSAX(XMLDBSource.java:214)
at 
org.apache.cocoon.components.source.impl.CocoonToAvalonSource.toSAX(CocoonToAvalonSource.java:149)
at 
org.apache.cocoon.environment.AbstractEnvironment.toSAX(AbstractEnvironment.java:532)
at org.apache.cocoon.generation.FileGenerator.generate(FileGenerator.java:140)
at 
org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.processXMLPipeline(AbstractProcessingPipeline.java:513)
at 
org.apache.cocoon.components.pipeline.impl.AbstractCachingProcessingPipeline.processXMLPipeline(AbstractCachingProcessingPipeline.java:192)
at 
org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.process(AbstractProcessingPipeline.java:484)
at 
org.apache.cocoon.components.treeprocessor.sitemap.SerializeNode.invoke(SerializeNode.java:149)
at 
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:84)
at 
org.apache.cocoon.components.treeprocessor.sitemap.PreparableMatchNode.invoke(PreparableMatchNode.java:164)
at 
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:84)
at 
org.apache.cocoon.components.treeprocessor.sitemap.ActTypeNode.invoke(ActTypeNode.java:158)
at 
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:84)
at 
org.apache.cocoon.components.treeprocessor.sitemap.PreparableMatchNode.invoke(PreparableMatchNode.java:164)
at 
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:108)
at 
org.apache.cocoon.components.treeprocessor.sitemap.PipelineNode.invoke(PipelineNode.java:153)
at 
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:108)
at 
org.apache.cocoon.components.treeprocessor.sitemap.PipelinesNode.invoke(PipelinesNode.java:143)
at 
org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreeProcessor.java:317)
at 
org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreeProcessor.java:299)
at 
org.apache.cocoon.components.treeprocessor.sitemap.MountNode.invoke(MountNode.java:134)
at 
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:84)
at 
org.apache.cocoon.components.treeprocessor.sitemap.PreparableMatchNode.invoke(PreparableMatchNode.java:164)
at 
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:108)
at 
org.apache.cocoon.components.treeprocessor.sitemap.PipelineNode.invoke(PipelineNode.java:153)
at 
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:108)
at 
org.apache.cocoon.components.treeprocessor.sitemap.PipelinesNode.invoke(PipelinesNode.java:143)

Re: Action Not Adding Values to Sitemap or is it?

[Murad Jura]

Hello Julian,

simply a part of the pipe which use parameters returned by the action 
should be inside the  tag.

Murad Jura.

Julian Klein wrote:
Hi All,

I am trying to add a paramater to the sitemap through
an Action extended from the MultiAction Class, but
when I try to access it in my sitemap, it is empty.  I
am certain there should be a value coming out of the
Action b/c it prints the value to my log from inside
the action.  Any help would be greatly appreciated.  I
attached my Action code and sitemap code snippets.  I
am running Cocoon 2.1 dev and java 1.4 on Red Hat 8.0.
 The reason for the action is to get collection names
from the Xindice database, which translate to client's
of the webapp.

Thanks,
Julian


   
	
 	  
value="doAddSubjectsAndMyCategories"/>
 	  
value="Global"/>
	
 
pattern="xpath">

src="xmldb:xindice://localhost:4080/db/wEMR/tasks/{../1}#{1}"/>


		
		
value="{categories}"/>
	

 

src="xmldb:xindice://localhost:4080/db/wEMR/tasks/{1}"/>


   

*

  /*Places all the user's into a sitemap parameter.*/
public Map doAddSubjNodes (Redirector redirector,
   SourceResolver resolver,
   Map objectModel,
   String src,
   Parameters parameters) throws
Exception {

   
Request request =
ObjectModelHelper.getRequest(objectModel);
Map sitemapParams = new HashMap();

//determine dest of task to be created
String subjectNode =
parameters.getParameter("task-subject-node",
 
request.getParameter("task-subject-node"));

TaskManager taskManager = new TaskManager();
   
//get all available subjectNode's
String[] subjNodes =
taskManager.getSubjectNodes();
String subjStr = "";
//add all user's to sitemap
for(int x=0;x
subjStr = subjStr + "/" + subjNodes[x];
}
System.out.println("subjNodes="+subjStr);
sitemapParams.put("subjNodes", subjStr);

return sitemapParams;
  }


=
Live simply so others may simply live.
 
-Ghandi
 
Pluralitas non est ponenda sine neccesitate.
"Entities should not be multiplied unneccesarily"
 
-William of Occam

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



-
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: Thanks for the book!

[Lajos]

Thanks Antonio! We appreciate the comments and look forward to reading 
your review.

Regards,

Lajos


Antonio Gallardo wrote:
Hi Lajos!

I just write you because I got your book on Jan, 20th and is the best of
the three about Cocoon 2. Thanks again to you and Jeremy. You are really
good writers!

I promise to post a review on amazon.com since there still are no one review.

Best Regards,

Antonio Gallardo.



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





--



   Lajos Moczar
  
Open Source Support, Consulting and Training
  
Cocoon Developer's Handbook
 (www.amazon.com/exec/obidos/tg/detail/-/0672322579)

   _  _
  / \ /
 /___\  /
/ \   /

 http://www.galatea.com -- powered by AzSSL


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

Redeploy in JBoss Causes Hang

[Robert Simmons]

Greetings. When I remove the cocoon.war from my 
JBoss Deployment directory and then put it back in, the application says that it 
deploys correctly but when I try to access  the cocoon page, it takes quite 
a long time (over a minute) to see the welcome page. What's going on 
here?
 
-- Robert 

Thanks for the book!

[Antonio Gallardo]

Hi Lajos!

I just write you because I got your book on Jan, 20th and is the best of
the three about Cocoon 2. Thanks again to you and Jeremy. You are really
good writers!

I promise to post a review on amazon.com since there still are no one review.

Best Regards,

Antonio Gallardo.



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

[Robert Simmons]

> Robert Simmons wrote:
>
> >GOOD! This is my idea of the right attitude. People seem to fail to
realize that
> >if I didn't see the potential of the product, I wouldn't bother wasting
several
> >hours of my time typing up very long emails on the subject.
> >
> I can see that you do indeed care, but (for example) Slashdot is full of
> long messages from people who don't care about the livelihood of a
> particular project.  This isn't you, I just couldn't resist making that
> point -- no offense intended.  Your statement makes assumptions that we
> already know you as a person.

I don't use slashdot for the very reason that its full of allot of backseat
drivers. You will just have to trust me when I say my internl deadline clock
is cringing at me wasting 2 days typing emails.

> >1) A deployment version with one jar containing all the required CORE
libraries
> >in that jar. This jar would contain avalon and excalibur and the rest but
> >wouldn't bother to mention it. That would stop "jar shock" that the newbie
> >encounters when popping open the web-inf/lib directory. I think my exact
words
> >were, "Holy shit?!?!? What do I really need?"
> >
>
> If you consider a .war as an atomic unit, it's unnecessary.  But it can
> seem intimidating, you're right.  Then again, how often have you gone
> into the lib directories of JBoss or Tomcat?  Those aren't exactly sparse.

Never bothered to look  loooking  nope. Looks nasty. But then notice
the "Ive never bothered looking." Despite using JBoss for near 2 years now.
In cocoon, I HAVE to look.

> On another note, it could well be argued that Cocoon is far more complex
> than Tomcat, so I'd be unsure whether this was a fair comparison.
> Cocoon actually seems to be straddling the line between servlet and
> container.  I think many long-time users and the developers see that,
> but as a newbie, you see the "servlet" moniker and have unrealistic
> expectations.  I don't actually think it's anyone's fault per se; it
> really is quite difficult to explain something that doesn't fit well
> into existing definitions or practices.  Be that as it may, first
> impressions are first impressions.

Peachy. But users dotn really care about what line its stradling. They care
1) does it work?. 2) is it scalable? 3) does it require you to be a developer
to use it? 4) how fast can i get it running. Save the speaches about what
lines its straddling for the developers and the people concerned about
learning its architecture. The users dont care.

> >2) A single built war file with hello world. All it does is spit out hello
world
> >through a little XSLT template. That's it. This is where newbies want to
start.
> >Start small and work your way up.
>
> I believe there are folks working on that particular issue.  It was
> asked for previously on the mailing lists (a skeleton sitemap in a
> relatively bare Cocoon instance) and there are many others that share
> your concern.  It really isn't apathy that you see but a work in
> progress.  There are some who may have taken your statements as
> indictments of their (volunteer) work when it's a known problem on the
> todo list.

Hmm, I find it strange if this isnt just some ant work to accomplish. Why
isnt it there? If it is truly such a time consuming task as to not have been
provided yet (though critical) then you rather prove my point. If the devs
dont have time to get this fired up, how the heck does someone who knows
nothign about it stand a chance?

> >3) Componetize optional features. Give them separate configuration files
and
> >keep them separate.
>
> This is already well underway in the "blocks" concept.  This is a
> relatively young endevour, so you would have to read the developer
> mailing list archives to get specific information.  As a quick preview
> though, if you built a copy of Cocoon CVS and looked in the WEB-INF/lib
> directory of the .war file, you would see quite a few .jar files with
> "block" in the name.  This is the beginnings of what you propose and is
> a work in progress.

Good news there.

> >4) Change the distribution. You get either a minimal (which is required
stuff
> >+hello world) or medium (which contains some samples) or kitchen sink (the
> >current distribution).
> >
>
> Been proposed before and is on the todo list.

Again .. if this isnt a small amount of work, somethign is seriously wrong.
If it is a small amount of work and not a priority than you can see where
newbies are comming from. Focusing on features is all well and good but if
you dont get people to adopt the technology, you are hosed. You can bet
Microsoft is examining cocoon right this mometn and trying to figure out if
they can make an easy to use package that does the same thing.

> >5) Remove anywhere where cocoon user has to know about avalon or
excalibur. Most
> >of us don't much care. When we write a generator we want to implement an
> >interface and say "uhh, my generator is here with this class name" and go
with
> >it. If I need

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

[Antonio Gallardo]

Robert Simmons dijo:
> Java and C++ both have places to start. You can get a Hello World up in
> about 5 minutes.

If you read just the 1st tutorial I pointed you in wiki you will dont told
that.

> This isn't a game. Its not a toy. Its not something that can be said
"like it or leave it." Its a technology.

I know that. Nobody here is just playing. I do professional work too. I
builded my first Cocoon application in 2 months. Now I am starting a new
project. Who is just playing here?

> And the other newbies to this product are likely not as
> tenacious as I am and will say "well to hell with it."

I already saw that.

> Cocoon needs some SERIOUS work in the usability zone. No no,
> I don't expect to understand
> it in 12 hours. Don't be ridicules. I do expect to be able to make a
> start on understanding it in 12 hours though. Having Hello-World up in
> 12 hours is not exactly a steep request.

You told that. You started pointing things out after 12 hours.
>
> If the users have to build from source, which is NEVER a straightforward
> process, they will take off and find something easier.

I think you have mixed some things. Cocoon already let you download the
2.0.4 distribution right from the web site. Install instructions are at:

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

I think what happened here is that many people is working right with the
CVS version. Then when there are some changes, they need to download the
sources and recompile it. But you cannot do it if you dont. By the way to
compile Cocoon just run this command:

./build.sh -Dinclude.webapp.libs=true -Dinclude.scratchpad.libs=true webapp

That is all, then you need to copy the generated war file to the webapp
directory of your Tomcat installation.

> A job that has nothing to do with developing and understanding the
> architecture of cocoon. So there is a dichotomy you are missing. The
> line between the developer and the user. The USERS don't have time to
> learn Avalon and cocoon and a billion other things. All of this detail
> should be HIDDEN from them.

You are not obligated to understand Avalon, etc to understand how Cocoon
works.

When I told about philosophy I thinked about the pipelines. This is the
most important concept here. You must also learn about the sitemap. That
is the heart of Cocoon. Here you define what will be processed and how.
But this does not have nothing to do with Cocoon.

Maybe nobody told you but if you point to:

http://localhost:8080/cocoon/samples/

You will see the current examples of Cocoon.


> Right now I get the impression that if I
> ever did want to make my own generator, I would need to mount 50 jars
> into my NetBeans project. NOT AN OPTION. One jar, fine. 50, no.

The really block is a work in progress. The idea is to make independent
blocks and let people to choose what want to use.

> don't care about setting the properties of the WML serializer. I'm not
> even going to use the WML serializer.

You can remove it from the sitemap without any problem. The first part of
the sitemap is a declaration of what you want to use. I think like the
#include in C or import in Java.

By the way in this languagues you also need to know what include or import
in order to make use of the library or package.


> My goal is to snap together a web
> site, route it through cocoon with my own sitemap and pipeline and go.
> Anything I don't specify or configure should DEFAULT to pre-configured
> settings.

Look, just for taste Cocoon, you can do that without problem. Dont be
afraid you can later tune the Cocoon machine even after the application is
deployed.

I had problems here too at deployment time As many other Open Source
Software Cocoon comes with a minimal configuration that let you run it on
almost every machine. Of course you MUST config it when you plan to deploy
it on production environment.

> So yell "get the hell out!" all you want. People will. And instead of
> cocoon winning the race and capturing the minds and hearts of web
> publishers, it will be .NET. The whole .NET framework should teach you
> something.

I think this is out off topics. I pointed to .NET just to show that maybe
in the future the super company will have something similar to this.
Nothing more. Personally I am a Linux fan. And I am working in that way.
The same as I did it almost 10 years ago when we started to replace Novell
and UNIX in favor of NT. Our clients are happy that they are not more tied
to MS in the new application. Of course, thanks to Java they can run on MS
plataform, but currently run the application on Linux.

> If its too complex to understand, it will LOOSE no matter how
> good it is.

This is not TOO COMPLEX. As I pointed before it is just other philosophy
of developing (I mean as a user). I dont know where also you need to think
about generator, tranformers, serialization. I started to know about it
here. The pipeline concept is the base of all. No Avalon or similars.

When the new users go to 

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

[Robert Simmons]

> Hi Robert -
>
> Ok, my turn to weigh in.
>
> First off, one first principle about any technology is that it's
> usability and suitability are largely subjective. Over the years, I have
> found that many technologies - JSP, EJBs, PHP, Perl/CGI, ActiveX, etc. -
> can work great if YOU like them and know how to use them EFFECTIVELY.
> And the same holds absolutely true with Cocoon. Sometimes you like it,
> sometimes you don't. For some jobs it rocks, for others a simpler
> approach will get the job done as well, if not better. THERE IS NO
> OBJECTIVE RIGHT OR WRONG. Put it another way, you cannot compare Cocoon
> with ActiveX, Perl, JSP or anything else - it is all apples and oranges.
>
> Though I'm a Cocoon book author, I can tell you I myself sometimes get
> fairly pissed with Cocoon. Only recently I was coding up a simple,
> though lengthy, form in Cocoon using an XSP with the formval logicsheet,
> when I started getting an error that I was exceeding 66535 (or whatever)
> bytes for a method. Gr. Luca will affirm that I was not feeling too
> kindly towards Cocoon that week. But in the end, (thanks to his
> client-side validation mechanism) I recoded and am fairly happy with the
> result. Should I have chosen Cocoon for this? Maybe not, actually. I
> probably put in more hours with this project than I would have using a
> JSP. But now that I'm done, I can modify the form to fit the client's
> changing needs much more easily than had I used a JSP. On the other
> hand, when I added credit-card capabilities to my site, I never even
> once considered Cocoon - I rolled a servlet with my own helper objects
> and am totally satisfied with the result. Point is, Cocoon is no magic
> bullet but then again, nothing is.
>
> You make an excellent point that I have to agree with: it is hard to
> separate the Cocoon developer from the Cocoon user. To put it another
> way, you have to be prepared to be a bit of a Cocoon developer to be an
> effective Cocoon user. Frankly, yes, that can be a deterent to adoption.

Yes, that is a deterrent to adoption. The strange thing is that it can be
easily fixed imho. What im talkign about is componetizing the distribution.
Hide anything the user doesnt need to routinely play with. The cocoon.xconf
file for example. I hear that I shouldnt be touching it. Fine, put it away in
a jar. Make it include any local user override of that file (via simple XML
include mechanism) and put the defaults away. Package the jars all into one
and label it cocoon-all.jar. In the online docs it would say "well drom the
cocoon-all.jar into your tomcat lib directory or in your war and off you go".

What we are talkign aobut isrepackaging. Some ant work. some config work and
thats it. Low budget solutions to high budget issues. Then what a user sees
when he gets to cocoon.war is something like the following (in XML notation):


Getting Started guide:

To get started in cocoon you need to download the cocoon distribution war.
Inside the lib directory you will find cocoon-all.jar This is the core cocoon
classes and everythign you need to start developing with cocoon. Included as
well is the cocoon-dev.jar. This file contains the developer interfaces to
cocoon, such as for creating custom generators, and nothing else. It is
provided as a convenience means for developers to compile their custom
genrators and other extensions without havign to deal with the entire
cocoon-all.jar.

Inside the full kitchen sink version of cocoon.war we have the entire cocoon
web site represented. It contains numerous examples and documentation. What
is important to know is that the only files you really need are
WEB-INF/lib/cocoon-all.jar WEB-INF/web.xml, a sitemap, and your own stuff. So
your basic cocoon application war would look like the following


  

   


  
  sitemap.xmap


The cocoon-all.jar could alternatively be placed in the lib directory of
Tomcat if you dont wish to have it in every one of your war files. In
addition it should be noted that it is rare that you will have to modify the
web.xml. Remember that cocoon *IS* the servlet. You are merely extending that
servlet with your own content and potentially special classes. You may have
to create a deployment descriptor for your specific application server if the
need arises, but the web.xml is somethign you should only rarely modify.

The sitemap is the core of the cocoon process. it describes how the data
flows from generation through to serialization. It is through defiining
sitemaps that we map URLs to these various pipelines. For example a single
url might be mapped to take mycompany.xml and use an XSL sheet to translate
it into HTML. Another URL might be mapped to a pipeline that converts that
same XML sheet to WML for display on phones.

So, lets get a minimal distribution of this thing running.

Start off by creating the above structure. For your first sitemap put in the
following .  now create the following two
files. Firs an XML file wi

Re: Cocoon is too complex for consumption?

[Miles Elam]

Robert Simmons wrote:


GOOD! This is my idea of the right attitude. People seem to fail to realize that
if I didn't see the potential of the product, I wouldn't bother wasting several
hours of my time typing up very long emails on the subject.


I can see that you do indeed care, but (for example) Slashdot is full of 
long messages from people who don't care about the livelihood of a 
particular project.  This isn't you, I just couldn't resist making that 
point -- no offense intended.  Your statement makes assumptions that we 
already know you as a person.

1) A deployment version with one jar containing all the required CORE libraries
in that jar. This jar would contain avalon and excalibur and the rest but
wouldn't bother to mention it. That would stop "jar shock" that the newbie
encounters when popping open the web-inf/lib directory. I think my exact words
were, "Holy shit?!?!? What do I really need?"



If you consider a .war as an atomic unit, it's unnecessary.  But it can 
seem intimidating, you're right.  Then again, how often have you gone 
into the lib directories of JBoss or Tomcat?  Those aren't exactly sparse.

On another note, it could well be argued that Cocoon is far more complex 
than Tomcat, so I'd be unsure whether this was a fair comparison.  
Cocoon actually seems to be straddling the line between servlet and 
container.  I think many long-time users and the developers see that, 
but as a newbie, you see the "servlet" moniker and have unrealistic 
expectations.  I don't actually think it's anyone's fault per se; it 
really is quite difficult to explain something that doesn't fit well 
into existing definitions or practices.  Be that as it may, first 
impressions are first impressions.

2) A single built war file with hello world. All it does is spit out hello world
through a little XSLT template. That's it. This is where newbies want to start.
Start small and work your way up.



I believe there are folks working on that particular issue.  It was 
asked for previously on the mailing lists (a skeleton sitemap in a 
relatively bare Cocoon instance) and there are many others that share 
your concern.  It really isn't apathy that you see but a work in 
progress.  There are some who may have taken your statements as 
indictments of their (volunteer) work when it's a known problem on the 
todo list.

3) Componetize optional features. Give them separate configuration files and
keep them separate.



This is already well underway in the "blocks" concept.  This is a 
relatively young endevour, so you would have to read the developer 
mailing list archives to get specific information.  As a quick preview 
though, if you built a copy of Cocoon CVS and looked in the WEB-INF/lib 
directory of the .war file, you would see quite a few .jar files with 
"block" in the name.  This is the beginnings of what you propose and is 
a work in progress.

4) Change the distribution. You get either a minimal (which is required stuff
+hello world) or medium (which contains some samples) or kitchen sink (the
current distribution).



Been proposed before and is on the todo list.


5) Remove anywhere where cocoon user has to know about avalon or excalibur. Most
of us don't much care. When we write a generator we want to implement an
interface and say "uhh, my generator is here with this class name" and go with
it. If I need to mount more than one jar, something is borked. Basically just
facade all the entry points into cocoon with interfaces. its low a low budget
task that goes a LONG way.



Technically you never mount a .jar file;  You only really deploy a .war 
file (or a .ear file in the case of EJB containers).  At any rate, with 
Cocoon in development (many times a state of flux), having each piece 
separate makes debugging and development quicker and easier.

If you need more than one jar, nothing is "borked."  It all works just 
fine as separate files.  This is an aesthetics issue (extending into 
mild intimidation), not a technical one.  Putting everything into a 
single jar won't make Cocoon run better -- it will simply appear 
"neater" to some.

As for Avalon and Excalibur interfaces (and components), the idea was 
that many of these resources are not Cocoon-specific and should be 
shared outside the context of a single webapp.  Weren't you just 
vehemently recommending the use of log4j?  Isn't that including another 
outside package dependency?  I see the issue here as one of 
documentation/education more than technical deficiency.

6) Remove any need to build from CVS. I downloaded the module, all 61 megs of it
and now I expect to spend 20 hours to just get a minimal build working. Users
don't want to have to build the product. Maybe 1% of ant users ever bother to
build it. Same for tomcat and the other popular apache products.



Some of the facilities that you wanted aren't available or as complete 
in the released binary;  That's why some folks pointed you to CVS.  
There are also some speed/efficie

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

[Robert Simmons]

My direct mail is [EMAIL PROTECTED] which is where to send any files. Ill be
interested to see what you have but I have to confess my frustration level is
ratcheted up high and almost out of the reach of rationality. I'm generally
not messing with web-client side much. I am paid professionally for my back
end expertise and us usually leave the front end to some jockey with
dreamweaver MX to tackle the jsps. I am primarily an enterprise programmer
and work on the EJB back end. What I intend to do with this think is to
create my EJBs. Write generators that contact the EJBs an get information and
publish that information. Somewhere along the road I need to have forms that
then call the EJBs and execute commands on them. Right now Id settle for
getting stuff out.

Example? Here you go .. attached to this is a current example of one little
command that gets the smileys for a forum application using a straight
servlet to XML. This guy works by expecting the browser to do the XSLT
transform for me. Its a hack. A demo just to test the full pipeline and proof
of concept of using XML rather than JSP for the front end.

Now I want to do THIS in cocoon. That is my ultimate goal for the evening.

-- Robert

- Original Message -
From: "Geoff Howard" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Sunday, January 26, 2003 5:01 AM
Subject: RE: Cocoon is complex, HOLD ON, WHY IS THIS BOILING UP ?


> > -Original Message-
> > From: Robert Simmons [mailto:[EMAIL PROTECTED]]
> > Sent: Saturday, January 25, 2003 10:19 PM
> > To: [EMAIL PROTECTED]
> > Subject: Re: Cocoon is complex, HOLD ON, WHY IS THIS BOILING UP ?
> >
> >
> > The biggest concept that has me is. "Ok so this is cocoon
> > including everything
> > but the kitchen sink... so where do I start on my OWN site?
> Ok, that's what this minimal build is working toward.  I know
> it's now just instructions, but it could soon be part of the
> binary dist.
>
> > Do I
> > need to copy
> > this enormous cocoon config file?
>
> Depends on which one?  sitemap.xmap can be stripped down significantly, as
> you'll see when I send you the 5 meg war.  cocoon.xconf could be, but the
> idea
> is that for most people and needs, you never need to touch it.  It's 27k -
> my
> advice is just leave it there and don't touch it.  Maybe it should have a
> prominent comment at the top declaring that this file is necessary, but
> probably won't need to be touched by the end user.
>
> > Haven't they ever heard of
> > defaults?
>
> I guess you mean hardcoded in the java in the event the config isn't there?
> I'd rather have a file I could go to to see what the defaults are than have
> them compiled in.  I think this is a matter of taste, and probably won't
> change.
>
> > Do I
> > really need to hand modify all his stuff?
>
> No, unless you mean getting to a minimal build.
>
> > Why is everyone telling
> > me to build
> > the blasted thing from source?
>
> Only because you wanted to get rid of the unnecessary elements, and this is
> the
> only way to do it for now.  It's changing, but as you can imagine having
> seen the
> size of this, there's a lot of work to make it simple.
>
> > Cocoon.xconf ? Do I need this in
> > my new war?
> Yes, it's in the one I'll send and you can leave it alone.
>
> > Holy
> > Christ there are allot of jars (28 is still allot .. prepack them in the
> > distrib).
> I'd think this is a matter of taste, but sure I'll pack them together for
> you.
>
> > Logikit? I use log4j for everything else. After all its the best
> > logging package ever made! What's with logikit?"
>
> Don't know why logkit was chosen, but this is configurable the the xconf
> file, but
> I'd advise you to leave it alone at this stage.  But it's exactly that kind
> of scenario
> that has led to the flexibility/complexity that you see.  The
implementation
> is hidden
> from the user through an abstraction.  Logging in the components I write is
> as simple as
> getLogger().debug("there you go");
> or getLogger().error("there you go");
>
> I don't know much about the internals of either package and don't care for
> the most part.
>
> >
> > Those are the things that pop to mind.
> >
> > Other things vary such as "why the heck wont JBoss let me
> > redeploy this sucker?"
>
> Not sure, but if you post that on the list (after searching the mail
> archives) I bet
> you'll find someone who's run into that.
>
> Do you need to deploy within JBoss though?
>
> > One question I got when I undeployed it from JBoss and dropped it
> > back in and
> > then hit the URL and watched IE wave its flag at me for 5 min in
> > some sort of
> > endless loop.
>
> Obviously not normal behavior, but no idea what's going on.  I've never
seen
> that and guess it's some issue with JBoss that is probably known by JBoss
> users.
>
> >
> > -- Robert
>
> Geoff
>
>
> -
> Please check that your question  has not already been answered in the
> FAQ before p

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

[Lajos]

Hi Robert -

Ok, my turn to weigh in.

First off, one first principle about any technology is that it's 
usability and suitability are largely subjective. Over the years, I have 
found that many technologies - JSP, EJBs, PHP, Perl/CGI, ActiveX, etc. - 
can work great if YOU like them and know how to use them EFFECTIVELY. 
And the same holds absolutely true with Cocoon. Sometimes you like it, 
sometimes you don't. For some jobs it rocks, for others a simpler 
approach will get the job done as well, if not better. THERE IS NO 
OBJECTIVE RIGHT OR WRONG. Put it another way, you cannot compare Cocoon 
with ActiveX, Perl, JSP or anything else - it is all apples and oranges.

Though I'm a Cocoon book author, I can tell you I myself sometimes get 
fairly pissed with Cocoon. Only recently I was coding up a simple, 
though lengthy, form in Cocoon using an XSP with the formval logicsheet, 
when I started getting an error that I was exceeding 66535 (or whatever) 
bytes for a method. Gr. Luca will affirm that I was not feeling too 
kindly towards Cocoon that week. But in the end, (thanks to his 
client-side validation mechanism) I recoded and am fairly happy with the 
result. Should I have chosen Cocoon for this? Maybe not, actually. I 
probably put in more hours with this project than I would have using a 
JSP. But now that I'm done, I can modify the form to fit the client's 
changing needs much more easily than had I used a JSP. On the other 
hand, when I added credit-card capabilities to my site, I never even 
once considered Cocoon - I rolled a servlet with my own helper objects 
and am totally satisfied with the result. Point is, Cocoon is no magic 
bullet but then again, nothing is.

You make an excellent point that I have to agree with: it is hard to 
separate the Cocoon developer from the Cocoon user. To put it another 
way, you have to be prepared to be a bit of a Cocoon developer to be an 
effective Cocoon user. Frankly, yes, that can be a deterent to adoption. 
If you are under the gun to get some multi-output app up and you are 
looking at Cocoon stricly as a user of the technology yes, you might 
have to learn more than you bargined for. But that is the nature of this 
particular beast, just like it is the nature of M$ products that you 
know next to nothing about how they operate (until you find yourself 
hacked through one of their many security holes). Again, you can't 
compare the two - apples and oranges.

Absolutely, Cocoon is complex, and large, which I personally don't care 
for. But the flip side is that you can also do many, many, many things 
with Cocoon. If you like such complexity and flexibility, and care to 
take the time to work through the materials at hand (like mine and 
Jeremy's book ;) ), you will be happy with the results.

I also must agree with you and Hussayn about the business aspect of 
Cocoon. Having consulted at all layers of IT, I know what people look 
at. And yes, Cocoon can fall short for the reasons mentioned - 
usability, time-to-get-running, documentation, abstraction from details, 
separation of developer/user knowledge, etc. Business does judge 
harshly, though perhaps unfairly. Certainly, we serious users will all 
sneer if a pile of MS sh*t is taken more seriously than Cocoon. But, 
then again, there is a point. MS may have the usability (or perhaps the 
perception of usability) edge on Cocoon. But, here is the hard part, it 
is NO ONE'S JOB TO CHANGE THIS. This freedom from accountability is both 
a strength and weakness of OSS in general. One the one hand, someone 
with a great idea can start something like Cocoon, but conversely there 
is no implicit responsibility to an end-user like you (and the others 
who periodically raise the same objections).

If someone wants to position Cocoon for the big time and compete on the 
usability front with the big commercial software products, then that 
person/organization can do something about it. Many of the current 
developers and users of Cocoon don't need more than they have and are 
neither concerned nor required to be concerned with this debate. If you 
want to change it, put together a project - email me offline and let's 
talk. I love the idea. But that is the only way it will be done - nobody 
actually has the responsibility to do anything. No one involved with 
Cocoon has the job to capture "the minds and hearts of web publishers". 
  If they don't want to, that's just fine. And if, as a result, some 
other products does end up capturing the minds and hearts of web 
publishers, that is fine too.


Regards,

Lajos


--



   Lajos Moczar
  
Open Source Support, Consulting and Training
  
Cocoon Developer's Handbook
 (www.amazon.com/exec/obidos/tg/detail/-/0672322579)

   _  _
  / \ /
 /___\  /
/ \   /

 

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

[Geoff Howard]

> -Original Message-
> From: Robert Simmons [mailto:[EMAIL PROTECTED]]
> Sent: Saturday, January 25, 2003 10:19 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Cocoon is complex, HOLD ON, WHY IS THIS BOILING UP ?
>
>
> The biggest concept that has me is. "Ok so this is cocoon
> including everything
> but the kitchen sink... so where do I start on my OWN site?
Ok, that's what this minimal build is working toward.  I know
it's now just instructions, but it could soon be part of the
binary dist.

> Do I
> need to copy
> this enormous cocoon config file?

Depends on which one?  sitemap.xmap can be stripped down significantly, as
you'll see when I send you the 5 meg war.  cocoon.xconf could be, but the
idea
is that for most people and needs, you never need to touch it.  It's 27k -
my
advice is just leave it there and don't touch it.  Maybe it should have a
prominent comment at the top declaring that this file is necessary, but
probably won't need to be touched by the end user.

> Haven't they ever heard of
> defaults?

I guess you mean hardcoded in the java in the event the config isn't there?
I'd rather have a file I could go to to see what the defaults are than have
them compiled in.  I think this is a matter of taste, and probably won't
change.

> Do I
> really need to hand modify all his stuff?

No, unless you mean getting to a minimal build.

> Why is everyone telling
> me to build
> the blasted thing from source?

Only because you wanted to get rid of the unnecessary elements, and this is
the
only way to do it for now.  It's changing, but as you can imagine having
seen the
size of this, there's a lot of work to make it simple.

> Cocoon.xconf ? Do I need this in
> my new war?
Yes, it's in the one I'll send and you can leave it alone.

> Holy
> Christ there are allot of jars (28 is still allot .. prepack them in the
> distrib).
I'd think this is a matter of taste, but sure I'll pack them together for
you.

> Logikit? I use log4j for everything else. After all its the best
> logging package ever made! What's with logikit?"

Don't know why logkit was chosen, but this is configurable the the xconf
file, but
I'd advise you to leave it alone at this stage.  But it's exactly that kind
of scenario
that has led to the flexibility/complexity that you see.  The implementation
is hidden
from the user through an abstraction.  Logging in the components I write is
as simple as
getLogger().debug("there you go");
or getLogger().error("there you go");

I don't know much about the internals of either package and don't care for
the most part.

>
> Those are the things that pop to mind.
>
> Other things vary such as "why the heck wont JBoss let me
> redeploy this sucker?"

Not sure, but if you post that on the list (after searching the mail
archives) I bet
you'll find someone who's run into that.

Do you need to deploy within JBoss though?

> One question I got when I undeployed it from JBoss and dropped it
> back in and
> then hit the URL and watched IE wave its flag at me for 5 min in
> some sort of
> endless loop.

Obviously not normal behavior, but no idea what's going on.  I've never seen
that and guess it's some issue with JBoss that is probably known by JBoss
users.

>
> -- Robert

Geoff


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

pass attributes to phpgenerator

[Johannes Stein]

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

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

[Robert Simmons]

The biggest concept that has me is. "Ok so this is cocoon including everything
but the kitchen sink... so where do I start on my OWN site? Do I need to copy
this enormous cocoon config file? Haven't they ever heard of defaults? Do I
really need to hand modify all his stuff? Why is everyone telling me to build
the blasted thing from source? Cocoon.xconf ? Do I need this in my new war? Holy
Christ there are allot of jars (28 is still allot .. prepack them in the
distrib). Logikit? I use log4j for everything else. After all its the best
logging package ever made! What's with logikit?"

Those are the things that pop to mind.

Other things vary such as "why the heck wont JBoss let me redeploy this sucker?"
One question I got when I undeployed it from JBoss and dropped it back in and
then hit the URL and watched IE wave its flag at me for 5 min in some sort of
endless loop.

-- Robert

- Original Message -
From: "Geoff Howard" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Sunday, January 26, 2003 4:07 AM
Subject: RE: Cocoon is complex, HOLD ON, WHY IS THIS BOILING UP ?


> > Java and C++ both have places to start. You can get a Hello World
> > up in about 5 minutes.
>
> I don't think you're asking for a "hello world".  I did a hello world within
> a
> few minutes of first downloading cocoon a year ago.  Put an xml file
> somewhere.
> Put an xsl file somewhere.  In the main sitemap, put
> 
> 
> 
> 
> 
>
> and you're done.  You're a smart guy and you must have done this much by
> now.
>
> Where you go from there is different for everyone.  You want to
> do EJB's, some people want to stick with static xml files, some people want
> relational
> databases, some want xml databases, slide, etc.  That's all very possible in
> cocoon
> but they are so different that it's made it tough so far to get the user
> experience under control, as you've noticed.
>
> What you've been asking for is legitimate but not currently easily
> available.
>
> I've heard you say:
> 1) Simple user experience.  Well, that's a little subjective because of the
> many
> different needs people are bringing to the table but I think everyone here
> would like
> to see that too and value your input on where that's missing.
> 2) Smaller, more self contained war.  I asked for that too when I started
> with
> cocoon and had to figure it out on my own unfortunately.  I sat down earlier
> and went
> through the steps of the build from source taking out everything optional
> and wrote them down for you and the greater good in the wiki.  The war I
> built is less than 5 meg, and worked right away.  If you're using jdk1.4 I
> can send you the war.
>The longer term solution is being worked on and has come a long way
> already from 2.0.x but it's in 2.1 which is just getting to alpha stage, and
> so not appropriate for your needs yet.
> 3) The complaint about the number of jars I understand less, unless it was
> related to cutting out what it unnecessary.  That can be overwhelming, but
> the minimal build I've described and may one day be included in the
> distribution has only what it needs, so you just leave the jars in there.
> It does have 28 jar files in WEB-INF/lib (about half of what the full
> version has) which sounds like a lot, but I don't yet understand your
> concern there.  Cocoon has a sophisticated component based architecture.  If
> a bug surfaces in the source resolving component, you will probably be able
> to drop in a replacement for that jar and not have to worry about the rest
> of Cocoon.  You can jar those all up together in one big collection if you
> want for convenience if you need to start mingling them with other things.
>
> > If you take the attitude "don't let the
> > door hit you in the ass on the way out," then people will head
> > out and make sure the aforementioned door doesn't strike. This isn't
> > a game. Its not a toy. Its not something that can be said "like
> > it or leave it." Its a technology. And the other newbies to this
> > product are likely not as tenacious as I am and will say "well to
> > hell with it." Cocoon needs some SERIOUS work in the usability
> > zone. No no, I don't expect to understand it in 12 hours. Don't
> > be ridicules. I do expect to be able to make a start on
> > understanding it in 12 hours though. Having Hello-World up in 12
> > hours is not exactly a steep request.
>
> You're right about the work needed for usability, which is why we're
> trying to help.  And you are helping us:
>
> - What concepts specifically are the most confusing to you
> from your perspective of just trying to get up and running now that
> you've been looking around the available docs and samples (and where
> are _they_ not much help)?
>   The wiki has been helping to get new documentation up quickly,
> so whatever specific discussion we can have on the list will be of
> almost immediate benefit to others that come after.
>
> - EJB use is not well documented and not very "slick"

Re: Cocoon is too complex for consumption?

[Robert Simmons]

10 minutes ? Some 30 hours later I still haven't figured out what I need to go
minimal.

-- Robert

- Original Message -
From: "Perry Molendijk" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Sunday, January 26, 2003 3:46 AM
Subject: Re: Cocoon is too complex for consumption?


> > The fact is that JSP continues to gather momentum and the era of XML-XSLT
> has all but been forgotten. To what do you attribute this?
> > XML and XSLT and by extension cocoon has a very narrow window to get some
> serious press to make itself live. This window is passing by.
>
> Funny that, I am kind booked out for most of the year with projects that
> need XSLT written for their applications. One of them is cleaning up the
> mess of having HTML and Java code in JSP nicely mixed up together. I don't
> write a line of Java myself but I have observed is that writting "clean"
> webapplications takes a fair bit of discipline that many developers don't
> have, or it is usually simply too hard for them; "this how I always do it".
>
> > If you ask me, the cocoon development effort should refocus itself from
> developing more features to getting the product in a state
> > such as tomcat is in. A state where people say "cocoon? Oh that's easy to
> use. getting hello-world to work is like a 10 minute
> > affair. You only need to worry about all the fancy features if you need to
> use them, give it a shot."
>
> OK the Cocoon doco needs work and the amount of features well out number the
> amount of doco pages. But you can still get Hello World up in 10 minutes.
> Most of the installation problems appear to be typical for all sorts of Java
> applications: wrong, missing or conflicting jar files in various places..
>
> Perry Molendijk
>
>
> -
> 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?

[Robert Simmons]

> 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

GOOD! This is my idea of the right attitude. People seem to fail to realize that
if I didn't see the potential of the product, I wouldn't bother wasting several
hours of my time typing up very long emails on the subject.

What you need in my newbie opinion.

1) A deployment version with one jar containing all the required CORE libraries
in that jar. This jar would contain avalon and excalibur and the rest but
wouldn't bother to mention it. That would stop "jar shock" that the newbie
encounters when popping open the web-inf/lib directory. I think my exact words
were, "Holy shit?!?!? What do I really need?"

2) A single built war file with hello world. All it does is spit out hello world
through a little XSLT template. That's it. This is where newbies want to start.
Start small and work your way up.

3) Componetize optional features. Give them separate configuration files and
keep them separate.

4) Change the distribution. You get either a minimal (which is required stuff
+hello world) or medium (which contains some samples) or kitchen sink (the
current distribution).

5) Remove anywhere where cocoon user has to know about avalon or excalibur. Most
of us don't much care. When we write a generator we want to implement an
interface and say "uhh, my generator is here with this class name" and go with
it. If I need to mount more than one jar, something is borked. Basically just
facade all the entry points into cocoon with interfaces. its low a low budget
task that goes a LONG way.

6) Remove any need to build from CVS. I downloaded the module, all 61 megs of it
and now I expect to spend 20 hours to just get a minimal build working. Users
don't want to have to build the product. Maybe 1% of ant users ever bother to
build it. Same for tomcat and the other popular apache products.

7 and not a priority but would be nice) Change logging to use Log4j. Its won the
race. Even the logging in jdk has been beaten bloody by log4j. The other logging
frameworks might as well concede.




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

[Geoff Howard]

> Java and C++ both have places to start. You can get a Hello World
> up in about 5 minutes.

I don't think you're asking for a "hello world".  I did a hello world within
a
few minutes of first downloading cocoon a year ago.  Put an xml file
somewhere.
Put an xsl file somewhere.  In the main sitemap, put






and you're done.  You're a smart guy and you must have done this much by
now.

Where you go from there is different for everyone.  You want to
do EJB's, some people want to stick with static xml files, some people want
relational
databases, some want xml databases, slide, etc.  That's all very possible in
cocoon
but they are so different that it's made it tough so far to get the user
experience under control, as you've noticed.

What you've been asking for is legitimate but not currently easily
available.

I've heard you say:
1) Simple user experience.  Well, that's a little subjective because of the
many
different needs people are bringing to the table but I think everyone here
would like
to see that too and value your input on where that's missing.
2) Smaller, more self contained war.  I asked for that too when I started
with
cocoon and had to figure it out on my own unfortunately.  I sat down earlier
and went
through the steps of the build from source taking out everything optional
and wrote them down for you and the greater good in the wiki.  The war I
built is less than 5 meg, and worked right away.  If you're using jdk1.4 I
can send you the war.
   The longer term solution is being worked on and has come a long way
already from 2.0.x but it's in 2.1 which is just getting to alpha stage, and
so not appropriate for your needs yet.
3) The complaint about the number of jars I understand less, unless it was
related to cutting out what it unnecessary.  That can be overwhelming, but
the minimal build I've described and may one day be included in the
distribution has only what it needs, so you just leave the jars in there.
It does have 28 jar files in WEB-INF/lib (about half of what the full
version has) which sounds like a lot, but I don't yet understand your
concern there.  Cocoon has a sophisticated component based architecture.  If
a bug surfaces in the source resolving component, you will probably be able
to drop in a replacement for that jar and not have to worry about the rest
of Cocoon.  You can jar those all up together in one big collection if you
want for convenience if you need to start mingling them with other things.

> If you take the attitude "don't let the
> door hit you in the ass on the way out," then people will head
> out and make sure the aforementioned door doesn't strike. This isn't
> a game. Its not a toy. Its not something that can be said "like
> it or leave it." Its a technology. And the other newbies to this
> product are likely not as tenacious as I am and will say "well to
> hell with it." Cocoon needs some SERIOUS work in the usability
> zone. No no, I don't expect to understand it in 12 hours. Don't
> be ridicules. I do expect to be able to make a start on
> understanding it in 12 hours though. Having Hello-World up in 12
> hours is not exactly a steep request.

You're right about the work needed for usability, which is why we're
trying to help.  And you are helping us:

- What concepts specifically are the most confusing to you
from your perspective of just trying to get up and running now that
you've been looking around the available docs and samples (and where
are _they_ not much help)?
  The wiki has been helping to get new documentation up quickly,
so whatever specific discussion we can have on the list will be of
almost immediate benefit to others that come after.

- EJB use is not well documented and not very "slick" at the moment, but I
for one have been wanting to take a look at it.  Do you see yet how to
proceed, or can we help get you started?  You could easily have a generator
spitting out xml from an ejb tonight if you'll ask specific questions and
provide more detail about what is unclear to you.

>
> If the users have to build from source, which is NEVER a
> straightforward process, they will take off and find something
> easier. Ant,
> for example, is massively extensible

Obviously that's why the binary distributions are there.  But as you've
pointed
out they are bloated for your deploying needs which is an excellent point I
think.
Follow the instructions I put up at the wiki or let me send you this war
file and
let me know if you think this is in the right direction.

> Right now I get the impression that if
> I ever did want to make my own generator, I would need to mount
> 50 jars into my NetBeans project. NOT AN OPTION. One jar, fine. 50,
> no.

I am not familiar enough with NetBeans to help you integrate there but maybe
someone else is.  Still, have you looked at the tutorial on generators I
sent you a link to?  The most complicated example there needs 4 jars on the
classpath.  In case you missed it, it's here:
http://xml.apache.org/cocoon/tuto

Re: I got this error

[Joerg Heinicke]

Hello Giovanni,

you have a wrong version of JVM. It seems that your code was compiled 
with a newer version than the used JVM. Did you download a binary 
distribution or did you build your own Cocoon from sources?

Regards,

Joerg

Giovanni Di Lembo wrote:
I got this error installing cocoon 2.0.1 with tomcat 4.1.8 and with jdk
1.4

WHY?

 type fatal

message Language Exception

description org.apache.cocoon.ProcessingException: Language Exception:
org.apache.cocoon.components.language.LanguageException: Error compiling
sitemap_xmap: Line 0, column 0: could not parse error message: error:
Invalid class file format in
C:\jdk4\jre\lib\rt.jar(java/io/OutputStream.class). The major.minor
version '48.0' is too recent for this tool to understand.
C:\Programmi\Apache Group\Tomcat
4.1\work\Standalone\localhost\cocoon\cocoon-files\org\apache\cocoon\www\
sitemap_xmap.java:12: Class java.io.OutputStream not found in import.
import java.io.OutputStream; ^ Line 0, column 0: could not parse error
message: error: Invalid class file format in
C:\jdk4\jre\lib\rt.jar(java/io/IOException.class). The major.minor
version '48.0' is too recent for this tool to understand.
C:\Programmi\Apache Group\Tomcat
4.1\work\Standalone\localhost\cocoon\cocoon-files\org\apache\cocoon\www\
sitemap_xmap.java:13: Class java.io.IOException not found in import.
import java.io.IOException; ^ Line 0, column 0: could not parse error
message: error: Invalid class file format in
C:\jdk4\jre\lib\rt.jar(java/util/List.class). The major.minor version
'48.0' is too recent for this tool to understand. C:\Programmi\Apache
Group\Tomcat
4.1\work\Standalone\localhost\cocoon\cocoon-files\org\apache\cocoon\www\
sitemap_xmap.java:15: Class java.util.List not found in import. import
java.util.List; ^ Line 0, column 0: could not parse error message:
error: Invalid class file format in
C:\jdk4\jre\lib\rt.jar(java/util/ArrayList.class). The major.minor
version '48.0' is too recent for this tool to understand.
C:\Programmi\Apache Group\Tomcat
4.1\work\Standalone\localhost\cocoon\cocoon-files\org\apache\cocoon\www\
sitemap_xmap.java:16: Class java.util.ArrayList not found in import.
import java.util.ArrayList; ^ Line 0, column 0: could not parse error
message: error: Invalid class file format in
C:\jdk4\jre\lib\rt.jar(java/util/Map.class). The major.minor version
'48.0' is too recent for this tool to understand. C:\Programmi\Apache
Group\Tomcat
4.1\work\Standalone\localhost\cocoon\cocoon-files\org\apache\cocoon\www\
sitemap_xmap.java:17: Class java.util.Map not found in import. import
java.util.Map; ^ Line 0, column 0: could not parse error message: error:
Invalid class file format in
C:\jdk4\jre\lib\rt.jar(java/util/HashMap.class). The major.minor version
'48.0' is too recent for this tool to understand. C:\Programmi\Apache
Group\Tomcat
4.1\work\Standalone\localhost\cocoon\cocoon-files\org\apache\cocoon\www\
sitemap_xmap.java:18: Class java.util.HashMap not found in import.
import java.util.HashMap; ^ Line 0, column 0: could not parse error
message: error: Invalid class file format in
C:\jdk4\jre\lib\rt.jar(java/util/Stack.class). The major.minor version
'48.0' is too recent for this tool to understand. C:\Programmi\Apache
Group\Tomcat
4.1\work\Standalone\localhost\cocoon\cocoon-files\org\apache\cocoon\www\
sitemap_xmap.java:19: Class java.util.Stack not found in import. import
java.util.Stack; ^ Line 0, column 0: could not parse error message:
error: Invalid class file format in
C:\jdk4\jre\lib\rt.jar(java/util/StringTokenizer.class). The major.minor
version '48.0' is too recent for this tool to understand.
C:\Programmi\Apache Group\Tomcat
4.1\work\Standalone\localhost\cocoon\cocoon-files\org\apache\cocoon\www\
sitemap_xmap.java:20: Class java.util.StringTokenizer not found in
import. import java.util.StringTokenizer; ^ Line 0, column 0: error:
Invalid class file format in
C:\jdk4\jre\lib\rt.jar(java/lang/Object.class). The major.minor version
'48.0' is too recent for this tool to understand. error: Class
java.lang.Object not found in class
org.apache.avalon.framework.logger.AbstractLoggable. 18 errors

sender org.apache.cocoon.servlet.CocoonServlet

source Cocoon servlet

request-uri

/cocoon/
path-info




-
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: FW: i18n problem with i18n:attr : ArrayIndexOutOfBoundsException

[Joerg Heinicke]

Hello Thomas,

"once upon the time" there was a buggy Xerces version having problem 
with I18n attributes. We had this problem in the Cocoon 2.0.3 release 
with (I think) Xerces 2.0. After we upgraded the Xerces version 
everything works ok again. Lines like 
"org.xml.sax.helpers.AttributesImpl.removeAttribute(AttributesImpl.java:439)" 
in your stacktrace let me assume, that it is the same problem you have.

Regards,

Joerg

Thomas Haselberger wrote:
another try to get feedback for my problem:

-Original Message-
From: Thomas Haselberger 
Sent: Dienstag, 21. Jänner 2003 10:52
To: Cocoon-Users (E-mail)
Subject: i18n problem with i18n:attr : ArrayIndexOutOfBoundsException


I use cocoon 2.0.4 in tomcat 4.1.18 with j2sdk1.4.0_03.

the i18n samples that use i18n:attr work ok, but my i18n transformation throws an 
ArrayIndexOutOfBoundsException.

this is my source xml:
=


http://apache.org/cocoon/i18n/2.0";>
  

  ol
  new

  

=

this is my sitemap matcher entry:
=


  
  
  

=

and that's the error log entry generated:
=
ERROR   (2003-01-21) 10:50.44:761   [sitemap] (/idc/i18ntest/bla) Thread-15/sitemap_xmap: Sitemap
org.apache.cocoon.ProcessingException: Exception during processing of file:/D:/java/jakarta-tomcat-4.1.18/webapps/idc/content/wml_for_i18n.xml: java.lang.ArrayIndexOutOfBoundsException
	at org.apache.cocoon.components.source.AbstractStreamSource.toSAX(AbstractStreamSource.java:214)
	at org.apache.cocoon.generation.FileGenerator.generate(FileGenerator.java:143)
	at org.apache.cocoon.components.pipeline.CachingEventPipeline.process(CachingEventPipeline.java:250)
	at org.apache.cocoon.components.pipeline.CachingStreamPipeline.process(CachingStreamPipeline.java:395)
	at org.apache.cocoon.www.sitemap_xmap.matchN400126(D:\java\jakarta-tomcat-4.1.18\work\Standalone\localhost\idc\cocoon-files\org/apache/cocoon/www\sitemap_xmap.java:1345)
	at org.apache.cocoon.www.sitemap_xmap.process(D:\java\jakarta-tomcat-4.1.18\work\Standalone\localhost\idc\cocoon-files\org/apache/cocoon/www\sitemap_xmap.java:1185)
	at org.apache.cocoon.www.sitemap_xmap.process(D:\java\jakarta-tomcat-4.1.18\work\Standalone\localhost\idc\cocoon-files\org/apache/cocoon/www\sitemap_xmap.java:1128)
	at org.apache.cocoon.sitemap.Handler.process(Handler.java:227)
	at org.apache.cocoon.sitemap.Manager.invoke(Manager.java:173)
	at org.apache.cocoon.sitemap.SitemapManager.process(SitemapManager.java:152)
	at org.apache.cocoon.Cocoon.process(Cocoon.java:579)
	at org.apache.cocoon.servlet.CocoonServlet.service(CocoonServlet.java:1043)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:247)
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:193)
	at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:260)
	at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643)
	at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)
	at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
	at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643)
	at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)
	at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
	at org.apache.catalina.core.StandardContext.invoke(StandardContext.java:2415)
	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:180)
	at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643)
	at org.apache.catalina.valves.ErrorDispatcherValve.invoke(ErrorDispatcherValve.java:170)
	at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:641)
	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:172)
	at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:641)
	at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)
	at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:174)
	at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643)
	at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)
	at org.apache.catalina.core.Containe

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

[Robert Simmons]

> 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. Take
> a look at that technology and tell me how slow it is.

What CSS has to do with my question is beyond me.

>
> > User friendly? You've got to be joking.
>
> What? Cocoon? Well, here I think you must first understand the philosophy
> behind Cocoon and after that we can talk about that.

No no no. You arent gettign it. People dont WANT to understand the philosophy. Do I 
have to understand the JBoss development
philosophy to use it? Nope. What about Ant? Again nope. What about Tomcat? Agin the 
answer is no. You dont seem to be able to
separate the cocoon developer from the cocoon user. One is trying to contribute to the 
cocoon project but the rest of us just want
to use it to snap up a pipeline in 15 min. We honestly couldnt care less what the 
philosophy of its internal design is. Its
irrlevant to us. I get paid for makign applications for my company, not for learnign 
the concept of cocoon. If I have to learn the
philosophy behind how a tool is developed, that tool simply wont make the production 
schedule. Business life is hard. In addition,
according to object oriented philosophy, I shouldnt have to know the philosophy behind 
a tool. Cocoon should be a black box that i
can use to wire together sitemaps. The only time I need know anything is the interface 
I have to implement to design a new generator
and what xml file to declare it in. If someone asks me "how does cocoon work?" I 
should be able to say "beats me but it does." You
can bet that when .NET puts out their product it will be like that. Knowing Microsoft 
the product will be utter crap. However it
will trounce cocoon into the dust and people such as yourself will be staring at the 
carnage and saying "but WHY!!!???" The answer
is the same reason why many awesome technologies have never worked. They failed to 
attract interest and customers and never evolved.

> Windows makes us too lazy, we want to do all just clicking a mouse.

Welcome to business life reality. Your geek based (and I mean that as a complement) 
idealism jsut flat doesnt pay the bills.

> > No, I don't want to take up any more time from folks. I just simply
> > don't have the time to mess with it. Reading config files and figuring
> > out how the hell to build a new application just isn't what I want to do
> > a very trivial part of my project with.
>
> I will see you back again. Maybe the next year, how knows, but if you will
> stay at the development arena, you soon or late will be

Re: Cocoon is too complex for consumption?

[Perry Molendijk]

> The fact is that JSP continues to gather momentum and the era of XML-XSLT
has all but been forgotten. To what do you attribute this?
> XML and XSLT and by extension cocoon has a very narrow window to get some
serious press to make itself live. This window is passing by.

Funny that, I am kind booked out for most of the year with projects that
need XSLT written for their applications. One of them is cleaning up the
mess of having HTML and Java code in JSP nicely mixed up together. I don't
write a line of Java myself but I have observed is that writting "clean"
webapplications takes a fair bit of discipline that many developers don't
have, or it is usually simply too hard for them; "this how I always do it".

> If you ask me, the cocoon development effort should refocus itself from
developing more features to getting the product in a state
> such as tomcat is in. A state where people say "cocoon? Oh that's easy to
use. getting hello-world to work is like a 10 minute
> affair. You only need to worry about all the fancy features if you need to
use them, give it a shot."

OK the Cocoon doco needs work and the amount of features well out number the
amount of doco pages. But you can still get Hello World up in 10 minutes.
Most of the installation problems appear to be typical for all sorts of Java
applications: wrong, missing or conflicting jar files in various places..

Perry Molendijk


-
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: Using docbook chunk.xsl with cocoon

[Perry Molendijk]

 
> I can post details if that's the problem you're trying to solve.

Jeff that would be great if you could post this.

Thanks

Perry Molendijk 


-
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: XMLForm Xindice Howto added to Wiki [please, att. Ivelin]

[Ivelin Ivanov]

>
> > 3) Override the getForm() method in the action
> Wouldn't it be enough to override the getFormModel() method?

Yes. Your code looks good.

> Something like this:
>   protected Object getFormModel() {
>  //to load the XML model
>  Container DOMModel = null;
>  Source modelSrc = null;
>//this parameter holds the name of the xml file with the empty XML
> structure
> String modelFileName = getParameters().getParameter("xmlform-model",
> null);
> if(modelFileName==null) return null;
> try {
>  modelSrc = getSourceResolver().resolveURI(modelFileName);
>   DOMModel = new XMLDocumentContainer(new
> StreamSource(modelSrc.getInputStream()));
> return DOMModel;
>   }
>   catch ( Exception e) {
> throw new CascadingRuntimeException( " Failed instantiating form
> model ", e );
>   }
>   finally {
> getSourceResolver().release(modelSrc);
>   }
>   }
>
> > 4) Use the JXPath DOMContainer to load the xml file(constant)
> I have used XMLDocumentContainer. I see there's a DocumentContainer but
only
> present in JXPath 1.1 alpha and the jar file is still not included in
> Cocoon, so I used the soon to be deprecated mentioned.
> Btw, how could I extract a DOMNode from the root or an XML String so I
could
> store the whole structure afterwards? I see in 1.1alpha I could do
something
> like 'DocumentContainer.MODEL_DOM' but I guess in 1.0 I should get a
> JXPathContext and search for the root node so I can get the String I need.
> Am I right?

Absolutely. On all counts.

>
> > 5) Use the DOMContainer object as the Form model
> Ok. But where should I store it? In a separate file like the ArtistBean I
> got before?
> Or maybe would be enough to declare it and initialize it in the getForm()
or
> getFormModel() method?

Should do.

>
> > 6) When you need to reference a node in the model, instead of using the
> DOM
> > API, you can directly use XPath,
> > like this: getForm().getValue("/@id")
> At this stage I can only see the form and when trying to access the model
I
> get the following exception: 'Cannot setValue of an object that is not
some
> other object's property/child'

I am not sure why that is. Look at the source of the XMLFormTransformer and
see how it uses the Form.getValue() to access properties referenced via
"ref" attributes in an XMLForm source document.

>
> Sorry about all the questions but this is totally new for me and it is not
> easy.

Not a problem at all. I have been looking for a good XML data model & db
example for a long time.
You are getting up to speed very fast.



Cheers,


Ivelin




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

[SAXESS - Hussayn Dabbous]

Antonio,

sorry, i really misinterpreted your last email. Seems i was wrong
(big apologize!) this was really not meant against you.
Let me explain what i have in mind:

>In the OpenSources the things goes a diferent way. This is not a 
>company where are people getting money to support you. Then the
>less you can do is thanks people that use his time to help you.
>How you will fell if >somebody stop you at the street and start
>attacking you just because you dont >know where is the street
>called "X"? This is ridiculous, right? I think some people here
>had the same feel.

You are right in all points. i agree.
But i did not understand robert's criticism in this direction.
I understand, he attacks some severe critical points, which
should be taken into concern (hope this is correct english...)
I did not hear, "the cocooners shall do it", i heard
"this is may be a severe problem", which is a completely different
message so far ...

From my point of view: cocoon can only proove it's long turn
significance, if it is introduced into "business", where business
does not necessarily mean "commercial business". It means
to prove cocoon to be

* customisable
* developer friendly (not userfriendly!)
* stable
* performant
* scalable
* well documented
* downward (upward?) compatible
* ...

and much much more...

This proof is partially performed from all of those who use
cocoon in their "business" (including me ;-). But this proof
is not in first place a task of the cocoon comunity, but
it may be a task of a possibly commercial group, which takes
care on these things and stays in constant discussion with the
core development of cocoon. Yes and everyone, who wants to get
this cocoon++ should have to pay for it in some way, or has to
enhance it on his/her own ;-)

For me currently the most significant problem is, that cocoon is
moving too fast to get a grasp on it and start quality assurance
issues. Maybe this is what the cocoon comunity really have to
take care about: "Getting the system into a state, where it can
be quality assured..."

And this is where a must agree with Robert ...

You see: I am with cocoon, i love it, but i also see the big big
potential "success leaks" ;-)

regards, hussayn

Antonio Gallardo wrote:

Yes I know this point, but for this reason you cannot just come here and
after 12 hours, start attacking something you dont know. This is the worng
way. In place you can ask in another way.



Maybe we should calm down a bit and take this thread really
serious. It contains much of material to think about.
And in many senses the criticism here can't be discussed
away.



I never got angry. I agree.

Antonio Gallardo.




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



--
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: Cocoon is complex, HOLD ON, WHY IS THIS BOILING UP ?

[Robert Simmons]

Java and C++ both have places to start. You can get a Hello World up in about 5 
minutes. If you take the attitude "don't let the
door hit you in the ass on the way out," then people will head out and make sure the 
aforementioned door doesn't strike. This isn't
a game. Its not a toy. Its not something that can be said "like it or leave it." Its a 
technology. And the other newbies to this
product are likely not as tenacious as I am and will say "well to hell with it." 
Cocoon needs some SERIOUS work in the usability
zone. No no, I don't expect to understand it in 12 hours. Don't be ridicules. I do 
expect to be able to make a start on
understanding it in 12 hours though. Having Hello-World up in 12 hours is not exactly 
a steep request.

If the users have to build from source, which is NEVER a straightforward process, they 
will take off and find something easier. Ant,
for example, is massively extensible. I still don't understand I all 2 years after 
using it. However I'm a user and not a developer
of it. Therefore I don't care to understand it. Yes, there is allot more in ant that I 
can use but I don't need it professionally
and I don't have time to get into things that I don't need. I have NEVER built ant 
from source. Nor tomcat, nor JBoss, nor any of
the other TOOLS I use to accomplish my job. A job that has nothing to do with 
developing and understanding the architecture of
cocoon. So there is a dichotomy you are missing. The line between the developer and 
the user. The USERS don't have time to learn
Avalon and cocoon and a billion other things. All of this detail should be HIDDEN from 
them. Right now I get the impression that if
I ever did want to make my own generator, I would need to mount 50 jars into my 
NetBeans project. NOT AN OPTION. One jar, fine. 50,
no.

Cocoon is missing this layer of abstraction. The cocoon jar file should be packed with 
classes abstracting things out so people who
don't know jack about Avalon can write a generator or action. There should be a single 
jar (perhaps with contained jars) that I can
drop in some magic location and magically write cocoon apps. Configuring it should be 
a matter of minutes (if at all) not a matter
of hours to understand. I don't care about setting the properties of the WML 
serializer. I'm not even going to use the WML
serializer. My goal is to snap together a web site, route it through cocoon with my 
own sitemap and pipeline and go. Anything I
don't specify or configure should DEFAULT to pre-configured settings.

So yell "get the hell out!" all you want. People will. And instead of cocoon winning 
the race and capturing the minds and hearts of
web publishers, it will be .NET. The whole .NET framework should teach you something. 
If its too complex to understand, it will
LOOSE no matter how good it is. When the new users go to .NET and put up hello-world 
in 20 minutes, cocoon wont have a chance. So
cocoon has really two options in my newbie opinion. 1) Start putting in that layer 
that attracts new users. 2) Die.

As for me personally, I'm already far behind schedule now. 2 days of dealing with this 
thing and getting nowhere. Ill give it a
couple more hours of consideration and if I still cant get a hello-world up without 
knowing a thing about the internal architecture,
I will move on and implement it all in JSP. Scoff all you want. But a JSP hello-world 
page I was able to get up and working in 15
minutes.

-- Robert

- Original Message -
From: "Antonio Gallardo" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Sunday, January 26, 2003 1:38 AM
Subject: Re: Cocoon is complex, HOLD ON, WHY IS THIS BOILING UP ?


> SAXESS - Hussayn Dabbous dijo:
> > And especially the newbies can give so valuable insight, even if they
> seem to be ignorant (they aren't ignorant at all. They are new to this
> !!!)
>
> Yes I know this point, but for this reason you cannot just come here and
> after 12 hours, start attacking something you dont know. This is the worng
> way. In place you can ask in another way.
>
> Also, everyone of us had the same problem and feel when we started at
> Cocoon. This is crazy, my first question was: "When can I start?".
>
> But this is not a good approach sign-in on the mail list and start
> commenting about this. If you wish a well documented framework wait for
> the release of MS .NET of mid 2005 and maybe at that time you will have
> something that will looks that the current version of Cocoon. Of course
> Cocoon in that time will be light-years ahead! I am not joking. MS already
> has started a few months ago a similar project in the .NET arena.
>
> In the OpenSources the things goes a diferent way. This is not a company
> where are people getting money to support you. Then the less you can do is
> thanks people that use his time to help you. How you will fell if somebody
> stop you at the street and start attacking you just because you dont know
> where is the street called "X"? This is ridiculous, right? I thi

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

[Antonio Gallardo]

SAXESS - Hussayn Dabbous dijo:
> And especially the newbies can give so valuable insight, even if they
seem to be ignorant (they aren't ignorant at all. They are new to this
!!!)

Yes I know this point, but for this reason you cannot just come here and
after 12 hours, start attacking something you dont know. This is the worng
way. In place you can ask in another way.

Also, everyone of us had the same problem and feel when we started at
Cocoon. This is crazy, my first question was: "When can I start?".

But this is not a good approach sign-in on the mail list and start
commenting about this. If you wish a well documented framework wait for
the release of MS .NET of mid 2005 and maybe at that time you will have
something that will looks that the current version of Cocoon. Of course
Cocoon in that time will be light-years ahead! I am not joking. MS already
has started a few months ago a similar project in the .NET arena.

In the OpenSources the things goes a diferent way. This is not a company
where are people getting money to support you. Then the less you can do is
thanks people that use his time to help you. How you will fell if somebody
stop you at the street and start attacking you just because you dont know
where is the street called "X"? This is ridiculous, right? I think some
people here had the same feel.

Nobody is forced to convince you stay and for tis reason I better stay
away of this class of thread. If he does not want to get this nice stuff.
His problem, not mine. ;-) But I bet he will come back. I saw it many
times in the timeline.

At the end,

I remember the times when some people was attacking GUI, just because
there does not understand it. It was at my students days. Some
collegues told things like:

"Windows 3.1 requiere too many recurses and is so slow. This will never be
a good stuff" At that time (1992) a 286 with 1 MB and HD 40 MB was a super
computer for a student like us. i386 was the Opteron of these days (the
new 32-bits technology - wow!, like now is the transition to the new
64-bits technology - wow again! :-).

I remember one teacher that told:

"You think you are the 'great boys' just because you can open 30 windows
in your PC. I dont want to waste my eyes burning it with 640*468 pixel
lightning at my eyes!"

Behind his back we joking if he has a room at his house with his own
saloon computer all just for him!". Because for him our computers was toys
and nothing more.

Maybe you will be loling about this comments. But this was what we meet at
the University at my times. People that all the time used text terminal
and with the GUI revolution just starting they does not understand what
happens around and just attacking GUI.

Another example of this, the long discusion about if Java will survive or
not? We have C and C++!

Well, we are know at the doors of the Web revolution called XML. Please
open your eyes!

Best Regards,

Antonio Gallardo

>
> Maybe we should calm down a bit and take this thread really
> serious. It contains much of material to think about.
> And in many senses the criticism here can't be discussed
> away.

I never got angry. I agree.

Antonio Gallardo.




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

new wiki page CreateMinimalWebapp

[Geoff Howard]

http://wiki.cocoondev.org/Wiki.jsp?page=CreateMinimalWebapp

collaboration welcome.

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

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

[Geoff Howard]

Try to follow the instructions at the following page I just created:

http://wiki.cocoondev.org/Wiki.jsp?page=CreateMinimalWebapp

Ignore the comments obviously geared at making this part of the build (and
possibly part of the release.)

You'll need a source distribution of Cocoon 2.0.4, which I know is not what
you wanted but this is where things are now.

Following that, you should be able to get a hello world up and running based
on the existing documentation within an hour at least, and you could be
writing your own Generators tonight if you follow the tutorial I already
sent you a link to.

Geoff Howard

> -Original Message-
> From: Robert Simmons [mailto:[EMAIL PROTECTED]]
> Sent: Saturday, January 25, 2003 4:10 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Cocoon is complex, but worth it! Some Answers to your
> dilemma
>
>
> Thanks for the reply. I still, however, cant figure out how to
> get a "hello world" working on a clean war without all of the other
> crap in the cocoon war. The configuration file is just plain
> staggering to say the least.



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

[SAXESS - Hussayn Dabbous]

I wonder why sometimes when it comes to criticism of cocoon
the arguments fly higher and higher until someone gets
really pissed of and angry ...

And why is it so many times a newbie who becomes the center
of this game ? (Also one of my first newbie questions boiled
up beyond the limits, but i'm still there ...)

Please dont missunderstand me. In general i think the comunity
takes care of many many questions and very valuable information
is flowing around, but we also should take special care about any
strong criticism on cocoon. And especially the newbies can give
so valuable insight, even if they seem to be ignorant (they
aren't ignorant at all. They are new to this !!!)

Maybe we should calm down a bit and take this thread really
serious. It contains much of material to think about.
And in many senses the criticism here can't be discussed
away.

regards, hussayn

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


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

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

[Antonio Gallardo]

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

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


> 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. Take
a look at that technology and tell me how slow it is.

> User friendly? You've got to be joking.

What? Cocoon? Well, here I think you must first understand the philosophy
behind Cocoon and after that we can talk about that.

Windows makes us too lazy, we want to do all just clicking a mouse.

> No, I don't want to take up any more time from folks. I just simply
> don't have the time to mess with it. Reading config files and figuring
> out how the hell to build a new application just isn't what I want to do
> a very trivial part of my project with.

I will see you back again. Maybe the next year, how knows, but if you will
stay at the development arena, you soon or late will be faced again with
this technology. Please, Take a note of that.

Best Regards,

Antonio Gallardo.



-
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

[Antonio Gallardo]

You really does dont want the help people give you:

Please just click here:

http://wiki.cocoondev.org/Wiki.jsp?page=Tutorials

and you will be ready after 3 hours. Please read just the 1st tutorial
from IBM developerworks.

Antonio Gallardo.





-
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: A documents repository......

[Antonio Gallardo]

Julian, thanks for the tip. :-D

Antonio Gallardo

Julian Klein dijo:
> Antonio,
>
> Although my install seems a bit buggy, it may be worth
> your while to look into Slide and the slide webapp
> that is in the cocoon scratchpad.  I am sure it will
> be up to par shortly.  Besides, using different tools
> (e.g. POI), you could convert all your files into XML
> and then transform them as you please.
>
> -Julian
>
> --- Antonio Gallardo
> <[EMAIL PROTECTED]> wrote:
>> Yesterday, I was asked to find a solution for
>> document repository and as a
>> Open Source fan I went to sourceforge.net and found
>> Owl Intranet Engine:
>> http://owl.sourceforge.net/
>>
>> But as a Cocoon addict I thinked it is a fine
>> opportunity to test the
>> directory generator and a FileWriter interface that
>> currently is in
>> Cocoon.
>>
>> Can someone point me if this can be really easily
>> done in Cocoon?
>>
>> Best Regards,
>>
>> Antonio Gallardo
>>
>>
>>
>>
>>
> -
>> 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]>
>>
>
>
> =
> Live simply so others may simply live.
>
> -Ghandi
>
> Pluralitas non est ponenda sine neccesitate.
> "Entities should not be multiplied unneccesarily"
>
> -William of Occam
>
> __
> 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]>




-
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: WYSIWYG XSLT Editors?

[Antonio Gallardo]

Franck Lumpe dijo:
> Antonio,
>
> Thanks for the pointers.
>
> Maybe we should set up a page on the Wiki for XML Editing Best Practices
> (solutions for client processing, browser-based solutions, practical
> WebDav, etc.)
>
> Not specifically a Cocoon issue but an important part of the
> implementation process.
> There is no publishing if there is no content!

Yes, it is true. These are the complement to Cocoon. How to tell people
about changing to XML if they does not have a easy way to publish his
work?
I think in this area OpenOffice is making a great job.

Best Regards,

Antonio Gallardo
>
> Regards,
>
> Franck Lumpe
>
>
>>
>> Please check:
>>
>> http://xml.openoffice.org/sx2ml/
>> http://xml.openoffice.org/saxecho/
>> http://www.xml.com/pub/a/2001/02/07/openoffice.html
>>
>> Antonio Gallardo
>>
>>
>
>
> -
> 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]>

I got this error

[Giovanni Di Lembo]

I got this error installing cocoon 2.0.1 with tomcat 4.1.8 and with jdk
1.4

WHY?

 type fatal

message Language Exception

description org.apache.cocoon.ProcessingException: Language Exception:
org.apache.cocoon.components.language.LanguageException: Error compiling
sitemap_xmap: Line 0, column 0: could not parse error message: error:
Invalid class file format in
C:\jdk4\jre\lib\rt.jar(java/io/OutputStream.class). The major.minor
version '48.0' is too recent for this tool to understand.
C:\Programmi\Apache Group\Tomcat
4.1\work\Standalone\localhost\cocoon\cocoon-files\org\apache\cocoon\www\
sitemap_xmap.java:12: Class java.io.OutputStream not found in import.
import java.io.OutputStream; ^ Line 0, column 0: could not parse error
message: error: Invalid class file format in
C:\jdk4\jre\lib\rt.jar(java/io/IOException.class). The major.minor
version '48.0' is too recent for this tool to understand.
C:\Programmi\Apache Group\Tomcat
4.1\work\Standalone\localhost\cocoon\cocoon-files\org\apache\cocoon\www\
sitemap_xmap.java:13: Class java.io.IOException not found in import.
import java.io.IOException; ^ Line 0, column 0: could not parse error
message: error: Invalid class file format in
C:\jdk4\jre\lib\rt.jar(java/util/List.class). The major.minor version
'48.0' is too recent for this tool to understand. C:\Programmi\Apache
Group\Tomcat
4.1\work\Standalone\localhost\cocoon\cocoon-files\org\apache\cocoon\www\
sitemap_xmap.java:15: Class java.util.List not found in import. import
java.util.List; ^ Line 0, column 0: could not parse error message:
error: Invalid class file format in
C:\jdk4\jre\lib\rt.jar(java/util/ArrayList.class). The major.minor
version '48.0' is too recent for this tool to understand.
C:\Programmi\Apache Group\Tomcat
4.1\work\Standalone\localhost\cocoon\cocoon-files\org\apache\cocoon\www\
sitemap_xmap.java:16: Class java.util.ArrayList not found in import.
import java.util.ArrayList; ^ Line 0, column 0: could not parse error
message: error: Invalid class file format in
C:\jdk4\jre\lib\rt.jar(java/util/Map.class). The major.minor version
'48.0' is too recent for this tool to understand. C:\Programmi\Apache
Group\Tomcat
4.1\work\Standalone\localhost\cocoon\cocoon-files\org\apache\cocoon\www\
sitemap_xmap.java:17: Class java.util.Map not found in import. import
java.util.Map; ^ Line 0, column 0: could not parse error message: error:
Invalid class file format in
C:\jdk4\jre\lib\rt.jar(java/util/HashMap.class). The major.minor version
'48.0' is too recent for this tool to understand. C:\Programmi\Apache
Group\Tomcat
4.1\work\Standalone\localhost\cocoon\cocoon-files\org\apache\cocoon\www\
sitemap_xmap.java:18: Class java.util.HashMap not found in import.
import java.util.HashMap; ^ Line 0, column 0: could not parse error
message: error: Invalid class file format in
C:\jdk4\jre\lib\rt.jar(java/util/Stack.class). The major.minor version
'48.0' is too recent for this tool to understand. C:\Programmi\Apache
Group\Tomcat
4.1\work\Standalone\localhost\cocoon\cocoon-files\org\apache\cocoon\www\
sitemap_xmap.java:19: Class java.util.Stack not found in import. import
java.util.Stack; ^ Line 0, column 0: could not parse error message:
error: Invalid class file format in
C:\jdk4\jre\lib\rt.jar(java/util/StringTokenizer.class). The major.minor
version '48.0' is too recent for this tool to understand.
C:\Programmi\Apache Group\Tomcat
4.1\work\Standalone\localhost\cocoon\cocoon-files\org\apache\cocoon\www\
sitemap_xmap.java:20: Class java.util.StringTokenizer not found in
import. import java.util.StringTokenizer; ^ Line 0, column 0: error:
Invalid class file format in
C:\jdk4\jre\lib\rt.jar(java/lang/Object.class). The major.minor version
'48.0' is too recent for this tool to understand. error: Class
java.lang.Object not found in class
org.apache.avalon.framework.logger.AbstractLoggable. 18 errors

sender org.apache.cocoon.servlet.CocoonServlet

source Cocoon servlet

request-uri

/cocoon/
path-info


-
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: XSLT debugger (was RE: .Net port of Cocoon)

[Michael Schneider]

I use Komodo from activate state   http://www.activestate.com


- Original Message -
From: "Luca Morandini" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, January 24, 2003 6:50 AM
Subject: RE: XSLT debugger (was RE: .Net port of Cocoon)


> Mark,
>
> I don't use XSLT debuggers, I've just configured logkit to put all
messages produced by Xalan into a single log file.
>
> LogTransformer, as Antonio pointed out, could be useful too.
>
> Nevertheless, there are a number of XSLT debuggers out there, which, if
you save the XML document before the XSLT stage into a file,
> could be used to debug your XSLT... but I never tried them.
>
> Regards,
>
> -
>Luca Morandini
>GIS Consultant
>   [EMAIL PROTECTED]
> http://utenti.tripod.it/lmorandini/index.html
> -
>
>
> > -Original Message-
> > From: Mark H [mailto:[EMAIL PROTECTED]]
> > Sent: Friday, January 24, 2003 12:20 PM
> > To: [EMAIL PROTECTED]
> > Subject: XSLT debugger (was RE: .Net port of Cocoon)
> >
> >
> > >AFAIK, there is no single debugger like this, only a patchwork of
> > debuggers, one for XSLT, one for Java...
> >
> > Where can I get hold of a XSLT debugger to use with cocoon? a lot of
times
> > cocoon doesn't provide much debugging information when there is
something
> > wrong with your stylesheets.
> >
> > Mark
> >
> > -Original Message-
> > From: Luca Morandini [mailto:[EMAIL PROTECTED]]
> > Sent: 23 January 2003 17:09
> > To: [EMAIL PROTECTED]
> > Subject: RE: .Net port of Cocoon
> >
> >
> > > -Original Message-
> > > From: Vadim Gritsenko [mailto:[EMAIL PROTECTED]]
> > > Sent: Thursday, January 23, 2003 5:05 PM
> > > To: [EMAIL PROTECTED]
> > > Subject: Re: .Net port of Cocoon
> >
> > > >
> > > >Granted, there is no debugger in Cocoon,
> > > >
> > >
> > > ... and shoud not be: all IDEs as well as JDK has debuggers. Use them
> > > remotely or start your servlet engine from under it - in either case
you
> > > can put breakpoints and debug your Java.
> > >
> > > /me goes back to lurking
> > > Vadim
> >
> > Vadim,
> >
> > let's get this straight: since Cocoon is composed of many technologies,
a
> > Java debugger alone cannot do the work.
> >
> > I'd like to debug my XSLT, see the parameters' values as they flow from
the
> > sitemap to the XSLT, check every stage's XML output, set
> > breakpoints in Actions... and more: this is what an ideal Cocoon
debugger
> > should do.
> >
> > AFAIK, there is no single debugger like this, only a patchwork of
debuggers,
> > one for XSLT, one for Java...
> >
> >
> > 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]>
> >
>
>
> -
> 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]>

FW: i18n problem with i18n:attr : ArrayIndexOutOfBoundsException

[Thomas Haselberger]

another try to get feedback for my problem:

-Original Message-
From: Thomas Haselberger 
Sent: Dienstag, 21. Jänner 2003 10:52
To: Cocoon-Users (E-mail)
Subject: i18n problem with i18n:attr : ArrayIndexOutOfBoundsException


I use cocoon 2.0.4 in tomcat 4.1.18 with j2sdk1.4.0_03.

the i18n samples that use i18n:attr work ok, but my i18n transformation throws an 
ArrayIndexOutOfBoundsException.

this is my source xml:
=


http://apache.org/cocoon/i18n/2.0";>
  

  ol
  new

  

=

this is my sitemap matcher entry:
=


  
  
  

=

and that's the error log entry generated:
=
ERROR   (2003-01-21) 10:50.44:761   [sitemap] (/idc/i18ntest/bla) 
Thread-15/sitemap_xmap: Sitemap
org.apache.cocoon.ProcessingException: Exception during processing of 
file:/D:/java/jakarta-tomcat-4.1.18/webapps/idc/content/wml_for_i18n.xml: 
java.lang.ArrayIndexOutOfBoundsException
at 
org.apache.cocoon.components.source.AbstractStreamSource.toSAX(AbstractStreamSource.java:214)
at org.apache.cocoon.generation.FileGenerator.generate(FileGenerator.java:143)
at 
org.apache.cocoon.components.pipeline.CachingEventPipeline.process(CachingEventPipeline.java:250)
at 
org.apache.cocoon.components.pipeline.CachingStreamPipeline.process(CachingStreamPipeline.java:395)
at 
org.apache.cocoon.www.sitemap_xmap.matchN400126(D:\java\jakarta-tomcat-4.1.18\work\Standalone\localhost\idc\cocoon-files\org/apache/cocoon/www\sitemap_xmap.java:1345)
at 
org.apache.cocoon.www.sitemap_xmap.process(D:\java\jakarta-tomcat-4.1.18\work\Standalone\localhost\idc\cocoon-files\org/apache/cocoon/www\sitemap_xmap.java:1185)
at 
org.apache.cocoon.www.sitemap_xmap.process(D:\java\jakarta-tomcat-4.1.18\work\Standalone\localhost\idc\cocoon-files\org/apache/cocoon/www\sitemap_xmap.java:1128)
at org.apache.cocoon.sitemap.Handler.process(Handler.java:227)
at org.apache.cocoon.sitemap.Manager.invoke(Manager.java:173)
at org.apache.cocoon.sitemap.SitemapManager.process(SitemapManager.java:152)
at org.apache.cocoon.Cocoon.process(Cocoon.java:579)
at org.apache.cocoon.servlet.CocoonServlet.service(CocoonServlet.java:1043)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at 
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:247)
at 
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:193)
at 
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:260)
at 
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
at 
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
at 
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
at org.apache.catalina.core.StandardContext.invoke(StandardContext.java:2415)
at 
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:180)
at 
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643)
at 
org.apache.catalina.valves.ErrorDispatcherValve.invoke(ErrorDispatcherValve.java:170)
at 
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:641)
at 
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:172)
at 
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:641)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
at 
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:174)
at 
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
at org.apache.coyote.tomcat4.CoyoteAdapter.service(CoyoteAdapter.java:223)
at org.apache.coyote.http11.Http11Processor.process(

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

[Steven Noels]

Robert Simmons wrote:


know. The Wiki page runs very slow for me and a tutorial linked to me


again: _what_ Wiki are you referring to? If it's 
http://wiki.cocoondev.org/, please quantify how slow, so that I can get 
a grip on it. That Wiki is built using plain JSP & taglibs, BTW. Nothing 
to do with Cocoon.


--
Steven Noelshttp://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog athttp://blogs.cocoondev.org/stevenn/
stevenn at outerthought.orgstevenn at apache.org


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

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

[SAXESS - Hussayn Dabbous]

depending on what you are doing with cocoon, you get
quite amazing performance due to caching. My website
is completely done in XML and using cocoon. and its
almost as performant as with ordinary html. I was
really amazed when i saw this although the site is super
simple... http://www.saxess.de

I your use case is more complex, you are hitting databases
and creating dynamic data, you will allways suffer from
performance. This has nothing to do with cocon.

And if you talk about performace, you have to take into
account, what cocoon does under the hood (XSLT is always
a performance problem).

regards, hussayn


Robert Simmons wrote:

Thanks for the reply. I still, however, cant figure out how to get a "hello world" working on a clean war without all of the other
crap in the cocoon war. The configuration file is just plain staggering to say the least. And looking at some pages that use cocoon,
I'm starting to have second thoughts about its performance in high traffic situation. Quite honestly I'm pretty close to saying
"hell with it" and just coding the interface in JSP. Although it might be powerful, if it isn't easy, its trash. No professional dev
wants, or has the time, to blow 2 to three weeks just to get separation of logic and presentation. Too high of a price for too
little gain.

Powerful? I believe you. I believe its powerful. Scalable? I don't know. 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. 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.
User friendly? You've got to be joking.

No, I don't want to take up any more time from folks. I just simply don't have the time to mess with it. Reading config files and
figuring out how the hell to build a new application just isn't what I want to do a very trivial part of my project with.

-- Robert

- Original Message -
From: "SAXESS - Hussayn Dabbous" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Saturday, January 25, 2003 9:52 PM
Subject: Re: Cocoon is complex, but worth it! Some Answers to your dilemma




I am with cocoon for about three months now and i remember
my own frustrations when i started as a newbie. From this
thread and other emails within this list and from my personal
experience with cocoon i conclude:

1.) cocoon gains high (initial) attraction (many newbies questions)
2.) cocoon is not easy to apply by newbies (see this thread ;-)
3.) cocoon is far away from getting mature (focus on dev HEAD)
dont missunderstand me: i mean it's robust but complex,
fast evolving and ever changing ...

But if you look under the hood you also find:

4.) cocoon provides a very exciting technology.
5.) cocoon IS actively developed.
6.) cocoon attracts commercial interests (projects)


I assume everybody getting attracted to cocoon has some
ideas in mind what he/she wants to do with it, but after
opening the box it is (at first) hard to see how you could
gain from cocoon within your projects. And i think that
at least in commercial projects what counts is the amount
of time you need to get it mastered.


The (non developing) users seem to suffer from

* undocumented features (wholes in documentation)
* complexity, even if the parts of interest
  are well documented.
* huge amount of loosely coupled docs and documentation
  sites.
* lack of "out of the box" applications that can be
  used right from the initial installation (maybe
  the cocoon portal is an exception, but it's also
  really complex for the newbies, isn't it ?)
* functional overkill
* Lack of debugging facilities especially for sitemap
  checking.
* very poor error reporting. You have to dig within tons of
  stack traces to get a clue ... Sometimes you even get
  no error report at all, it simply doesn't work.


But it is also true, that once you have mastered the
cocoon basics and once you start understanding how
things work, you suddenly get so much out of it,
that all your initial efforts get payed back.

Because cocoon is something i really want to support,
i started a Wiki page that adresses some of the most
hearting issues. Hopefully this work can be
used (and improved) also by others:

http://wiki.cocoondev.org/Wiki.jsp?page=SurvivalTips

Besides this i recommend to have a look at the
"cocoon developer's handbook" (developer's library)
This book is now my "good companion" in the cocoon
adventure.

Since i use cocoon within commercial projects i
had the oportunity to give away a small subproject
to one of the cocoon developers and i was really
positively surprised from the quality of the work
i got back. Hence i would recommend to all other
project managers out in the world:

simply ask for support from the cocoon comunity and
i am shure, you will either get your problems
solved "on the fly" or you will find excellent experts
who will be happy to get 

Re: Cocoon. More Answers to your dilemma

[SAXESS - Hussayn Dabbous]

There is one problem with your approach:

What if your webapp uses different versions of
commonly used jars ?

I had this problem with one of my webapps, that
internally used an older version of the avalon
framework and some other jars incompatible to
my cocoon-2.0.4. I tried hard to get my webapp integrated
into cocoon and finally i gave up and came to following
solution:

1.) I set up a clean cocoon webapp
2.) I create a sitemap only for presentation
issues (the web frontend of my webapp)
and instrument what i need for this purpose
into a subdirectory within the cocoon app.
3.) I set up my "legacy" application completely
separated from cocoon
4.) I created an XML interface that consists
primarily of a bunch of jsp's that interact
with my legacy app and spill out XML to cocoon.
I could have used exis of course, but the interface
was not soo complex...

By this a could cleanly separate my legacy application
from my frontend. I had not to deal with compatibility
issues and i ended up in a very nice presentation layer.
What i liked most about this is the (almoust) total
separation of logic from presentation ;-)

There was only one caveat to master: My apps are under
authentification control. Therefore we implemented
a session aware protocol named "proxy:" that allows
under certain circumstances to transparently transfer
cookies between the browser and the legacyapplication.
Currently both apps must run in the same container and
the container must provide SSO. But i hope this limitation
can be eliminated in the near future...

regards, hussayn


Julian Klein wrote:

Robert,



I want all
the framework configs out of my way. I want all of
the options and jars and so on neatly tucked away
and where I can just drop them
in a directory and forget about them.



You can do one of two things with the jars.

1)The Cocoon war by default has all of them stored in
a certain lib directory.  When you unpack the war in
Tomcat on startup the path would be as follows
(assuming the war is in the $TOMCAT_HOME/webapps
directory on startup):
$TOMCAT_HOME/webapps/cocoon/WEB-INF/lib.  This way all
the jars are available to the servlet container that
is running the cocoon app and localized to this
directory.

2)You could move all these jars to $TOMCAT_HOME/lib or
if you are running a newer version of Tomcat
(e.g.4.1.12) then it would be $TOMCAT_HOME/common/lib.
 If you put the jars here they will be available to
all webapps running in Tomcat and be localized. 
Unlike the first option, this allows a more "public"
feel to your jars (the first is more like a
"protected" feel to the jars).

NOTE:All that was Tomcat specific deployment info, not
Cocoon.  So the Cocoon developers have used the first
option to allow these jars to be localized and clean.

The jars can also be found at:
xml-cocoon/build/cocoon/webapp/WEB-INF/lib


Now Id like to have a war that is THAT small and
without having to have an intimate knowledge of
cocoon to accomplish it. 


You would have to build Cocoon from the CVS source
code and modify the Ant build script to stop the
packaging of jars in the cocoon war.  This requires a
minimal knowledge of Ant.



-->--> web.xml  (NOT a 40 meg file)



Finally, the web.xml that comes with Cocoon in only a
few Ks.  So it should never be more, unless you have
added A LOT of servlet mappings, but that must be
proprietary.

Hope this helps,
Julian



=
Live simply so others may simply live.
 
-Ghandi
 
Pluralitas non est ponenda sine neccesitate.
"Entities should not be multiplied unneccesarily"
 
-William of Occam

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


--
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: Cocoon is complex, but worth it! Some Answers to your dilemma

[Robert Simmons]

Thanks for the reply. I still, however, cant figure out how to get a "hello world" 
working on a clean war without all of the other
crap in the cocoon war. The configuration file is just plain staggering to say the 
least. And looking at some pages that use cocoon,
I'm starting to have second thoughts about its performance in high traffic situation. 
Quite honestly I'm pretty close to saying
"hell with it" and just coding the interface in JSP. Although it might be powerful, if 
it isn't easy, its trash. No professional dev
wants, or has the time, to blow 2 to three weeks just to get separation of logic and 
presentation. Too high of a price for too
little gain.

Powerful? I believe you. I believe its powerful. Scalable? I don't know. 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. 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.
User friendly? You've got to be joking.

No, I don't want to take up any more time from folks. I just simply don't have the 
time to mess with it. Reading config files and
figuring out how the hell to build a new application just isn't what I want to do a 
very trivial part of my project with.

-- Robert

- Original Message -
From: "SAXESS - Hussayn Dabbous" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Saturday, January 25, 2003 9:52 PM
Subject: Re: Cocoon is complex, but worth it! Some Answers to your dilemma


> I am with cocoon for about three months now and i remember
> my own frustrations when i started as a newbie. From this
> thread and other emails within this list and from my personal
> experience with cocoon i conclude:
>
> 1.) cocoon gains high (initial) attraction (many newbies questions)
> 2.) cocoon is not easy to apply by newbies (see this thread ;-)
> 3.) cocoon is far away from getting mature (focus on dev HEAD)
>  dont missunderstand me: i mean it's robust but complex,
>  fast evolving and ever changing ...
>
> But if you look under the hood you also find:
>
> 4.) cocoon provides a very exciting technology.
> 5.) cocoon IS actively developed.
> 6.) cocoon attracts commercial interests (projects)
>
>
> I assume everybody getting attracted to cocoon has some
> ideas in mind what he/she wants to do with it, but after
> opening the box it is (at first) hard to see how you could
> gain from cocoon within your projects. And i think that
> at least in commercial projects what counts is the amount
> of time you need to get it mastered.
>
>
> The (non developing) users seem to suffer from
>
> * undocumented features (wholes in documentation)
> * complexity, even if the parts of interest
>are well documented.
> * huge amount of loosely coupled docs and documentation
>sites.
> * lack of "out of the box" applications that can be
>used right from the initial installation (maybe
>the cocoon portal is an exception, but it's also
>really complex for the newbies, isn't it ?)
> * functional overkill
> * Lack of debugging facilities especially for sitemap
>checking.
> * very poor error reporting. You have to dig within tons of
>stack traces to get a clue ... Sometimes you even get
>no error report at all, it simply doesn't work.
>
>
> But it is also true, that once you have mastered the
> cocoon basics and once you start understanding how
> things work, you suddenly get so much out of it,
> that all your initial efforts get payed back.
>
> Because cocoon is something i really want to support,
> i started a Wiki page that adresses some of the most
> hearting issues. Hopefully this work can be
> used (and improved) also by others:
>
> http://wiki.cocoondev.org/Wiki.jsp?page=SurvivalTips
>
> Besides this i recommend to have a look at the
> "cocoon developer's handbook" (developer's library)
> This book is now my "good companion" in the cocoon
> adventure.
>
> Since i use cocoon within commercial projects i
> had the oportunity to give away a small subproject
> to one of the cocoon developers and i was really
> positively surprised from the quality of the work
> i got back. Hence i would recommend to all other
> project managers out in the world:
>
> simply ask for support from the cocoon comunity and
> i am shure, you will either get your problems
> solved "on the fly" or you will find excellent experts
> who will be happy to get involved in your projects as
> freelancers...
>
> I hope that cocoon will master it's own future
> and eventually become "the tomcat of XML-publishing"
>
> regards, Hussayn
>
> --
> Dr. Hussayn Dabbous
> SAXESS Software Design GmbH
> Neuenhöfer Allee 125
> 50935 Köln
> Telefon: +49-221-56011-0
> Fax: +49-221-56011-20
> E-Mail:  [EMAIL PROTECTED]
>
>
> -
> Please check that your question  has not already been answered

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

[SAXESS - Hussayn Dabbous]

I am with cocoon for about three months now and i remember
my own frustrations when i started as a newbie. From this
thread and other emails within this list and from my personal
experience with cocoon i conclude:

1.) cocoon gains high (initial) attraction (many newbies questions)
2.) cocoon is not easy to apply by newbies (see this thread ;-)
3.) cocoon is far away from getting mature (focus on dev HEAD)
dont missunderstand me: i mean it's robust but complex,
fast evolving and ever changing ...

But if you look under the hood you also find:

4.) cocoon provides a very exciting technology.
5.) cocoon IS actively developed.
6.) cocoon attracts commercial interests (projects)


I assume everybody getting attracted to cocoon has some
ideas in mind what he/she wants to do with it, but after
opening the box it is (at first) hard to see how you could
gain from cocoon within your projects. And i think that
at least in commercial projects what counts is the amount
of time you need to get it mastered.


The (non developing) users seem to suffer from

* undocumented features (wholes in documentation)
* complexity, even if the parts of interest
  are well documented.
* huge amount of loosely coupled docs and documentation
  sites.
* lack of "out of the box" applications that can be
  used right from the initial installation (maybe
  the cocoon portal is an exception, but it's also
  really complex for the newbies, isn't it ?)
* functional overkill
* Lack of debugging facilities especially for sitemap
  checking.
* very poor error reporting. You have to dig within tons of
  stack traces to get a clue ... Sometimes you even get
  no error report at all, it simply doesn't work.


But it is also true, that once you have mastered the
cocoon basics and once you start understanding how
things work, you suddenly get so much out of it,
that all your initial efforts get payed back.

Because cocoon is something i really want to support,
i started a Wiki page that adresses some of the most
hearting issues. Hopefully this work can be
used (and improved) also by others:

http://wiki.cocoondev.org/Wiki.jsp?page=SurvivalTips

Besides this i recommend to have a look at the
"cocoon developer's handbook" (developer's library)
This book is now my "good companion" in the cocoon
adventure.

Since i use cocoon within commercial projects i
had the oportunity to give away a small subproject
to one of the cocoon developers and i was really
positively surprised from the quality of the work
i got back. Hence i would recommend to all other
project managers out in the world:

simply ask for support from the cocoon comunity and
i am shure, you will either get your problems
solved "on the fly" or you will find excellent experts
who will be happy to get involved in your projects as
freelancers...

I hope that cocoon will master it's own future
and eventually become "the tomcat of XML-publishing"

regards, Hussayn

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


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

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

Re: WYSIWYG XSLT Editors?

[Julian Klein]

Ckeck out these XML editors:

http://xopus.org/index.jsp?menu=info

http://bitfluxeditor.org/

-Julian

=
Live simply so others may simply live.
 
-Ghandi
 
Pluralitas non est ponenda sine neccesitate.
"Entities should not be multiplied unneccesarily"
 
-William of Occam

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

Re: Cocoon. More Answers to your dilemma

[Julian Klein]

Robert,

> I want all
> the framework configs out of my way. I want all of
> the options and jars and so on neatly tucked away
> and where I can just drop them
> in a directory and forget about them.

You can do one of two things with the jars.

1)The Cocoon war by default has all of them stored in
a certain lib directory.  When you unpack the war in
Tomcat on startup the path would be as follows
(assuming the war is in the $TOMCAT_HOME/webapps
directory on startup):
$TOMCAT_HOME/webapps/cocoon/WEB-INF/lib.  This way all
the jars are available to the servlet container that
is running the cocoon app and localized to this
directory.

2)You could move all these jars to $TOMCAT_HOME/lib or
if you are running a newer version of Tomcat
(e.g.4.1.12) then it would be $TOMCAT_HOME/common/lib.
 If you put the jars here they will be available to
all webapps running in Tomcat and be localized. 
Unlike the first option, this allows a more "public"
feel to your jars (the first is more like a
"protected" feel to the jars).

NOTE:All that was Tomcat specific deployment info, not
Cocoon.  So the Cocoon developers have used the first
option to allow these jars to be localized and clean.

The jars can also be found at:
xml-cocoon/build/cocoon/webapp/WEB-INF/lib

> Now Id like to have a war that is THAT small and
> without having to have an intimate knowledge of
> cocoon to accomplish it. 

You would have to build Cocoon from the CVS source
code and modify the Ant build script to stop the
packaging of jars in the cocoon war.  This requires a
minimal knowledge of Ant.

> -->--> web.xml  (NOT a 40 meg file)

Finally, the web.xml that comes with Cocoon in only a
few Ks.  So it should never be more, unless you have
added A LOT of servlet mappings, but that must be
proprietary.

Hope this helps,
Julian



=
Live simply so others may simply live.
 
-Ghandi
 
Pluralitas non est ponenda sine neccesitate.
"Entities should not be multiplied unneccesarily"
 
-William of Occam

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

Re: WYSIWYG XSLT Editors?

[Franck Lumpe]

Antonio,

Thanks for the pointers.

Maybe we should set up a page on the Wiki for XML Editing Best Practices
(solutions for client processing, browser-based solutions, practical WebDav,
etc.)

Not specifically a Cocoon issue but an important part of the implementation
process.
There is no publishing if there is no content!

Regards,

Franck Lumpe


>
> Please check:
>
> http://xml.openoffice.org/sx2ml/
> http://xml.openoffice.org/saxecho/
> http://www.xml.com/pub/a/2001/02/07/openoffice.html
>
> Antonio Gallardo
>
>


-
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

[Robert Simmons]

Great. Thanks for the information. However the questions are still thick as pea soup.

If I don't want to deploy all the cocoon jars in my war, I have to put them somewhere. 
It has been suggested that I put them in the
tomcat lib directory. Ok fine, then how does one configure it?

My goal is to end up with a hello-world war that looks like

myapp.war
--> META-INF
-->--> MANIFEST.MF
-->WEB-INF
-->--> web.xml  (NOT a 40 meg file)
-->--> jboss-web.xml
-->--> classes
-->-->--> my action or generator classes.
--> XSL
-->--> My stlye sheets.
--> XSD
-->--> My schema
--> Other static files.
--> my sitemap

Now Id like to have a war that is THAT small and without having to have an intimate 
knowledge of cocoon to accomplish it. I want all
the framework configs out of my way. I want all of the options and jars and so on 
neatly tucked away and where I can just drop them
in a directory and forget about them.

I'm seeking USER based simplicity and haven't found it yet. If I had time from my busy 
schedule I would potentially join the
development effort to get this user simplicity but unfortunately joining cocoon and 
learning its development wont pay my electric
bills. I have a book to write and the interface to my server for my book should be 
superfluous, not massively complex. The book is
about the server side and I only need the interact to demonstrate what I'm doing on 
the server side.

-- Robert



- Original Message -
From: "Julian Klein" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Saturday, January 25, 2003 7:58 PM
Subject: Re: Cocoon is complex, but worth it! Some Answers to your dilemma


> First off I made some suggestions to your
> questions/problems below...skip ahead if you don't
> want my commentary on Cocoon.
>
> Well it seems to me that when I started with Cocoon, I
> was hoping to jump right on in.  Unfortunately, it was
> not that easy, but not b/c of Cocoon, rather my
> limited knowledge of xpath and xsl functions.  Anyway,
> I tackled these problems by studying the applications
> samples packaged with cocoon and reading the
> documentation.  It may be discouraging, but anything
> worthwhile can't be done overnight, right?  Anyway, as
> I work more and more with Cocoon, I am amazed by the
> genius of it's architecture.  Cocoon is certainly a
> tribute to Open Source and the greatness of those out
> there working on and contributing to it.  Stick to it
> and you will be repaid.
>
>
>
> 
> It seems if you have a servlet working, you must be
> looking to upgrade.  So you should not be looking for
> an overnight solution, which is easy with all the
> options out there.  Overall, the advice I can give is
> you must consider:
>
> 1)Are you going to use Cocoon for more than just a
> replacement for your servlet?
>
> 2)What technologies do you want to use: XSP,XSLT,etc.
>
> 3)You do not need to build from the CVS source, you
> can just download a pre-built version from the site
> (nightly or major release)
> http://xml.apache.org/dist/cocoon/
>
> 4)You may not need to create a new transformer, but
> perhaps just make an action.
> http://xml.apache.org/cocoon/userdocs/concepts/actions.html
>
> 5)You prob need a minimal sitemap(see below) to match
> your url requests to your data.  No need to worry
> about the endless options now.  The beauty is you will
> learn them as you go and find that Cocoon has almost
> everything you could ever need.
>
> 6)Look over the user's guide and study some of the
> sitemaps packages with Cocoon.
>
> I hope this makes some sense. If not, I 'm sorry, but
> I feel as if Cocoon is a great way to go if you want
> to do more than just replace your serlvlet.  With all
> the users, developers, wiki, documentation, and
> mailing lists...you will almost always get an answer.
> Whether or not it makes sense ;-) !  I attached a
> basic sitemap to get you going...
>
> -Julian
>
> 
>  xmlns:map="http://apache.org/cocoon/sitemap/1.0";>
>
> 
>
>  
>   
>
>   
>
>   
>
>   
> mime-type="text/xml" name="xml"
>
> src="org.apache.cocoon.serialization.XMLSerializer"/>
>
> mime-type="text/html" name="html"
>pool-grow="4" pool-max="32"
> pool-min="4"
>
> src="org.apache.cocoon.serialization.HTMLSerializer">
> 1024
>
>   
>
>   
>
>   
>
>  
>
>
> 
>  
>   
>
>
>
> 
> 
> 
>
>
> 
> 
> 
>
>
>
>  
>
>
>
>  mime-type="image/png"/>
>
>
>
>  mime-type="image/jpeg"/>
>
>
>
>  src="context://task/stylesheets/error2html.xsl"/>
> 
>
>
>   
> 
> 
>
> =
> Live simply so others may simply live.
>
> -Ghandi
>
> Pluralitas non est ponenda sine neccesitate.
> "Entities should not be multiplied unneccesarily"
>
> -William of Occam
>
> __
> Do you Yahoo!?
> Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
> http

Re: AW: AW: Action Not Adding Values to Sitemap or is it?

[Julian Klein]

MArco,

Thanks, but it is not the action.  Before I even put
it in, I had this problem.  So it seems to be the
pseudo-protocol of Cocoon or the Xindice db.  I will
look into it more, but for now I will stick to what I
have going...a working app!  Thanks again.

-Julian

--- Marco Rolappe <[EMAIL PROTECTED]> wrote:
> hi julian,
> 
> sorry, I haven't worked with XIndice yet. but from
> looking at the XIndice
> sources the NPE seems to be caused by the key being
> null. as already
> mentionend, I'm not into XIndice so I don't know
> where that key is being
> specified (created by your action, maybe?), but
> perhaps this info helps you
> finding the problem.
> 
> 
> -Ursprungliche Nachricht-
> Von:
>
[EMAIL PROTECTED]
>
[mailto:[EMAIL PROTECTED]]Im
> Auftrag von Julian Klein
> Gesendet: Samstag, 25. Januar 2003 19:08
> An: [EMAIL PROTECTED]
> Betreff: Re: AW: Action Not Adding Values to Sitemap
> or is it?
> 
> 
> Marco,
> 
> 
> Thanks a lot, I must have overlooked that in the
> how-to on the website.  I was wondering if you know
> whether or not the new version of Xindice (1.1 Beta)
> works over the pseudo protocol.  I have tried, but
> to
> no avail.  The new version must run in Tomcat's
> servlet container.  I want to upgrade b/c Xindice
> does
> not reliably send all the documents in a given
> collection to the sitemap pipeline.  It seems to
> throw
> a DocumentCache error (I attached the stack trace in
> case you may recognize this error).  Also, I
> attached
> my final sitemap snippet b/c it was slightly
> different
> then what you sent (the sitemap parameter reference
> for the xindice url/collection had to move back one
> map).  Anyway, I really appreciate the help.
> 
> -Julian
> 
> 
>
>   
>  value="doAddSubjectsAndMyCategories"/>
>  value="Global"/>
>pattern="xpath">
> 
src="xmldb:xindice://localhost:4080/db/tasks/{../../1}#{1}"/>
>  src="stylesheets/task.xsl">
> 
>value="{../subjNodes}"/>
>value="{../categories}"/>
>   
> 
>  
>  src="xmldb:xindice://localhost:4080/db/tasks/{1}"/>
> 
> 
> 
>
> 
> 
> **Xindice 1.0 DocumentCache
> Error
> 
> 
> java.lang.NullPointerException
> at
>
org.apache.xindice.core.DocumentCache$CacheKey.equals(DocumentCache.java:171
> )
> at
> java.util.WeakHashMap.eq(WeakHashMap.java:248)
> at
> java.util.WeakHashMap.get(WeakHashMap.java:340)
> at
>
org.apache.xindice.core.DocumentCache.getDocument(DocumentCache.java:79)
> at
>
org.apache.xindice.core.Collection.getDocument(Collection.java:711)
> at
>
org.apache.xindice.core.query.XPathQueryResolver$ResultSet.prepareNextNode(X
> PathQueryResolver.java:1003)
> at
>
org.apache.xindice.core.query.XPathQueryResolver$ResultSet.getNextNode(XPath
> QueryResolver.java:1042)
> at
>
org.apache.xindice.client.corba.CollectionServant.queryWrapper(CollectionSer
> vant.java:385)
> at
>
org.apache.xindice.client.corba.CollectionServant.queryCollection(Collection
> Servant.java:425)
> at
>
org.apache.xindice.client.corba.db.CollectionPOA._invoke(CollectionPOA.java:
> 332)
> at
> org.openorb.adapter.poa.POA.dispatch(POA.java:975)
> at
>
org.openorb.net.AbstractServerRequest.dispatch(AbstractServerRequest.java:75
> 0)
> at
>
org.openorb.net.ServerManagerImpl.serve_request(ServerManagerImpl.java:1467)
> at
>
org.openorb.net.ServerManagerImpl.thread_pool_main(ServerManagerImpl.java:14
> 10)
> at
>
org.openorb.net.ServerManagerImpl.access$200(ServerManagerImpl.java:77)
> at
>
org.openorb.net.ServerManagerImpl$PoolThread.run(ServerManagerImpl.java:1557
> )
> 
> 
> =
> Live simply so others may simply live.
> 
> -Ghandi
> 
> Pluralitas non est ponenda sine neccesitate.
> "Entities should not be multiplied unneccesarily"
> 
> -William of Occam
> 
> __
> 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]>
> 
> 
>
-
> 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]>
> 


=
Live simply so others may simply live.
 
-Ghandi
 
Pluralitas non est ponenda sine neccesitate.
"Entities should not be multiplied unneccesarily"
 
-William of Occam

AW: AW: Action Not Adding Values to Sitemap or is it?

[Marco Rolappe]

hi julian,

sorry, I haven't worked with XIndice yet. but from looking at the XIndice
sources the NPE seems to be caused by the key being null. as already
mentionend, I'm not into XIndice so I don't know where that key is being
specified (created by your action, maybe?), but perhaps this info helps you
finding the problem.


-Ursprungliche Nachricht-
Von: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]Im
Auftrag von Julian Klein
Gesendet: Samstag, 25. Januar 2003 19:08
An: [EMAIL PROTECTED]
Betreff: Re: AW: Action Not Adding Values to Sitemap or is it?


Marco,


Thanks a lot, I must have overlooked that in the
how-to on the website.  I was wondering if you know
whether or not the new version of Xindice (1.1 Beta)
works over the pseudo protocol.  I have tried, but to
no avail.  The new version must run in Tomcat's
servlet container.  I want to upgrade b/c Xindice does
not reliably send all the documents in a given
collection to the sitemap pipeline.  It seems to throw
a DocumentCache error (I attached the stack trace in
case you may recognize this error).  Also, I attached
my final sitemap snippet b/c it was slightly different
then what you sent (the sitemap parameter reference
for the xindice url/collection had to move back one
map).  Anyway, I really appreciate the help.

-Julian


   

  
  
  







 




   


**Xindice 1.0 DocumentCache
Error


java.lang.NullPointerException
at
org.apache.xindice.core.DocumentCache$CacheKey.equals(DocumentCache.java:171
)
at
java.util.WeakHashMap.eq(WeakHashMap.java:248)
at
java.util.WeakHashMap.get(WeakHashMap.java:340)
at
org.apache.xindice.core.DocumentCache.getDocument(DocumentCache.java:79)
at
org.apache.xindice.core.Collection.getDocument(Collection.java:711)
at
org.apache.xindice.core.query.XPathQueryResolver$ResultSet.prepareNextNode(X
PathQueryResolver.java:1003)
at
org.apache.xindice.core.query.XPathQueryResolver$ResultSet.getNextNode(XPath
QueryResolver.java:1042)
at
org.apache.xindice.client.corba.CollectionServant.queryWrapper(CollectionSer
vant.java:385)
at
org.apache.xindice.client.corba.CollectionServant.queryCollection(Collection
Servant.java:425)
at
org.apache.xindice.client.corba.db.CollectionPOA._invoke(CollectionPOA.java:
332)
at
org.openorb.adapter.poa.POA.dispatch(POA.java:975)
at
org.openorb.net.AbstractServerRequest.dispatch(AbstractServerRequest.java:75
0)
at
org.openorb.net.ServerManagerImpl.serve_request(ServerManagerImpl.java:1467)
at
org.openorb.net.ServerManagerImpl.thread_pool_main(ServerManagerImpl.java:14
10)
at
org.openorb.net.ServerManagerImpl.access$200(ServerManagerImpl.java:77)
at
org.openorb.net.ServerManagerImpl$PoolThread.run(ServerManagerImpl.java:1557
)


=
Live simply so others may simply live.

-Ghandi

Pluralitas non est ponenda sine neccesitate.
"Entities should not be multiplied unneccesarily"

-William of Occam

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


-
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

[Julian Klein]

First off I made some suggestions to your
questions/problems below...skip ahead if you don't
want my commentary on Cocoon.

Well it seems to me that when I started with Cocoon, I
was hoping to jump right on in.  Unfortunately, it was
not that easy, but not b/c of Cocoon, rather my
limited knowledge of xpath and xsl functions.  Anyway,
I tackled these problems by studying the applications
samples packaged with cocoon and reading the
documentation.  It may be discouraging, but anything
worthwhile can't be done overnight, right?  Anyway, as
I work more and more with Cocoon, I am amazed by the
genius of it's architecture.  Cocoon is certainly a
tribute to Open Source and the greatness of those out
there working on and contributing to it.  Stick to it
and you will be repaid.




It seems if you have a servlet working, you must be
looking to upgrade.  So you should not be looking for
an overnight solution, which is easy with all the
options out there.  Overall, the advice I can give is
you must consider:

1)Are you going to use Cocoon for more than just a
replacement for your servlet?

2)What technologies do you want to use: XSP,XSLT,etc.

3)You do not need to build from the CVS source, you
can just download a pre-built version from the site
(nightly or major release)
http://xml.apache.org/dist/cocoon/

4)You may not need to create a new transformer, but
perhaps just make an action.
http://xml.apache.org/cocoon/userdocs/concepts/actions.html

5)You prob need a minimal sitemap(see below) to match
your url requests to your data.  No need to worry
about the endless options now.  The beauty is you will
learn them as you go and find that Cocoon has almost
everything you could ever need.

6)Look over the user's guide and study some of the
sitemaps packages with Cocoon.

I hope this makes some sense. If not, I 'm sorry, but
I feel as if Cocoon is a great way to go if you want
to do more than just replace your serlvlet.  With all
the users, developers, wiki, documentation, and
mailing lists...you will almost always get an answer. 
Whether or not it makes sense ;-) !  I attached a
basic sitemap to get you going...

-Julian


http://apache.org/cocoon/sitemap/1.0";>



 
  

  

  

  
   

   
1024
   
  

  

  

 



 
  
   
   
   



   
   



   
   
   
 
   

   

   

   

   

   


   

  



=
Live simply so others may simply live.
 
-Ghandi
 
Pluralitas non est ponenda sine neccesitate.
"Entities should not be multiplied unneccesarily"
 
-William of Occam

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

Sunrise getting context - problem

[Bartosz Matuszczak]

Hi
I have 2 maches in sitemap:


   

   
   


   
   
   
  

  
   
 
  

get-data.xml  contains:   to retrieve user Id from sunrise context.
When i'm logged  in and call "mach1" from browser everything goes fine and i
receive insted of   current user ID.
But when i call  "mach2" from browser  this error is caused
Cocoon 2 - Internal server error




type fatal

message Failed to execute pipeline.

description org.apache.cocoon.ProcessingException: Failed to execute
pipeline.: java.lang.IllegalArgumentException:
sunShine.streamContextFragment: Context 'sunRise' not found.

sender org.apache.cocoon.servlet.CocoonServlet

source Cocoon servlet


Why it is so ?  Why when mach2 is called from mach1 this exception throws.
This same error get I when i try to call mach 1 from browser but without
  action.
any ideas ?

Bye
Bartek




***r-e-k-l-a-m-a**

Chcesz oszczedzic na kosztach obslugi bankowej ?
mBIZNES - konto dla firm
http://epieniadze.onet.pl/mbiznes

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

[Robert Simmons]

I don't forget that. Nor do I expect everyone to adapt to "my way". Not at all. 
However I know for a fact that I am not the only new
user to cocoon having these issues. I can look at the mailing list archive a long way 
back and see people who have come, posted the
same opinions and then subsequently never posted again. You may say "fine they can go 
to hell." but if you are trying to make a
technology not just be a little niche technology with a little tight club as members 
than you need to change this turnover. People
should come into cocoon, see its power and rapidly get a hello world up and start 
running with it. Only through this can you save
the technology from the heap where all the other failed ones went.

The fact is that JSP continues to gather momentum and the era of XML-XSLT has all but 
been forgotten. To what do you attribute this?
XML and XSLT and by extension cocoon has a very narrow window to get some serious 
press to make itself live. This window is passing
by. Sitting there and saying "those damn newbies don't know anything!" might satisfy 
your sense of self but doesn't promote the
technology. Similarly, replying to a mail such as mine and saying "Don't expect 
everything to be _your_ way the moment you arrive,"
doesn't accomplish anything except getting people to say, "ok fair enough," and 
heading for the door.

In the end, cocoon has two choices. Adapt to the users or die. Its as simple as that. 
If you keep telling us to shut up for whining
about how hard it is to get started, that's fine. The technology will die.

If you ask me, the cocoon development effort should refocus itself from developing 
more features to getting the product in a state
such as tomcat is in. A state where people say "cocoon? Oh that's easy to use. getting 
hello-world to work is like a 10 minute
affair. You only need to worry about all the fancy features if you need to use them, 
give it a shot."

Right now, to the newbie, cocoon only inspires three words. Those are, "What the hell?"

As for me, I don't screw with it any more. I have a book to write and publishing 
schedules to make and the book isn't even remotely
about client side stuff and therefore anything not easy on the client side has to be 
off the shelf.

-- Robert


- Original Message -
From: "Steven Noels" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Saturday, January 25, 2003 7:03 PM
Subject: Re: Cocoon is too complex for consumption?


> Robert Simmons wrote:
>
> > Lastly, flaming is not an option. These are the opinions from a
> > newbie comming into cocoon. Readers of this list can flame all they
> > want but that is just hiding from the very real problems.
>
> Robert, I can only give you one advise: don't forget human beings are
> sitting behind these MUAs. Don't expect everything to be _your_ way the
> moment you arrive.
>
> (ditto for the Jakarta Forums idea).
>
> 
> --
> Steven Noelshttp://outerthought.org/
> Outerthought - Open Source, Java & XML Competence Support Center
> Read my weblog athttp://blogs.cocoondev.org/stevenn/
> stevenn at outerthought.orgstevenn at apache.org
>
>
> -
> Please check that your question  has not already been answered in the
> FAQ before posting. 
>
> 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: A documents repository......

[Julian Klein]

Antonio,

Although my install seems a bit buggy, it may be worth
your while to look into Slide and the slide webapp
that is in the cocoon scratchpad.  I am sure it will
be up to par shortly.  Besides, using different tools
(e.g. POI), you could convert all your files into XML
and then transform them as you please.

-Julian

--- Antonio Gallardo
<[EMAIL PROTECTED]> wrote:
> Yesterday, I was asked to find a solution for
> document repository and as a
> Open Source fan I went to sourceforge.net and found
> Owl Intranet Engine:
> http://owl.sourceforge.net/
> 
> But as a Cocoon addict I thinked it is a fine
> opportunity to test the
> directory generator and a FileWriter interface that
> currently is in
> Cocoon.
> 
> Can someone point me if this can be really easily
> done in Cocoon?
> 
> Best Regards,
> 
> Antonio Gallardo
> 
> 
> 
> 
>
-
> 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]>
> 


=
Live simply so others may simply live.
 
-Ghandi
 
Pluralitas non est ponenda sine neccesitate.
"Entities should not be multiplied unneccesarily"
 
-William of Occam

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

Re: AW: Action Not Adding Values to Sitemap or is it?

[Julian Klein]

Marco,


Thanks a lot, I must have overlooked that in the
how-to on the website.  I was wondering if you know
whether or not the new version of Xindice (1.1 Beta)
works over the pseudo protocol.  I have tried, but to
no avail.  The new version must run in Tomcat's
servlet container.  I want to upgrade b/c Xindice does
not reliably send all the documents in a given
collection to the sitemap pipeline.  It seems to throw
a DocumentCache error (I attached the stack trace in
case you may recognize this error).  Also, I attached
my final sitemap snippet b/c it was slightly different
then what you sent (the sitemap parameter reference
for the xindice url/collection had to move back one
map).  Anyway, I really appreciate the help.

-Julian


   

  
  
  







 




   


**Xindice 1.0 DocumentCache
Error


java.lang.NullPointerException
at
org.apache.xindice.core.DocumentCache$CacheKey.equals(DocumentCache.java:171)
at
java.util.WeakHashMap.eq(WeakHashMap.java:248)
at
java.util.WeakHashMap.get(WeakHashMap.java:340)
at
org.apache.xindice.core.DocumentCache.getDocument(DocumentCache.java:79)
at
org.apache.xindice.core.Collection.getDocument(Collection.java:711)
at
org.apache.xindice.core.query.XPathQueryResolver$ResultSet.prepareNextNode(XPathQueryResolver.java:1003)
at
org.apache.xindice.core.query.XPathQueryResolver$ResultSet.getNextNode(XPathQueryResolver.java:1042)
at
org.apache.xindice.client.corba.CollectionServant.queryWrapper(CollectionServant.java:385)
at
org.apache.xindice.client.corba.CollectionServant.queryCollection(CollectionServant.java:425)
at
org.apache.xindice.client.corba.db.CollectionPOA._invoke(CollectionPOA.java:332)
at
org.openorb.adapter.poa.POA.dispatch(POA.java:975)
at
org.openorb.net.AbstractServerRequest.dispatch(AbstractServerRequest.java:750)
at
org.openorb.net.ServerManagerImpl.serve_request(ServerManagerImpl.java:1467)
at
org.openorb.net.ServerManagerImpl.thread_pool_main(ServerManagerImpl.java:1410)
at
org.openorb.net.ServerManagerImpl.access$200(ServerManagerImpl.java:77)
at
org.openorb.net.ServerManagerImpl$PoolThread.run(ServerManagerImpl.java:1557)


=
Live simply so others may simply live.
 
-Ghandi
 
Pluralitas non est ponenda sine neccesitate.
"Entities should not be multiplied unneccesarily"
 
-William of Occam

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

sunRise login error rediect - doesn't work always

[ilfrin]

Hi
  
  I'm experiencing a problem concerning the sunRise login action.
  the sitemap fragment looks like this:


   





   

   
   


the problem is that this thing works on one machine and doesn't work
on some other one (it works on the development host one but wills not to
cooperate on the main server), it does log in but the problem is when
you pass a wrog password it throws a NullPointerException it doesn't
redirect.

I repeat the same code works on one machine and doesn't work on an
other one, the two machines have the same cocoon and tomcat.

Is there any idea what to search for, where is the problem and how to
get it to work ? I think this question is mainly to you Carsten :)
should I try wrapping the contents of the math with the sunRise-auth
action ??

Thanks a lot and thanks for your last hint Carsten, it worked of
course :)

-- 
 yours,
 ilfrin  mailto:[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?

[Steven Noels]

Robert Simmons wrote:


Lastly, flaming is not an option. These are the opinions from a
newbie comming into cocoon. Readers of this list can flame all they 
want but that is just hiding from the very real problems.

Robert, I can only give you one advise: don't forget human beings are 
sitting behind these MUAs. Don't expect everything to be _your_ way the 
moment you arrive.

(ditto for the Jakarta Forums idea).


--
Steven Noelshttp://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog athttp://blogs.cocoondev.org/stevenn/
stevenn at outerthought.orgstevenn at apache.org


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

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

A documents repository......

[Antonio Gallardo]

Yesterday, I was asked to find a solution for document repository and as a
Open Source fan I went to sourceforge.net and found Owl Intranet Engine:
http://owl.sourceforge.net/

But as a Cocoon addict I thinked it is a fine opportunity to test the
directory generator and a FileWriter interface that currently is in
Cocoon.

Can someone point me if this can be really easily done in Cocoon?

Best Regards,

Antonio Gallardo




-
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: WYSIWYG XSLT Editors?

[Antonio Gallardo]

Franck Lumpe dijo:
> Antonio Gallardo wrote:
>
>> Well, you can see all the OpenOffice.org products as a big WYSIWYG
>> XSLT editing.
>
> Uh?!
>
> I heard that the data format was XML but nothing more.
>
> As I am too lazy to investigate (and probably its interesting for
> others), could you please give us some hint on what OpenOffice has to do
> with XSLT.

Please check:

http://xml.openoffice.org/sx2ml/
http://xml.openoffice.org/saxecho/
http://www.xml.com/pub/a/2001/02/07/openoffice.html

Antonio Gallardo




-
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: simple question about RequestSelector

[Cyril Vidal]

Thanks to all for your help!
It's working now, with two different methods:

1°) Using a RequestParamAction:
















and by editing a default participants.xslt file, as described by Joerg.

2°) Using a RequestSelector:



































with transformer component 'xslt-with-parameters' defined as below:



true





Now, I will try to do something with i18nTransformer, so that I shouldn't
need no more two stylesheets.

If you know some accessible documentation about it, I would be very
intersted in...

Any way , Again Many Thanks, for your Help,

Best,

Cyril.

- Original Message -
From: "Joerg Heinicke" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Saturday, January 25, 2003 4:42 PM
Subject: Re: simple question about RequestSelector


> Hello Cyril,
>
> the participants.xsl can be really simple:
>
> 
>
> 
>
> 
>
> Replacing YOURDEFAULTLANGUAGE with EN or FR you can choose the default
> language of the application. And the above stylesheet is really not
> difficult to maintain.
>
> But maybe there is such a fallback operation in the input modules too?
>
> Regards,
>
> Joerg
>
> Cyril Vidal wrote:
> > Hi Christian,
> >
> > Thanks again very much for your help.
> > I've tested what you suggested me (a good idea...) and it works fine:
> >
> > But, as I read in Cocoon center's lesson about request parameter:
> > Some advantages of RequestSelector over a RequestParamAction are that
> >
> >  you can use a default stylesheet when the parameter is not
present,
> >
> >
> > and in my example, when I point the browser for the first time to
> > http://localhost:8080/cocoon/hellococoon
> >
> > of course, because I not have participants.xsl among my stylesheets but
> > juste participantsFR.xsl and particpantsEN.xsl,  Cocoon generates an
> > error...(In fact, I've added another particpants.xsl styleshhet to fix
the
> > problem, but it also requires to build another stylesheet...). Or is
there
> > another simplest solution?
> >
> >
> >>Regarding the original question, I believe the "use-request-parameters"
> >>configuration needs to go into the configuration section and not into
> >>the pipeline.
> >
> >
> > IN the same lesson, it's said apparently that we can:
> >
http://www.cocooncenter.de/cc/documents/resources/request-params/transformer
> > .html
> > I've tested it in another example and it seemed to work.
> >
> >  In addition, you would not neet the next
> >
> >>  
> >>becasue *all* parameters are available. Besides, "{critere}" is
> >>undefined at this place since the selector does not set any sitemap
> >>variables. For this you would need either the input module syntax above
> >>or an action that sets a variable.
> >>
> >
> >
> > ...I'm sorry, but I'm afraid not to understand very well what you're
trying
> > to explain to me...
> > How can I mix an action and a select?
> >
> > Thanks for your help,
> > Best,
> > 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]>
>


-
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: simple question about RequestSelector

[Christian Haul]

Joerg Heinicke wrote:

Hello Cyril,

the participants.xsl can be really simple:







Replacing YOURDEFAULTLANGUAGE with EN or FR you can choose the default 
language of the application. And the above stylesheet is really not 
difficult to maintain.

But maybe there is such a fallback operation in the input modules too?

Indeed there is. But that get a little bit more complex since one would 
need to put several of them together in cocoon.xconf. I.e. (from 2.1 
cocoon.xconf)


  
  
  
  


	Chris.

--
C h r i s t i a n   H a u l
[EMAIL PROTECTED]
fingerprint: 99B0 1D9D 7919 644A 4837  7D73 FEF9 6856 335A 9E08


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

[Robert Simmons]

Well you are wrong. I know all of those and some of them QUITE well. And still getting 
cocoon going is a major hassle. Yes, I can
deploy the distribution but I mean getting my own application going. Just a 
hello-world app.

-- robert

- Original Message -
From: "Gustavo Nalle Fernandes" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Saturday, January 25, 2003 5:56 PM
Subject: RES: Cocoon is too complex for consumption?


>Cocoon is a powerfull _framework_ used to develop XML applications and
> not an out of the box product. As a framework, Cocoon architecture must be
> well understood in order provide extensions that satisfies a particular
> need.
> IMHO, Cocoon´s leaning curve is not steep, assuming that the -DEVELOPER-
> knows XML, XSL, Namespaces, DTD, SCHEMA, HTTP,Servlets and JAVA/OOP.
>
>
>
> -Mensagem original-
> De: Robert Simmons [mailto:[EMAIL PROTECTED]]
> Enviada em: sábado, 25 de janeiro de 2003 14:13
> Para: [EMAIL PROTECTED]
> Assunto: Re: Cocoon is too complex for consumption?
>
>
> I think you might already be there. Currently the concept of cocoon is a
> great one. I create a piepline and cocoon shunts it from a
> to b, applying the transforms and so on. Great development effort. Pardon
> the language but its a shitty user effort. Just look at
> one of your paragraphs in the linked archive.
>
> 
> "If we don't do this, not only Cocoon will get bigger and bigger (and
> start appearing more as a distribution of technologies, than a
> framework), but users will find it harder and harder to modify it for
> their specific needs."
> 
>
> And that is the crux of the problem. Whoever is heading the project seems a
> bit confused. People dont want to MODIFY cocoon. They
> want to USE cocoon. They want to install cocoon's mechanics, then drop in
> their pipelines and go. Cocoon is now trying to do all
> sorts of things that dont need to be done imho. The number of features is so
> staggering that gettign started is near impossible. But
> as I get more into the product, I find myself saying, petulantly, "But I
> just wanted the pipeline!" And that is all that I wanted.
> To have a pipeline. To be able to say to cocoon, "Yeah, well ... in your
> pipeline whenever someone hits URL x, go to pipeline Z and
> run my custom class (which connects to ejbs and so on) and transform it with
> stylesheet Y and give it back to the user.
>
> "But you arent understanding how cocoon works Robert!" BINGO!! You hit it
> right there on the head. I dont want to understand how it
> works. As a user Im not interested. When reading the JBoss documentation, I
> skip over all the architecture stuff and the development
> stuff. As a user, this stuff is irrelevant to me. Object oriented
> programmign is supposed to guarantee to provide me with an
> interface and then implement some functionality. How? Who the hell cares? Im
> a user of it. My prime computing expertise is in the
> back end side of EJBs and issues that pertain to them. I want to USE cocoon,
> not develop on it.
>
> Possible solutions to this.
>
> 1) Rearchitect cocoon to implement some sort of deployment mechanism, such
> as COB. The problem here is that then you have to get
> that working with application servers and so on. The other problem is
> inertia. Gettign the masses of developers to learn a
> new-unstandardized deployment mechanism.
>
> 2) MERGE it with tomcat in the way JBoss has merged with tomcat. I download
> JBoss and they are like "well tomcat is included." I say
> "cool" and drop in my wars and go. If cocoon had a basic mechanism install
> that could be installed into tomcat than the situation
> would be aleviated. Users of the product drop their wars into tomcat as
> normal with a sitemap file in the WEB-INF directory and
> their special generators an so on in the classes directory. Cocoon magically
> wires together the pipeline. No worrying about how to
> configure cocoon or what properties to give it or so on. Thats left to
> advanced users under the heading of "customizing your
> install".
>
> At any rate I can see the learning curve for this product is steep. And
> cocoon is mainly going o suffer from people like me. People
> whoe would love to use it but dont have a month to blow trying to get a
> technology to work that is merely suppsed to be an EASY way
> to develop a polymorphic presentation layer.
>
> Lastly, flaming is not an option. These are the opinions from a newbie
> comming into cocoon. Readers of this list can flame all they
> want but that is just hiding from the very real problems.
>
> -- Robert
>
> - Original Message -
> From: "Steven Noels" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Saturday, January 25, 2003 3:43 PM
> Subject: Re: Cocoon is too complex for consumption?
>
>
> > Jeff Turner wrote:
> >
> > > http://wiki.cocoondev.org/Wiki.jsp?page=BlocksDefinition
> > > http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=101603335007960&w=2
> > > http://marc.theaimsgroup.com/?l=xml-co

RES: Cocoon is too complex for consumption?

[Gustavo Nalle Fernandes]

   Cocoon is a powerfull _framework_ used to develop XML applications and
not an out of the box product. As a framework, Cocoon architecture must be
well understood in order provide extensions that satisfies a particular
need.
IMHO, Cocoon´s leaning curve is not steep, assuming that the -DEVELOPER-
knows XML, XSL, Namespaces, DTD, SCHEMA, HTTP,Servlets and JAVA/OOP.



-Mensagem original-
De: Robert Simmons [mailto:[EMAIL PROTECTED]]
Enviada em: sábado, 25 de janeiro de 2003 14:13
Para: [EMAIL PROTECTED]
Assunto: Re: Cocoon is too complex for consumption?


I think you might already be there. Currently the concept of cocoon is a
great one. I create a piepline and cocoon shunts it from a
to b, applying the transforms and so on. Great development effort. Pardon
the language but its a shitty user effort. Just look at
one of your paragraphs in the linked archive.


"If we don't do this, not only Cocoon will get bigger and bigger (and
start appearing more as a distribution of technologies, than a
framework), but users will find it harder and harder to modify it for
their specific needs."


And that is the crux of the problem. Whoever is heading the project seems a
bit confused. People dont want to MODIFY cocoon. They
want to USE cocoon. They want to install cocoon's mechanics, then drop in
their pipelines and go. Cocoon is now trying to do all
sorts of things that dont need to be done imho. The number of features is so
staggering that gettign started is near impossible. But
as I get more into the product, I find myself saying, petulantly, "But I
just wanted the pipeline!" And that is all that I wanted.
To have a pipeline. To be able to say to cocoon, "Yeah, well ... in your
pipeline whenever someone hits URL x, go to pipeline Z and
run my custom class (which connects to ejbs and so on) and transform it with
stylesheet Y and give it back to the user.

"But you arent understanding how cocoon works Robert!" BINGO!! You hit it
right there on the head. I dont want to understand how it
works. As a user Im not interested. When reading the JBoss documentation, I
skip over all the architecture stuff and the development
stuff. As a user, this stuff is irrelevant to me. Object oriented
programmign is supposed to guarantee to provide me with an
interface and then implement some functionality. How? Who the hell cares? Im
a user of it. My prime computing expertise is in the
back end side of EJBs and issues that pertain to them. I want to USE cocoon,
not develop on it.

Possible solutions to this.

1) Rearchitect cocoon to implement some sort of deployment mechanism, such
as COB. The problem here is that then you have to get
that working with application servers and so on. The other problem is
inertia. Gettign the masses of developers to learn a
new-unstandardized deployment mechanism.

2) MERGE it with tomcat in the way JBoss has merged with tomcat. I download
JBoss and they are like "well tomcat is included." I say
"cool" and drop in my wars and go. If cocoon had a basic mechanism install
that could be installed into tomcat than the situation
would be aleviated. Users of the product drop their wars into tomcat as
normal with a sitemap file in the WEB-INF directory and
their special generators an so on in the classes directory. Cocoon magically
wires together the pipeline. No worrying about how to
configure cocoon or what properties to give it or so on. Thats left to
advanced users under the heading of "customizing your
install".

At any rate I can see the learning curve for this product is steep. And
cocoon is mainly going o suffer from people like me. People
whoe would love to use it but dont have a month to blow trying to get a
technology to work that is merely suppsed to be an EASY way
to develop a polymorphic presentation layer.

Lastly, flaming is not an option. These are the opinions from a newbie
comming into cocoon. Readers of this list can flame all they
want but that is just hiding from the very real problems.

-- Robert

- Original Message -
From: "Steven Noels" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Saturday, January 25, 2003 3:43 PM
Subject: Re: Cocoon is too complex for consumption?


> Jeff Turner wrote:
>
> > http://wiki.cocoondev.org/Wiki.jsp?page=BlocksDefinition
> > http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=101603335007960&w=2
> > http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=101732982704553&w=2
>
> oh, but that is unfair since you are a Cocoon committer and you have
> easier access to such things... not! ;-)
>
> 
> --
> Steven Noelshttp://outerthought.org/
> Outerthought - Open Source, Java & XML Competence Support Center
> Read my weblog athttp://blogs.cocoondev.org/stevenn/
> stevenn at outerthought.orgstevenn at apache.org
>
>
> -
> Please check that your question  has not already been answered in the
> FAQ before posting. 

Re: WYSIWYG XSLT Editors?

[Franck Lumpe]

Antonio Gallardo wrote:

> Well, you can see all the OpenOffice.org products as a big WYSIWYG XSLT
> editing.

Uh?!

I heard that the data format was XML but nothing more.

As I am too lazy to investigate (and probably its interesting for others),
could you please give us some hint on what OpenOffice has to do with XSLT.

Thanks in Advance

Franck Lumpe


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

[Antonio Gallardo]

Alireza Fattahi dijo:
> I think cocoon needs some thing like blank web application( if it does
> not already have, I am new to Coocon:) ). There is one in Struts.

please check:

http://wiki.cocoondev.org/Wiki.jsp?page=Tutorials

It will helps you to understand the USER philosophy behind this incredible
web machine in less than 3 hours! (Sams does not publish a similar book!
lol). And you will after that start to build your own web application.

Best Regards,

Antonio Gallardo



>
> -Original Message-
> From: Steven Noels [mailto:[EMAIL PROTECTED]]
> Sent: Saturday, January 25, 2003 6:14 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Cocoon is too complex for consumption?
>
> Jeff Turner wrote:
>
>> http://wiki.cocoondev.org/Wiki.jsp?page=BlocksDefinition
>> http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=101603335007960&w=2
>> http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=101732982704553&w=2
>
> oh, but that is unfair since you are a Cocoon committer and you have
> easier access to such things... not! ;-)
>
> 
> --
> Steven Noelshttp://outerthought.org/
> Outerthought - Open Source, Java & XML Competence Support Center
> Read my weblog athttp://blogs.cocoondev.org/stevenn/
> stevenn at outerthought.orgstevenn at apache.org
>
>
> -
> Please check that your question  has not already been answered in the
> FAQ before posting. 
>
> 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, e-mail: <[EMAIL PROTECTED]>
For additional commands, e-mail:   <[EMAIL PROTECTED]>

Re: Cocoon is too complex for consumption?

[Robert Simmons]

I think you might already be there. Currently the concept of cocoon is a great one. I 
create a piepline and cocoon shunts it from a
to b, applying the transforms and so on. Great development effort. Pardon the language 
but its a shitty user effort. Just look at
one of your paragraphs in the linked archive.


"If we don't do this, not only Cocoon will get bigger and bigger (and
start appearing more as a distribution of technologies, than a
framework), but users will find it harder and harder to modify it for
their specific needs."


And that is the crux of the problem. Whoever is heading the project seems a bit 
confused. People dont want to MODIFY cocoon. They
want to USE cocoon. They want to install cocoon's mechanics, then drop in their 
pipelines and go. Cocoon is now trying to do all
sorts of things that dont need to be done imho. The number of features is so 
staggering that gettign started is near impossible. But
as I get more into the product, I find myself saying, petulantly, "But I just wanted 
the pipeline!" And that is all that I wanted.
To have a pipeline. To be able to say to cocoon, "Yeah, well ... in your pipeline 
whenever someone hits URL x, go to pipeline Z and
run my custom class (which connects to ejbs and so on) and transform it with 
stylesheet Y and give it back to the user.

"But you arent understanding how cocoon works Robert!" BINGO!! You hit it right there 
on the head. I dont want to understand how it
works. As a user Im not interested. When reading the JBoss documentation, I skip over 
all the architecture stuff and the development
stuff. As a user, this stuff is irrelevant to me. Object oriented programmign is 
supposed to guarantee to provide me with an
interface and then implement some functionality. How? Who the hell cares? Im a user of 
it. My prime computing expertise is in the
back end side of EJBs and issues that pertain to them. I want to USE cocoon, not 
develop on it.

Possible solutions to this.

1) Rearchitect cocoon to implement some sort of deployment mechanism, such as COB. The 
problem here is that then you have to get
that working with application servers and so on. The other problem is inertia. Gettign 
the masses of developers to learn a
new-unstandardized deployment mechanism.

2) MERGE it with tomcat in the way JBoss has merged with tomcat. I download JBoss and 
they are like "well tomcat is included." I say
"cool" and drop in my wars and go. If cocoon had a basic mechanism install that could 
be installed into tomcat than the situation
would be aleviated. Users of the product drop their wars into tomcat as normal with a 
sitemap file in the WEB-INF directory and
their special generators an so on in the classes directory. Cocoon magically wires 
together the pipeline. No worrying about how to
configure cocoon or what properties to give it or so on. Thats left to advanced users 
under the heading of "customizing your
install".

At any rate I can see the learning curve for this product is steep. And cocoon is 
mainly going o suffer from people like me. People
whoe would love to use it but dont have a month to blow trying to get a technology to 
work that is merely suppsed to be an EASY way
to develop a polymorphic presentation layer.

Lastly, flaming is not an option. These are the opinions from a newbie comming into 
cocoon. Readers of this list can flame all they
want but that is just hiding from the very real problems.

-- Robert

- Original Message -
From: "Steven Noels" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Saturday, January 25, 2003 3:43 PM
Subject: Re: Cocoon is too complex for consumption?


> Jeff Turner wrote:
>
> > http://wiki.cocoondev.org/Wiki.jsp?page=BlocksDefinition
> > http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=101603335007960&w=2
> > http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=101732982704553&w=2
>
> oh, but that is unfair since you are a Cocoon committer and you have
> easier access to such things... not! ;-)
>
> 
> --
> Steven Noelshttp://outerthought.org/
> Outerthought - Open Source, Java & XML Competence Support Center
> Read my weblog athttp://blogs.cocoondev.org/stevenn/
> stevenn at outerthought.orgstevenn at apache.org
>
>
> -
> Please check that your question  has not already been answered in the
> FAQ before posting. 
>
> 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: simple question about RequestSelector

[Joerg Heinicke]

Hello Cyril,

the participants.xsl can be really simple:







Replacing YOURDEFAULTLANGUAGE with EN or FR you can choose the default 
language of the application. And the above stylesheet is really not 
difficult to maintain.

But maybe there is such a fallback operation in the input modules too?

Regards,

Joerg

Cyril Vidal wrote:
Hi Christian,

Thanks again very much for your help.
I've tested what you suggested me (a good idea...) and it works fine:

But, as I read in Cocoon center's lesson about request parameter:
Some advantages of RequestSelector over a RequestParamAction are that

 you can use a default stylesheet when the parameter is not present,


and in my example, when I point the browser for the first time to
http://localhost:8080/cocoon/hellococoon

of course, because I not have participants.xsl among my stylesheets but
juste participantsFR.xsl and particpantsEN.xsl,  Cocoon generates an
error...(In fact, I've added another particpants.xsl styleshhet to fix the
problem, but it also requires to build another stylesheet...). Or is there
another simplest solution?



Regarding the original question, I believe the "use-request-parameters"
configuration needs to go into the configuration section and not into
the pipeline.



IN the same lesson, it's said apparently that we can:
http://www.cocooncenter.de/cc/documents/resources/request-params/transformer
.html
I've tested it in another example and it seemed to work.

 In addition, you would not neet the next


 
becasue *all* parameters are available. Besides, "{critere}" is
undefined at this place since the selector does not set any sitemap
variables. For this you would need either the input module syntax above
or an action that sets a variable.




...I'm sorry, but I'm afraid not to understand very well what you're trying
to explain to me...
How can I mix an action and a select?

Thanks for your help,
Best,
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]>

Re: Cocoon versus taglibs

[Jordi Valldaura]

> On Sat, Jan 25, 2003 at 01:26:09PM +0100, Jordi Valldaura wrote:
> > Hello,
> >
> > Im developing a litle intranet
>
> (plug.. http://xml.apache.org/forrest/ :)
>
> >, I want to use XML and i18n so I need XSLT transformation and
> >internacionalization support. I was planning to use cocoon, but
> > Jeff Turner said  there were other ways to do this for example tablibs.
> >
> > My question is: are the tablibs (XTags & i18n) faster than cocoon with a
> > simple sitemap transforming XSPs to HTML 
>
> I think you'll have to test it for yourself.  Being straight SAX, Cocoon
> should be faster, but real life often throws surprises, and theorising on
> performance issues is pointless.
>
> One thing to note though: if your XML rarely changes, Cocoon's caching
> should help significantly.  There are caching taglibs around if you
> choose the JSP route, but they won't be nearly as sophisticated as
> Cocoon.

 Everything will be dynamic, I acces a database through an EJB layer. The
intranet is a kind of web file system thats why performance its important.



>
> --Jeff
>
> > The intranet will have an average of 200 concurrent users.
> >
> > Thanks in advance
>
> -
> 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?

[Alireza Fattahi]

I think cocoon needs some thing like blank web application( if it does not
already have, I am new to Coocon:) ). There is one in Struts. 

-Original Message-
From: Steven Noels [mailto:[EMAIL PROTECTED]] 
Sent: Saturday, January 25, 2003 6:14 PM
To: [EMAIL PROTECTED]
Subject: Re: Cocoon is too complex for consumption?

Jeff Turner wrote:

> http://wiki.cocoondev.org/Wiki.jsp?page=BlocksDefinition
> http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=101603335007960&w=2
> http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=101732982704553&w=2

oh, but that is unfair since you are a Cocoon committer and you have 
easier access to such things... not! ;-)


-- 
Steven Noelshttp://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog athttp://blogs.cocoondev.org/stevenn/
stevenn at outerthought.orgstevenn at apache.org


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

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?

[Steven Noels]

Jeff Turner wrote:


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


oh, but that is unfair since you are a Cocoon committer and you have 
easier access to such things... not! ;-)


--
Steven Noelshttp://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog athttp://blogs.cocoondev.org/stevenn/
stevenn at outerthought.orgstevenn at apache.org


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

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

Re: simple question about RequestSelector

[Cyril Vidal]

Hi Christian,

Thanks again very much for your help.
I've tested what you suggested me (a good idea...) and it works fine:

But, as I read in Cocoon center's lesson about request parameter:
Some advantages of RequestSelector over a RequestParamAction are that

 you can use a default stylesheet when the parameter is not present,


and in my example, when I point the browser for the first time to
http://localhost:8080/cocoon/hellococoon

of course, because I not have participants.xsl among my stylesheets but
juste participantsFR.xsl and particpantsEN.xsl,  Cocoon generates an
error...(In fact, I've added another particpants.xsl styleshhet to fix the
problem, but it also requires to build another stylesheet...). Or is there
another simplest solution?

> Regarding the original question, I believe the "use-request-parameters"
> configuration needs to go into the configuration section and not into
> the pipeline.

IN the same lesson, it's said apparently that we can:
http://www.cocooncenter.de/cc/documents/resources/request-params/transformer
.html
I've tested it in another example and it seemed to work.

 In addition, you would not neet the next
>   
> becasue *all* parameters are available. Besides, "{critere}" is
> undefined at this place since the selector does not set any sitemap
> variables. For this you would need either the input module syntax above
> or an action that sets a variable.
>

...I'm sorry, but I'm afraid not to understand very well what you're trying
to explain to me...
How can I mix an action and a select?

Thanks for your help,
Best,
Cyril.

<>

RE: Cocoon is too complex for consumption?

[Geoff Howard]

I think a practical and attainable suggestion that could come out of this
would be to provide a minimal binary distribution along with the "everything
but the kitchen sink" model.  The suggestion for new people would be to
download both, play with the kitchen sink, and then start developing their
app on the stripped down version.

Adding in the few things you need that aren't standard (with a full version
to refer to for examples) is probably going to be easier for new users than
digging through to determine what is not needed.  And obviously some people
don't want to have to build from source, which I understand.  I don't build
apache or tomcat from source unless I have to for some reason, and then I
expect some complexity.

> -Original Message-
> From: Jeff Turner [mailto:[EMAIL PROTECTED]]
> Sent: Saturday, January 25, 2003 8:06 AM
> To: [EMAIL PROTECTED]
> Subject: Re: Cocoon is too complex for consumption?
>
>
> > > So how could cocoon be of use to me and others like me? If I
> could build a
> > > war with simply any special classes I have (generators, etc)
> my XSL pages
> > > and a sitemap. Then I deploy that war and cocoon figures out
> how to wire
> > > things together.
> >



> > In general I agree that Cocoon is too "feature-oriented" and not at all
> > "user-oriented".
> > If you know the product as the back of your hand, yes, you
> think everything is
> > dirt easy, but it is overwhelming to get started. (The good
> news is that it
> > is 10x better now than in the "old days", when you needed ~10
> additional
> > downloads and installations.)
> >
> > 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
>

Of course blocks when finished should (and already do if you're willing to
work from source dist) go a long way to helping identify and exclude
unneeded pieces.

Geoff


-
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: simple question about RequestSelector

[Marco Rolappe]

hi cyril,

the problem is the '{critere}'. you have no sitemap component creating this
sitemap variable. but in this case you don't need that anyway since you are
instructing the XSLT-/TraxTransformer to 'use-request-parameters', i.e. make
all request parameters available to the stylesheet as stylesheet params. to
be able to access 'critere' within the stylesheet then, declare it at the
head of your stylesheet (). should you need the
parameter to be named 'tri', the simple solution would be a .

HTH

-Ursprüngliche Nachricht-
Von: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]Im
Auftrag von Cyril Vidal
Gesendet: Samstag, 25. Januar 2003 13:52
An: [EMAIL PROTECTED]
Betreff: simple question about RequestSelector


Dear all,

I would like to process an URI of the following type:
http://localhost:8080/cocoon/hellococoon?langue=anglais&critere=organisme

The first parameter's role is to select a specified stylesheet:
langue=anglais -> select participantsEN.xslt
langue=francais -> select participantsFR.xslt

while parameter 'critere' is used to pass a parameter to the selectionned
stylesheet.

If I only take care about the parameter 'langue', the following code's
snippet using RequestSelector works fine:





































But When I want to deal with the second parameter too, (by adding the
following instructions):









 I have some problems, indeed I receive no error messag but nothing is
happening.

I use the the following code:
























...





I'm sure the XSLT works well , so I guess the sitemap' syntax ins't good.

Can someone help me, please?

Thannks in advance,

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


-
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: simple question about RequestSelector

[Christian Haul]

Cyril Vidal wrote:

Dear all,

I would like to process an URI of the following type:
http://localhost:8080/cocoon/hellococoon?langue=anglais&critere=organisme

The first parameter's role is to select a specified stylesheet:
langue=anglais -> select participantsEN.xslt
langue=francais -> select participantsFR.xslt

while parameter 'critere' is used to pass a parameter to the selectionned
stylesheet.


While this is no answer to your question, it might still be helpful.
Say you are using at least 2.0.4 and are able to either rename your xsl 
or the parameter value so that they match. Then you could do

  


   


  

The so called input modules are available like any other variable from 
the sitemap.

Regarding the original question, I believe the "use-request-parameters" 
configuration needs to go into the configuration section and not into 
the pipeline. In addition, you would not neet the next
 
becasue *all* parameters are available. Besides, "{critere}" is 
undefined at this place since the selector does not set any sitemap 
variables. For this you would need either the input module syntax above 
or an action that sets a variable.

	Chris.

--
C h r i s t i a n   H a u l
[EMAIL PROTECTED]
fingerprint: 99B0 1D9D 7919 644A 4837  7D73 FEF9 6856 335A 9E08


-
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: Action Not Adding Values to Sitemap or is it?

[Marco Rolappe]

AFAIR your sitemap variable is only accessible within your map:act block,
something like this:


   

  
  

 








 





   


-Ursprungliche Nachricht-
Von: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]Im
Auftrag von Julian Klein
Gesendet: Samstag, 25. Januar 2003 00:21
An: Cocoon Users
Betreff: Action Not Adding Values to Sitemap or is it?


Hi All,

I am trying to add a paramater to the sitemap through
an Action extended from the MultiAction Class, but
when I try to access it in my sitemap, it is empty.  I
am certain there should be a value coming out of the
Action b/c it prints the value to my log from inside
the action.  Any help would be greatly appreciated.  I
attached my Action code and sitemap code snippets.  I
am running Cocoon 2.1 dev and java 1.4 on Red Hat 8.0.
 The reason for the action is to get collection names
from the Xindice database, which translate to client's
of the webapp.

Thanks,
Julian


   

  
  

 







 



   

*

  /*Places all the user's into a sitemap parameter.*/
public Map doAddSubjNodes (Redirector redirector,
   SourceResolver resolver,
   Map objectModel,
   String src,
   Parameters parameters) throws
Exception {


Request request =
ObjectModelHelper.getRequest(objectModel);
Map sitemapParams = new HashMap();

//determine dest of task to be created
String subjectNode =
parameters.getParameter("task-subject-node",

request.getParameter("task-subject-node"));

TaskManager taskManager = new TaskManager();

//get all available subjectNode's
String[] subjNodes =
taskManager.getSubjectNodes();
String subjStr = "";
//add all user's to sitemap
for(int x=0;x

=
Live simply so others may simply live.

-Ghandi

Pluralitas non est ponenda sine neccesitate.
"Entities should not be multiplied unneccesarily"

-William of Occam

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


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

[Jeff Turner]

On Sat, Jan 25, 2003 at 06:22:10PM +0800, Niclas Hedhman wrote:
> On Saturday 25 January 2003 14:17, Robert Simmons wrote:
> > That is the impression that I am getting and I'm curious as to feedback
> > from list users.
> 
> I bet you will ;o)
> 
> > So how could cocoon be of use to me and others like me? If I could build a
> > war with simply any special classes I have (generators, etc) my XSL pages
> > and a sitemap. Then I deploy that war and cocoon figures out how to wire
> > things together.
> 
> In general I agree that Cocoon is too "feature-oriented" and not at all 
> "user-oriented".
> If you know the product as the back of your hand, yes, you think everything is 
> dirt easy, but it is overwhelming to get started. (The good news is that it 
> is 10x better now than in the "old days", when you needed ~10 additional 
> downloads and installations.)
> 
> 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



--Jeff

> Well, well... 
> 
> 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]>

simple question about RequestSelector

[Cyril Vidal]

Dear all,

I would like to process an URI of the following type:
http://localhost:8080/cocoon/hellococoon?langue=anglais&critere=organisme

The first parameter's role is to select a specified stylesheet:
langue=anglais -> select participantsEN.xslt
langue=francais -> select participantsFR.xslt

while parameter 'critere' is used to pass a parameter to the selectionned
stylesheet.

If I only take care about the parameter 'langue', the following code's
snippet using RequestSelector works fine:





































But When I want to deal with the second parameter too, (by adding the
following instructions):









 I have some problems, indeed I receive no error messag but nothing is
happening.

I use the the following code:
























...





I'm sure the XSLT works well , so I guess the sitemap' syntax ins't good.

Can someone help me, please?

Thannks in advance,

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

RE: Cocoon is too complex for consumption?

[Jeremy Aston]

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

Re: Cocoon versus taglibs

[Jeff Turner]

On Sat, Jan 25, 2003 at 01:26:09PM +0100, Jordi Valldaura wrote:
> Hello,
> 
> Im developing a litle intranet

(plug.. http://xml.apache.org/forrest/ :)

>, I want to use XML and i18n so I need XSLT transformation and
>internacionalization support. I was planning to use cocoon, but
> Jeff Turner said  there were other ways to do this for example tablibs.
> 
> My question is: are the tablibs (XTags & i18n) faster than cocoon with a
> simple sitemap transforming XSPs to HTML 

I think you'll have to test it for yourself.  Being straight SAX, Cocoon
should be faster, but real life often throws surprises, and theorising on
performance issues is pointless.

One thing to note though: if your XML rarely changes, Cocoon's caching
should help significantly.  There are caching taglibs around if you
choose the JSP route, but they won't be nearly as sophisticated as
Cocoon.

--Jeff

> The intranet will have an average of 200 concurrent users.
> 
> Thanks in advance

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

Cocoon versus taglibs

[Jordi Valldaura]

Hello,

Im developing a litle intranet, I want to use XML and i18n so I need XSLT
transformation and internacionalization support. I was planning to use
cocoon, but
Jeff Turner said  there were other ways to do this for example tablibs.

My question is: are the tablibs (XTags & i18n) faster than cocoon with a
simple sitemap transforming XSPs to HTML 

The intranet will have an average of 200 concurrent users.

Thanks in advance


-
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 14:17, Robert Simmons wrote:
> That is the impression that I am getting and I'm curious as to feedback
> from list users.

I bet you will ;o)

> So how could cocoon be of use to me and others like me? If I could build a
> war with simply any special classes I have (generators, etc) my XSL pages
> and a sitemap. Then I deploy that war and cocoon figures out how to wire
> things together.

In general I agree that Cocoon is too "feature-oriented" and not at all 
"user-oriented".
If you know the product as the back of your hand, yes, you think everything is 
dirt easy, but it is overwhelming to get started. (The good news is that it 
is 10x better now than in the "old days", when you needed ~10 additional 
downloads and installations.)

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.

Well, well... 

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

Re: Cocoon is too complex for consumption?

[Steven Noels]

Robert Simmons wrote:


Users tell me to go to wiki (which is down allot or just really slow) to 
find information but its like hunting for an needle in a haystack.

This is worrying me. Is that the case? Has anyone experienced 
performance issues with http://wiki.cocoondev.org/ ?



I guess I'm rambling a bit and I'm sorry. Its just frustrating to spend 
several hours on something and essentially get nowhere. Cocoon may be a 
powerful product, but it will never go mainstream in the web, imho, with 
its level of difficulty in understanding it.

... it seems like you are very opinionated, and should thus be a good 
contributor to the Cocoon Documentation effort.


--
Steven Noelshttp://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog athttp://blogs.cocoondev.org/stevenn/
stevenn at outerthought.orgstevenn at apache.org


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

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