Cocoon Warnings when starting in JBoss 3.0
I deployed cocoon by basically dropping it in my jboss deployment directory. When i started the appserver, I got the following traces in the console. The ones that I am wondering about are the (Unknown-URI) Unknown-thread messages. Anyone know what's up ? -- Robert Begin relevant logged messages: 00:37:48,936 INFO [MainDeployer] Starting deployment of package: file:/C:/j2sdk/addons/jboss/server/default/deploy/cocoon.war00:37:52,942 INFO [EmbeddedCatalinaService41] deploy, ctxPath=/cocoon, warUrl=file:/C:/j2sdk/addons/jboss/server/default/tmp/deploy/server/default/deploy/cocoon.war/94.cocoon.war00:37:53,874 INFO [Engine] WebappLoader[/cocoon]: Deploying class repositories to work directory C:\j2sdk\addons\jboss\tomcat-4.1.x\work\MainEngine\localhost\cocoon00:37:53,884 INFO [Engine] WebappLoader[/cocoon]: Deploy class files /WEB-INF/classes to C:\j2sdk\addons\jboss\tomcat-4.1.x\work\MainEngine\localhost\cocoon\WEB-INF\classes00:37:53,894 INFO [Engine] WebappLoader[/cocoon]: Deploy JAR /WEB-INF/lib/avalon-framework-20020627.jar to C:\j2sdk\addons\jboss\tomcat-4.1.x\work\MainEngine\localhost\cocoon\WEB-INF\lib\avalon-framework-20020627.jar00:37:53,914 INFO [Engine] WebappLoader[/cocoon]: Deploy JAR /WEB-INF/lib/batik-all-1.5b2.jar to C:\j2sdk\addons\jboss\tomcat-4.1.x\work\MainEngine\localhost\cocoon\WEB-INF\lib\batik-all-1.5b2.jar00:37:54,104 INFO [Engine] WebappLoader[/cocoon]: Deploy JAR /WEB-INF/lib/bsf-2.2.jar to C:\j2sdk\addons\jboss\tomcat-4.1.x\work\MainEngine\localhost\cocoon\WEB-INF\lib\bsf-2.2.jar00:37:54,114 INFO [Engine] WebappLoader[/cocoon]: Deploy JAR /WEB-INF/lib/castor-0.9.3.9-xml.jar to C:\j2sdk\addons\jboss\tomcat-4.1.x\work\MainEngine\localhost\cocoon\WEB-INF\lib\castor-0.9.3.9-xml.jar00:37:54,194 INFO [Engine] WebappLoader[/cocoon]: Deploy JAR /WEB-INF/lib/cocoon-2.0.4.jar to C:\j2sdk\addons\jboss\tomcat-4.1.x\work\MainEngine\localhost\cocoon\WEB-INF\lib\cocoon-2.0.4.jar00:37:54,344 INFO [Engine] WebappLoader[/cocoon]: Deploy JAR /WEB-INF/lib/cocoon-scratchpad.jar to C:\j2sdk\addons\jboss\tomcat-4.1.x\work\MainEngine\localhost\cocoon\WEB-INF\lib\cocoon-scratchpad.jar00:37:54,384 INFO [Engine] WebappLoader[/cocoon]: Deploy JAR /WEB-INF/lib/commons-collections-2.1.jar to C:\j2sdk\addons\jboss\tomcat-4.1.x\work\MainEngine\localhost\cocoon\WEB-INF\lib\commons-collections-2.1.jar00:37:54,404 INFO [Engine] WebappLoader[/cocoon]: Deploy JAR /WEB-INF/lib/commons-httpclient-20020423.jar to C:\j2sdk\addons\jboss\tomcat-4.1.x\work\MainEngine\localhost\cocoon\WEB-INF\lib\commons-httpclient-20020423.jar00:37:54,414 INFO [Engine] WebappLoader[/cocoon]: Deploy JAR /WEB-INF/lib/commons-jxpath-1.0.jar to C:\j2sdk\addons\jboss\tomcat-4.1.x\work\MainEngine\localhost\cocoon\WEB-INF\lib\commons-jxpath-1.0.jar00:37:54,444 INFO [Engine] WebappLoader[/cocoon]: Deploy JAR /WEB-INF/lib/commons-logging-1.0.jar to C:\j2sdk\addons\jboss\tomcat-4.1.x\work\MainEngine\localhost\cocoon\WEB-INF\lib\commons-logging-1.0.jar00:37:54,454 INFO [Engine] WebappLoader[/cocoon]: Deploy JAR /WEB-INF/lib/deli-0.50.jar to C:\j2sdk\addons\jboss\tomcat-4.1.x\work\MainEngine\localhost\cocoon\WEB-INF\lib\deli-0.50.jar00:37:54,464 INFO [Engine] WebappLoader[/cocoon]: Deploy JAR /WEB-INF/lib/excalibur-altrmi-common-20020916.jar to C:\j2sdk\addons\jboss\tomcat-4.1.x\work\MainEngine\localhost\cocoon\WEB-INF\lib\excalibur-altrmi-common-20020916.jar00:37:54,474 INFO [Engine] WebappLoader[/cocoon]: Deploy JAR /WEB-INF/lib/excalibur-altrmi-server-impl-20020916.jar to C:\j2sdk\addons\jboss\tomcat-4.1.x\work\MainEngine\localhost\cocoon\WEB-INF\lib\excalibur-altrmi-server-impl-20020916.jar00:37:54,484 INFO [Engine] WebappLoader[/cocoon]: Deploy JAR /WEB-INF/lib/excalibur-altrmi-server-interfaces-20020916.jar to C:\j2sdk\addons\jboss\tomcat-4.1.x\work\MainEngine\localhost\cocoon\WEB-INF\lib\excalibur-altrmi-server-interfaces-20020916.jar00:37:54,494 INFO [Engine] WebappLoader[/cocoon]: Deploy JAR /WEB-INF/lib/excalibur-cli-1.0.jar to C:\j2sdk\addons\jboss\tomcat-4.1.x\work\MainEngine\localhost\cocoon\WEB-INF\lib\excalibur-cli-1.0.jar00:37:54,494 INFO [Engine] WebappLoader[/cocoon]: Deploy JAR /WEB-INF/lib/excalibur-collections-20020820.jar to C:\j2sdk\addons\jboss\tomcat-4.1.x\work\MainEngine\localhost\cocoon\WEB-INF\lib\excalibur-collections-20020820.jar00:37:54,504 INFO [Engine] WebappLoader[/cocoon]: Deploy JAR /WEB-INF/lib/excalibur-component-20020916.jar to C:\j2sdk\addons\jboss\tomcat-4.1.x\work\MainEngine\localhost\cocoon\WEB-INF\lib\excalibur-component-20020916.jar00:37:54,514 INFO [Engine] WebappLoader[/cocoon]: Deploy JAR /WEB-INF/lib/excalibur-concurrent-20020820.jar to C:\j2sdk\addons\jboss\tomcat-4.1.x\work\MainEngine\localhost\cocoon\WEB-INF\lib\excalibur-concurrent-20020820.jar00:37:54,524 INFO [Engine] WebappLoader[/cocoon]: Deploy JAR /WEB-INF/lib/excalibur-datasource-vm14-20021121.jar to
Cocoon Warnings when starting in JBoss 3.0
I deployed cocoon by basically dropping it in my jboss deployment directory. When i started the appserver, I got the following traces in the console. The ones that I am wondering about are the (Unknown-URI) Unknown-thread messages. Anyone know what's up ? -- Robert Begin relevant logged messages: 00:37:55,826 INFO [Engine] WebappLoader[/cocoon]: Deploy JAR /WEB-INF/lib/xt-19991105.jar to C:\j2sdk\addons\jboss\tomcat-4.1.x\work\MainEngine\localhost\cocoon\WEB-INF\lib\xt-19991105.jar00:37:58,430 INFO [Engine] ContextConfig[/cocoon]: Added certificates - request attribute Valve00:38:08,214 INFO [EmbeddedCatalinaService41] Using Java2 parent classloader delegation: true00:38:08,224 INFO [Engine] StandardManager[/cocoon]: Seeding random number generator class java.security.SecureRandom00:38:08,224 INFO [Engine] StandardManager[/cocoon]: Seeding of random number generator has been completed00:38:08,715 INFO [Engine] WARN (2003-01-23) 00:38.08:715 [ ] (Unknown-URI) Unknown-thread/CocoonServlet: Setting servlet-context for LogKit to C:\j2sdk\addons\jboss\tomcat-4.1.x\work\MainEngine\localhost\cocoon\cocoon-files\log 00:38:08,855 INFO [Engine] DEBUG (2003-01-23) 00:38.08:855 [ ] (Unknown-URI) Unknown-thread/DefaultLogTargetFactoryManager: added new LogTargetFactory of type priority-filter 00:38:08,865 INFO [Engine] DEBUG (2003-01-23) 00:38.08:865 [ ] (Unknown-URI) Unknown-thread/DefaultLogTargetFactoryManager: added new LogTargetFactory of type servlet 00:38:08,925 INFO [Engine] DEBUG (2003-01-23) 00:38.08:925 [ ] (Unknown-URI) Unknown-thread/DefaultLogTargetFactoryManager: added new LogTargetFactory of type cocoon 00:38:08,965 INFO [Engine] DEBUG (2003-01-23) 00:38.08:965 [ ] (Unknown-URI) Unknown-thread/DefaultLogTargetManager: added new LogTarget of id core 00:38:08,965 INFO [Engine] DEBUG (2003-01-23) 00:38.08:965 [ ] (Unknown-URI) Unknown-thread/DefaultLogTargetManager: added new LogTarget of id sitemap 00:38:08,975 INFO [Engine] DEBUG (2003-01-23) 00:38.08:975 [ ] (Unknown-URI) Unknown-thread/DefaultLogTargetManager: added new LogTarget of id access 00:38:08,975 INFO [Engine] DEBUG (2003-01-23) 00:38.08:975 [ ] (Unknown-URI) Unknown-thread/PriorityFilterTargetFactory: loglevel is ERROR 00:38:09,005 INFO [Engine] DEBUG (2003-01-23) 00:38.08:995 [ ] (Unknown-URI) Unknown-thread/PriorityFilterTargetFactory: creating target cocoon: org.apache.avalon.framework.configuration.DefaultConfiguration@1cefde4 00:38:09,005 INFO [Engine] DEBUG (2003-01-23) 00:38.09:005 [ ] (Unknown-URI) Unknown-thread/DefaultLogTargetManager: added new LogTarget of id error 00:38:09,005 INFO [Engine] DEBUG (2003-01-23) 00:38.09:005 [ ] (Unknown-URI) Unknown-thread/DefaultLogKitManager: added logger for category core 00:38:09,005 INFO [Engine] DEBUG (2003-01-23) 00:38.09:005 [ ] (Unknown-URI) Unknown-thread/DefaultLogKitManager: added logger for category core.startup 00:38:09,015 INFO [Engine] DEBUG (2003-01-23) 00:38.09:015 [ ] (Unknown-URI) Unknown-thread/DefaultLogKitManager: added logger for category core.roles 00:38:09,015 INFO [Engine] DEBUG (2003-01-23) 00:38.09:015 [ ] (Unknown-URI) Unknown-thread/DefaultLogKitManager: added logger for category core.manager 00:38:09,015 INFO [Engine] DEBUG (2003-01-23) 00:38.09:015 [ ] (Unknown-URI) Unknown-thread/DefaultLogKitManager: added logger for category core.store 00:38:09,015 INFO [Engine] DEBUG (2003-01-23) 00:38.09:015 [ ] (Unknown-URI) Unknown-thread/DefaultLogKitManager: added logger for category sitemap 00:38:09,015 INFO [Engine] DEBUG (2003-01-23) 00:38.09:015 [ ] (Unknown-URI) Unknown-thread/DefaultLogKitManager: added logger for category access 00:38:09,025 INFO [Engine] DEBUG (2003-01-23) 00:38.09:025 [ ] (Unknown-URI) Unknown-thread/DefaultLogKitManager: Logger for category access returned 00:38:10,918 INFO [Engine] DEBUG (2003-01-23) 00:38.10:918 [ ] (Unknown-URI) Unknown-thread/DefaultLogKitManager: Logger for category core returned 00:38:12,400 INFO [Engine] DEBUG (2003-01-23) 00:38.12:400 [ ] (Unknown-URI) Unknown-thread/DefaultLogKitManager: Logger for category core.hsqldb-server not defined in configuration. New Logger created and returned 00:38:12,430 INFO [Engine] DEBUG (2003-01-23) 00:38.12:430 [ ] (Unknown-URI) Unknown-thread/DefaultLogKitManager: Logger for category core.store.persistent not defined in configuration. New Logger created and returned 00:38:12,440 INFO [Engine] DEBUG (2003-01-23) 00:38.12:440 [ ] (Unknown-URI) Unknown-thread/DefaultLogKitManager: Logger for category core.store.transient not defined in configuration. New Logger created and returned 00:38:12,450 INFO [Engine] DEBUG (2003-01-23) 00:38.12:450 [ ] (Unknown-URI) Unknown-thread/DefaultLogKitManager: Logger for category core.store.janitor not defined in configuration. New Logger created and returned 00:38:12,460 INFO [Engine] DEBUG (2003-01-23) 00:38.12:460 [ ]
Question on Usability of Cocoon in a Distributed application.
Greetings. I currently have a distributed application that uses Session beans for most of its work. I am a cocoon user in that the session bean returns XML and then cocoon magically transforms it using XSL into the html that I want. In order to accomplish this, I have a servlet running that creates a DOM document, adds stuff to it, and spits it back out. So the user connects to the servlet, the action that they did is run on the session beans, then the data is returned from the session beans, including an xsl:stylesheet processing instruction, the data is transformed and the user gets a view. What I'm wondering is if I could cut out the middleman and drop the servlet altogether. The problem I currently have is that the servlet is occasionally serving requests that return pages that are no more than placeholders. For example, if I have a point where the user needs to "add and entry" than the servlet returns an empty tagged XML document which cocoon transforms into the form. The form is submitted and then the servlet actually does some work, contacting the EJB and validating the changes and so on. If I could have an alternative strategy, such as having XML documents for everything than things would go along much more swimmingly. Ideally, the form would be generated and the user hits "submit" to add his new entry. Then the submit hits another XML page which somehow contacts the EJB server, negotiates with the session bean and gets data back. Then it spits out the XML which is again transformed via XSL. I am wondering if this is possible. Comments ? (Note: The beans are running on JBoss 3.0.4 currently as is cocoon and tomcat. Moving the logic of the application out of the session beans is just not an option. They do all the hard work and there is quite a bit of it. I'm looking to use cocoon for the entire PRESENTATION and client negotiating layer only.) -- Robert
WYSIWYG XSLT Editors?
Greetings, I have downloaded theevaluation version of eXcelon Stylus Studio and am enjoying it. What I wanted to know was who are their competitors for WYSIWYG XSLT editing and other XML editing. I would like to see as many products as I can before I decide on a purchase. -- Robert
The simplest possible cocoon application?
I currently have the cocoon war installed on my JBoss 3.0.4 server. It works fine. I deployed a second war file that contains an XML and an XSL. The XML has an embedded xsl:stylesheet processing instruction. When I go to the URL inside the war and hit the XML page, the translation is made fine. Ok so here is the question. I am now thinking of doing something a bit more than static XML pages. What would be the bare minimum? Do I have to copy the cocoon war and all the libs in it to another deployment or can I use the jars already deployed in the war? Do sitemaps work outside of the cocoon war? How can I set up a simple application, prior to considering generators, outside of the cocoon deployment? Note. The lack of truly newbie cocoon documentation is appalling. -- Robert
Re: The simplest possible cocoon application?
- Original Message - From: Jeff Turner [EMAIL PROTECTED] To: Cocoon Users [EMAIL PROTECTED] Sent: Saturday, January 25, 2003 6:02 AM Subject: Re: The simplest possible cocoon application? On Sat, Jan 25, 2003 at 05:21:13AM +0100, Robert Simmons wrote: I currently have the cocoon war installed on my JBoss 3.0.4 server. It works fine. I deployed a second war file that contains an XML and an XSL. The XML has an embedded xsl:stylesheet processing instruction. Embedded stylesheets are very unusual.. are you sure it's Cocoon applying the embedded stylesheet, or the web browser? Hmm, how could I tell? What would you use if you didnt embedd the stylesheet into the XML? Oh, I get it, the pipeline tells it what transform to make ? Addendum: I undeployed cocoon from jboss and the transform still worked. Must be the browser doing it. OOK .. =) Now I feel like i actually know LESS than before. When I go to the URL inside the war and hit the XML page, the translation is made fine. Ok so here is the question. I am now thinking of doing something a bit more than static XML pages. What would be the bare minimum? Do I have to copy the cocoon war and all the libs in it to another deployment or can I use the jars already deployed in the war? Each war has one main sitemap. Each sitemap can have lots of different pipelines. Where did the 'second war file' you mention come from? Did you copy the sitemap and WEB-INF/cocoon.xconf from the Cocoon samples war? What I mean is that, if possible, I dont want to copy the whole MASSIVE jar library in the cocoon distribution war into every blasted web app that I create. The thing thats stumping the newbie here is how a user uses it. It almost seems like i have to be practically a dveloper on cocoon to use it. I honestly dont care how it works, I just ultimately want to write come generators that smack a EJB and spit out XML that then gets transformed. Basically what i have right now is a normal java servlet that builds a dom document, serializes it to xml and trusts the xsl transform to put out the html and so on. The servlet has a massive number of methods from all the commands being handeled. I want to nuke that servlet and instead write cocoon generators to spit out the xml and then let cocoon do its magic. However after 12 hours of reading, Im still a tad lost. Do sitemaps work outside of the cocoon war? No. Wars are completely self-contained things. Yes yes, I know this. But if I deploy 5 different WARs to the server, I dont want to have that HUGE library of jars in every war. How can I set up a simple application, prior to considering generators, outside of the cocoon deployment? What do you mean, 'outside' a deployment? The issue with the jars is what I mean. Note. The lack of truly newbie cocoon documentation is appalling. Fortunately we have a Wiki where anyone can document things. This page looks quite relevant to your question: I will read it ... but I have to say that this looks liek a very powerful front end that once you know it, it is great. Prior to that there is ALLOT of head scratching. And I dont think im any lightweight at programmign either. http://wiki.cocoondev.org/Wiki.jsp?page=SimpleTransformations --Jeff -- Robert - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Cocoon is too complex for consumption?
That is the impression thatI am getting and I'm curious as to feedback from list users. Basically my experience is one of confusion. I downloaded the war and deployed it. The samples and stuff deploy fine but now where does one go from there? The samples and tutorials are splattered all over the net. 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. The default cocoon war contains thousands of files. What does one do to deploy a new application? copy the whole immense framework to a new jar? That seems overly complex for a user that just wants to generate some XML and some XSL and leap off to the races. Its almost like cocoon is buried under complexity. Now I am even being told that in order to use the product, I need to get it from CVS and do builds and so on. For the end user this is just not a viable option. They just want to fire off some XSP pages, some XML and drop it in a war and go. Some 12 hours after I started investigating this technology, still have only a vague clue of what I would need to actually accomplish something. The content of the war is a big part of that problem. The word "overkill" immediately leaps to mind. For the new person to this technology, knowing what each thing does, is nearly impossible. I guess that's what it comes down to for me in the end. I started evaluating using cocoon to replace a static servlet that generates XML manually. The goal was to simplify things by using cocoon. I thought I could just transform that servlet into a cocoon generator, drop it in the right place and go. Doing a lengthy build process, configuration, decoding of what the MOUNTAIN of values in the MOUNTAIN of configuration files mean is just a waste of time for me. In the end, I suppose I'm going to have to stick with the servlet strategy. as a professional developer, I don't have 2 weeks to waste figuring out how to get something working. You look at tomcat for example. The hello world is simple. You drop the minimal 3 class war in tomcat and away it goes. Intimate knowledge of tomcat is not necessary. In fact most users of tomcat authentically don't care about its implementation. 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. 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. The death of XML based web publishing perhaps? Is this why JSP is taking over? Although a flawed paradigm, it allows the neophyte to drop a single hello-world.jsp into a tiny war with 2 deployment descriptors and go. This is the simplicity that the users of the product want. Fiddling around with the base core of the product you are using just isn't in the budget. Well, I will stop babbling now and look forward to comments.
Re: The simplest possible cocoon application?
Well, Actually I came from CORBA so EJB wasn't a big deal. I had Hello World up in 2 hours. I'm looking for a front end to an application that will be the core of a book I'm writing. The content of the book is all about the EJB side and I wanted a powerful but fast front end. Doesn't look like I'm gonna get my wish. And Honestly I don't have a month to blow. -- Robert - Original Message - From: Geoff Howard [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Saturday, January 25, 2003 7:28 AM Subject: RE: The simplest possible cocoon application? - Original Message - From: Jeff Turner [EMAIL PROTECTED] To: Cocoon Users [EMAIL PROTECTED] Sent: Saturday, January 25, 2003 6:02 AM Subject: Re: The simplest possible cocoon application? On Sat, Jan 25, 2003 at 05:21:13AM +0100, Robert Simmons wrote: I currently have the cocoon war installed on my JBoss 3.0.4 server. It works fine. I deployed a second war file that contains an XML and an XSL. The XML has an embedded xsl:stylesheet processing instruction. Embedded stylesheets are very unusual.. are you sure it's Cocoon applying the embedded stylesheet, or the web browser? Hmm, how could I tell? What would you use if you didnt embedd the stylesheet into the XML? Oh, I get it, the pipeline tells it what transform to make ? Addendum: I undeployed cocoon from jboss and the transform still worked. Must be the browser doing it. OOK .. =) Now I feel like i actually know LESS than before. Bingo. My understanding is that Cocoon1 used/allowed embedded stylesheets but cocoon2 ignores them because they tie you to one view. Ok so here is the question. I am now thinking of doing something a bit more than static XML pages. What would be the bare minimum? Do I have to copy the cocoon war and all the libs in it to another deployment or can I use the jars already deployed in the war? Much of what ships with cocoon is optional - at this stage there is a kitchen sink philosophy for distribution: everything is turned on by default, every optional part is included by default. Good for showcasing but obviously not needed for deployment. The binary distributions will come like this, so you may want to consider building from source and specifying build properties so that only what you need is built. If you have a source distribution or cvs checkout, look in the lib directory and you'll see (at least) two directories. Obviously everything in optional can be removed if it looks like something you don't need (probably a lot). The old build system (2.0.3 and maybe 2.0.4) relied on the presence of those jars to determine what you wanted included. If you're using 2.1 dev, have a look at properties.xml in the main directory. This is where build properties are specified. Not sure if you're familiar with ant, but the way its properties work you can override those settings without modifying the file by including a .ant.properties file in that directory (or in your home directory) and those will take precedence. Those files have a different format by the way. Unfortunately, you can't undefine a property and the build in some places relies on the presence of a property to determine behavior (at least it used to) so there you'll be stuck modifying the original file. There is a new concept aimed at separating core elements from optional ones called blocks. This provides even more ability to trim out unneeded elements, but I think it's only in 2.1 (although it may be in 2.0.4?). properties.xml specifies which blocks to build. Each war has one main sitemap. Each sitemap can have lots of different pipelines. Where did the 'second war file' you mention come from? Did you copy the sitemap and WEB-INF/cocoon.xconf from the Cocoon samples war? What I mean is that, if possible, I dont want to copy the whole MASSIVE jar library in the cocoon distribution war into every blasted web app that I create. Trimming the size of the webapp as described above will help, but also consider whether you need each to be a separate webapp, or can deploy them within one cocoon instance. The cocoon concept of mounted sub-sitemaps get you a lot of what you'd want with separate webapps. Maybe if you voice a few specific issues others can help figure out whether this solution will work for you. The thing thats stumping the newbie here is how a user uses it. It almost seems like i have to be practically a dveloper on cocoon to use it. I honestly dont care how it works, I just ultimately want to write come generators that smack a EJB and spit out XML that then gets transformed. Well, that's pretty easy. I'd suggest first starting with static xml files using the wiki page Jeff provided to get the basics of using the sitemap and pipelines, then try building a few simple generators following the tutorial (http://xml.apache.org/cocoon/tutorial
Re: Cocoon is too complex for consumption?
I think you might already be there. Currently the concept of cocoon is a great one. I create a piepline and cocoon shunts it from a to b, applying the transforms and so on. Great development effort. Pardon the language but its a shitty user effort. Just look at one of your paragraphs in the linked archive. quote If we don't do this, not only Cocoon will get bigger and bigger (and start appearing more as a distribution of technologies, than a framework), but users will find it harder and harder to modify it for their specific needs. /quote And that is the crux of the problem. Whoever is heading the project seems a bit confused. People dont want to MODIFY cocoon. They want to USE cocoon. They want to install cocoon's mechanics, then drop in their pipelines and go. Cocoon is now trying to do all sorts of things that dont need to be done imho. The number of features is so staggering that gettign started is near impossible. But as I get more into the product, I find myself saying, petulantly, But I just wanted the pipeline! And that is all that I wanted. To have a pipeline. To be able to say to cocoon, Yeah, well ... in your pipeline whenever someone hits URL x, go to pipeline Z and run my custom class (which connects to ejbs and so on) and transform it with stylesheet Y and give it back to the user. But you arent understanding how cocoon works Robert! BINGO!! You hit it right there on the head. I dont want to understand how it works. As a user Im not interested. When reading the JBoss documentation, I skip over all the architecture stuff and the development stuff. As a user, this stuff is irrelevant to me. Object oriented programmign is supposed to guarantee to provide me with an interface and then implement some functionality. How? Who the hell cares? Im a user of it. My prime computing expertise is in the back end side of EJBs and issues that pertain to them. I want to USE cocoon, not develop on it. Possible solutions to this. 1) Rearchitect cocoon to implement some sort of deployment mechanism, such as COB. The problem here is that then you have to get that working with application servers and so on. The other problem is inertia. Gettign the masses of developers to learn a new-unstandardized deployment mechanism. 2) MERGE it with tomcat in the way JBoss has merged with tomcat. I download JBoss and they are like well tomcat is included. I say cool and drop in my wars and go. If cocoon had a basic mechanism install that could be installed into tomcat than the situation would be aleviated. Users of the product drop their wars into tomcat as normal with a sitemap file in the WEB-INF directory and their special generators an so on in the classes directory. Cocoon magically wires together the pipeline. No worrying about how to configure cocoon or what properties to give it or so on. Thats left to advanced users under the heading of customizing your install. At any rate I can see the learning curve for this product is steep. And cocoon is mainly going o suffer from people like me. People whoe would love to use it but dont have a month to blow trying to get a technology to work that is merely suppsed to be an EASY way to develop a polymorphic presentation layer. Lastly, flaming is not an option. These are the opinions from a newbie comming into cocoon. Readers of this list can flame all they want but that is just hiding from the very real problems. -- Robert - Original Message - From: Steven Noels [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Saturday, January 25, 2003 3:43 PM Subject: Re: Cocoon is too complex for consumption? Jeff Turner wrote: http://wiki.cocoondev.org/Wiki.jsp?page=BlocksDefinition http://marc.theaimsgroup.com/?l=xml-cocoon-devm=101603335007960w=2 http://marc.theaimsgroup.com/?l=xml-cocoon-devm=101732982704553w=2 oh, but that is unfair since you are a Cocoon committer and you have easier access to such things... not! ;-) /Steven -- Steven Noelshttp://outerthought.org/ Outerthought - Open Source, Java XML Competence Support Center Read my weblog athttp://blogs.cocoondev.org/stevenn/ stevenn at outerthought.orgstevenn at apache.org - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Cocoon is too complex for consumption?
Well you are wrong. I know all of those and some of them QUITE well. And still getting cocoon going is a major hassle. Yes, I can deploy the distribution but I mean getting my own application going. Just a hello-world app. -- robert - Original Message - From: Gustavo Nalle Fernandes [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Saturday, January 25, 2003 5:56 PM Subject: RES: Cocoon is too complex for consumption? Cocoon is a powerfull _framework_ used to develop XML applications and not an out of the box product. As a framework, Cocoon architecture must be well understood in order provide extensions that satisfies a particular need. IMHO, Cocoon´s leaning curve is not steep, assuming that the -DEVELOPER- knows XML, XSL, Namespaces, DTD, SCHEMA, HTTP,Servlets and JAVA/OOP. -Mensagem original- De: Robert Simmons [mailto:[EMAIL PROTECTED]] Enviada em: sábado, 25 de janeiro de 2003 14:13 Para: [EMAIL PROTECTED] Assunto: Re: Cocoon is too complex for consumption? I think you might already be there. Currently the concept of cocoon is a great one. I create a piepline and cocoon shunts it from a to b, applying the transforms and so on. Great development effort. Pardon the language but its a shitty user effort. Just look at one of your paragraphs in the linked archive. quote If we don't do this, not only Cocoon will get bigger and bigger (and start appearing more as a distribution of technologies, than a framework), but users will find it harder and harder to modify it for their specific needs. /quote And that is the crux of the problem. Whoever is heading the project seems a bit confused. People dont want to MODIFY cocoon. They want to USE cocoon. They want to install cocoon's mechanics, then drop in their pipelines and go. Cocoon is now trying to do all sorts of things that dont need to be done imho. The number of features is so staggering that gettign started is near impossible. But as I get more into the product, I find myself saying, petulantly, But I just wanted the pipeline! And that is all that I wanted. To have a pipeline. To be able to say to cocoon, Yeah, well ... in your pipeline whenever someone hits URL x, go to pipeline Z and run my custom class (which connects to ejbs and so on) and transform it with stylesheet Y and give it back to the user. But you arent understanding how cocoon works Robert! BINGO!! You hit it right there on the head. I dont want to understand how it works. As a user Im not interested. When reading the JBoss documentation, I skip over all the architecture stuff and the development stuff. As a user, this stuff is irrelevant to me. Object oriented programmign is supposed to guarantee to provide me with an interface and then implement some functionality. How? Who the hell cares? Im a user of it. My prime computing expertise is in the back end side of EJBs and issues that pertain to them. I want to USE cocoon, not develop on it. Possible solutions to this. 1) Rearchitect cocoon to implement some sort of deployment mechanism, such as COB. The problem here is that then you have to get that working with application servers and so on. The other problem is inertia. Gettign the masses of developers to learn a new-unstandardized deployment mechanism. 2) MERGE it with tomcat in the way JBoss has merged with tomcat. I download JBoss and they are like well tomcat is included. I say cool and drop in my wars and go. If cocoon had a basic mechanism install that could be installed into tomcat than the situation would be aleviated. Users of the product drop their wars into tomcat as normal with a sitemap file in the WEB-INF directory and their special generators an so on in the classes directory. Cocoon magically wires together the pipeline. No worrying about how to configure cocoon or what properties to give it or so on. Thats left to advanced users under the heading of customizing your install. At any rate I can see the learning curve for this product is steep. And cocoon is mainly going o suffer from people like me. People whoe would love to use it but dont have a month to blow trying to get a technology to work that is merely suppsed to be an EASY way to develop a polymorphic presentation layer. Lastly, flaming is not an option. These are the opinions from a newbie comming into cocoon. Readers of this list can flame all they want but that is just hiding from the very real problems. -- Robert - Original Message - From: Steven Noels [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Saturday, January 25, 2003 3:43 PM Subject: Re: Cocoon is too complex for consumption? Jeff Turner wrote: http://wiki.cocoondev.org/Wiki.jsp?page=BlocksDefinition http://marc.theaimsgroup.com/?l=xml-cocoon-devm=101603335007960w=2 http://marc.theaimsgroup.com/?l=xml-cocoon-devm=101732982704553w=2 oh, but that is unfair since you are a Cocoon committer and you have easier access
Re: Cocoon is too complex for consumption?
I don't forget that. Nor do I expect everyone to adapt to my way. Not at all. However I know for a fact that I am not the only new user to cocoon having these issues. I can look at the mailing list archive a long way back and see people who have come, posted the same opinions and then subsequently never posted again. You may say fine they can go to hell. but if you are trying to make a technology not just be a little niche technology with a little tight club as members than you need to change this turnover. People should come into cocoon, see its power and rapidly get a hello world up and start running with it. Only through this can you save the technology from the heap where all the other failed ones went. The fact is that JSP continues to gather momentum and the era of XML-XSLT has all but been forgotten. To what do you attribute this? XML and XSLT and by extension cocoon has a very narrow window to get some serious press to make itself live. This window is passing by. Sitting there and saying those damn newbies don't know anything! might satisfy your sense of self but doesn't promote the technology. Similarly, replying to a mail such as mine and saying Don't expect everything to be _your_ way the moment you arrive, doesn't accomplish anything except getting people to say, ok fair enough, and heading for the door. In the end, cocoon has two choices. Adapt to the users or die. Its as simple as that. If you keep telling us to shut up for whining about how hard it is to get started, that's fine. The technology will die. If you ask me, the cocoon development effort should refocus itself from developing more features to getting the product in a state such as tomcat is in. A state where people say cocoon? Oh that's easy to use. getting hello-world to work is like a 10 minute affair. You only need to worry about all the fancy features if you need to use them, give it a shot. Right now, to the newbie, cocoon only inspires three words. Those are, What the hell? As for me, I don't screw with it any more. I have a book to write and publishing schedules to make and the book isn't even remotely about client side stuff and therefore anything not easy on the client side has to be off the shelf. -- Robert - Original Message - From: Steven Noels [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Saturday, January 25, 2003 7:03 PM Subject: Re: Cocoon is too complex for consumption? Robert Simmons wrote: Lastly, flaming is not an option. These are the opinions from a newbie comming into cocoon. Readers of this list can flame all they want but that is just hiding from the very real problems. Robert, I can only give you one advise: don't forget human beings are sitting behind these MUAs. Don't expect everything to be _your_ way the moment you arrive. (ditto for the Jakarta Forums idea). /Steven -- Steven Noelshttp://outerthought.org/ Outerthought - Open Source, Java XML Competence Support Center Read my weblog athttp://blogs.cocoondev.org/stevenn/ stevenn at outerthought.orgstevenn at apache.org - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Cocoon is complex, but worth it! Some Answers to your dilemma
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 ?xml version=1.0? map:sitemap xmlns:map=http://apache.org/cocoon/sitemap/1.0; !-- === Components === -- map:components map:generators default=file/ map:transformers default=xslt/ map:readers default=resource/ map:serializers default=html map:serializer logger=sitemap.serializer.xml mime-type=text/xml name=xml src=org.apache.cocoon.serialization.XMLSerializer/ map:serializer logger=sitemap.serializer.html mime-type=text/html name=html pool-grow=4 pool-max=32 pool-min=4 src=org.apache.cocoon.serialization.HTMLSerializer buffer-size1024/buffer-size /map:serializer /map:serializers map:matchers default=wildcard/ map:selectors default=browser/ /map:components !-- === Pipelines = -- map:pipelines map:pipeline map:match pattern=** !-- = Dynamic Content -- map:match pattern=viewHTML/** map:generate src=myXMLDataSource/ map:transform src=myXSLSheet/
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. 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 in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail:
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. 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 think some people here had the same feel.
Re: Cocoon is complex, but worth it! Some Answers to your dilemma
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 faced again with this technology. Please, Take a note of that. Probably
Re: Cocoon is too complex for consumption?
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. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Cocoon is 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? 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 map:match pattern=hellothere.html map:generate src=myxmlfile.xml/ map:transform src=myxslfile.xsl/ map:serialize/ /map:match 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
Re: Cocoon is complex, HOLD ON, WHY IS THIS BOILING UP ?
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 posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED
Re: Cocoon is complex, but worth it! Some Answers to your dilemma
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): quote 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 war-file directory name=WEB-INF directory name=lib file name=cocoon-all.jar/ /directory file name=web.xml/ /directory sitemap.xmap /war-file 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
Re: Cocoon is too complex for consumption?
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 to mount more than one jar, something is borked. Basically just facade all the entry points
Redeploy in JBoss Causes Hang
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
Single JAR with all the libs?
Is there a way to compress all the cocoon jars into one jar so I can just drop in my application server like a golf ball and all cocoon deployments will have access to it ? -- Robert
Re: Single JAR with all the libs?
Ya I know that. I'm not talking about the prebuilt, distributed web application. I am trying to develop a strategy for other users to be able to use cocoon from within JBoss without having to leap through 15 hoops. So I basically want a way I can build cocoon libs and then in each war file I make that uses cocoon, I merely need the config files and only things pertaining to my stuff and not to cocoon in general. Getting the kitchen sink build working was a matter of just dropping it in JBoss. Now I want to go further and make other applications with the product. Right now Id have to resort to telling readers to download cocoon, unpack it, rewrite their manifests to include the Cocoon-Libs section, then run the build which should convert the old libs to the new location and then install cocoon. Picture this scenario. You want to use cocoon for a front end to a powerful EJB based system. Your readers of your book want to download your source code and install it and get it running. They need a simple process. Right now the process is download the kitchen sink version, figure out what the hell you don't need, repack everything and deploy it. Not functional for users of the product. Therefore I keep rolling back around to having a single jar that I can drop in JBoss like an oversized golf ball and call cocoon installed and ready for users to deploy their OWN war files that use cocoon rather than asking them to modify cocoon's war. I'm not sure if I'm making sense here. -- Robert - Original Message - From: Luca Morandini [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Sunday, January 26, 2003 9:41 AM Subject: RE: Single JAR with all the libs? Robert, I'm not sure I've understood your question, but I like to give it a try. When you build Cocoon, it produces a WAR file, you just: 1) put the WAR under the webapps of your servlet container 2) re-start the container The you can deploy your Cocoon app under the mount directory, hence avoid editing the general sitemap.xmap (the one in webapps/cocoon). Regards, - Luca Morandini GIS Consultant [EMAIL PROTECTED] http://utenti.tripod.it/lmorandini/index.html - -Original Message- From: Robert Simmons [mailto:[EMAIL PROTECTED]] Sent: Sunday, January 26, 2003 9:07 AM To: Cocoon Users Subject: Single JAR with all the libs? Is there a way to compress all the cocoon jars into one jar so I can just drop in my application server like a golf ball and all cocoon deployments will have access to it ? -- Robert - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Single JAR with all the libs?
Hmm one question though. This huge manifest attribute called Cocoon-Libs. Where is it used in the application? Can I leave it out ? - Original Message - From: Luca Morandini [EMAIL PROTECTED] To: Cocoon-users [EMAIL PROTECTED] Sent: Sunday, January 26, 2003 10:45 AM Subject: RE: Single JAR with all the libs? Robert, well, if I were you I'd tweak the build.xml to tailor it to your needs, and just tell the readers to: 1) replace the native build.xml with yours 2) run it 3) deploy the resulting WAR. I have no idea of alternative approaches... sorry :( Regards, - Luca Morandini GIS Consultant [EMAIL PROTECTED] http://utenti.tripod.it/lmorandini/index.html - -Original Message- From: Robert Simmons [mailto:[EMAIL PROTECTED]] Sent: Sunday, January 26, 2003 9:57 AM To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: Single JAR with all the libs? Ya I know that. I'm not talking about the prebuilt, distributed web application. I am trying to develop a strategy for other users to be able to use cocoon from within JBoss without having to leap through 15 hoops. So I basically want a way I can build cocoon libs and then in each war file I make that uses cocoon, I merely need the config files and only things pertaining to my stuff and not to cocoon in general. Getting the kitchen sink build working was a matter of just dropping it in JBoss. Now I want to go further and make other applications with the product. Right now Id have to resort to telling readers to download cocoon, unpack it, rewrite their manifests to include the Cocoon-Libs section, then run the build which should convert the old libs to the new location and then install cocoon. Picture this scenario. You want to use cocoon for a front end to a powerful EJB based system. Your readers of your book want to download your source code and install it and get it running. They need a simple process. Right now the process is download the kitchen sink version, figure out what the hell you don't need, repack everything and deploy it. Not functional for users of the product. Therefore I keep rolling back around to having a single jar that I can drop in JBoss like an oversized golf ball and call cocoon installed and ready for users to deploy their OWN war files that use cocoon rather than asking them to modify cocoon's war. I'm not sure if I'm making sense here. -- Robert - Original Message - From: Luca Morandini [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Sunday, January 26, 2003 9:41 AM Subject: RE: Single JAR with all the libs? Robert, I'm not sure I've understood your question, but I like to give it a try. When you build Cocoon, it produces a WAR file, you just: 1) put the WAR under the webapps of your servlet container 2) re-start the container The you can deploy your Cocoon app under the mount directory, hence avoid editing the general sitemap.xmap (the one in webapps/cocoon). Regards, - Luca Morandini GIS Consultant [EMAIL PROTECTED] http://utenti.tripod.it/lmorandini/index.html - -Original Message- From: Robert Simmons [mailto:[EMAIL PROTECTED]] Sent: Sunday, January 26, 2003 9:07 AM To: Cocoon Users Subject: Single JAR with all the libs? Is there a way to compress all the cocoon jars into one jar so I can just drop in my application server like a golf ball and all cocoon deployments will have access to it ? -- Robert - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Smileys Cocoon sample
Hmm well that is what im getting to .. im pretty much on today tinkering with cocoon trying to get a build that will be a bit more deployable to the newb. What i want is for readers of my book (which Im writing on SERVER side issues (as in EJB) to be able to download everything and run the sucker. Right now id have to package in soem 30 jars and that would be just too much. If i can find a way to pack it into one jar and have cocoon still work then I w ould be a long way towards my goal. Then I would be debating using a custom generator or exploring actions (possibly, I dotn know) or just straight xsp. The smileys are the first thing ive done since it is the easiest to implement what we like to call the thin row. -- robert - Original Message - From: Luca Morandini [EMAIL PROTECTED] To: Cocoon-users [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Sunday, January 26, 2003 10:52 AM Subject: Smileys Cocoon sample Robert, I've taken a look at your code and I'm tinkering with the idea of re-write it using Cocoon... could you be of assistance today ? BTW, there is any other poster who'd like to replicate this example in Cocoon ? Regards, - Luca Morandini GIS Consultant [EMAIL PROTECTED] http://utenti.tripod.it/lmorandini/index.html - - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Single JAR with all the libs?
Ok I yanked the manifest file from WEB-INF and it all still seems to work, though I don't know about in the full cocoon deployment. Is there any JUnit built into this sucker? -- Robert - Original Message - From: Robert Simmons [EMAIL PROTECTED] To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Sunday, January 26, 2003 1:12 PM Subject: Re: Single JAR with all the libs? Hmm one question though. This huge manifest attribute called Cocoon-Libs. Where is it used in the application? Can I leave it out ? - Original Message - From: Luca Morandini [EMAIL PROTECTED] To: Cocoon-users [EMAIL PROTECTED] Sent: Sunday, January 26, 2003 10:45 AM Subject: RE: Single JAR with all the libs? Robert, well, if I were you I'd tweak the build.xml to tailor it to your needs, and just tell the readers to: 1) replace the native build.xml with yours 2) run it 3) deploy the resulting WAR. I have no idea of alternative approaches... sorry :( Regards, - Luca Morandini GIS Consultant [EMAIL PROTECTED] http://utenti.tripod.it/lmorandini/index.html - -Original Message- From: Robert Simmons [mailto:[EMAIL PROTECTED]] Sent: Sunday, January 26, 2003 9:57 AM To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: Single JAR with all the libs? Ya I know that. I'm not talking about the prebuilt, distributed web application. I am trying to develop a strategy for other users to be able to use cocoon from within JBoss without having to leap through 15 hoops. So I basically want a way I can build cocoon libs and then in each war file I make that uses cocoon, I merely need the config files and only things pertaining to my stuff and not to cocoon in general. Getting the kitchen sink build working was a matter of just dropping it in JBoss. Now I want to go further and make other applications with the product. Right now Id have to resort to telling readers to download cocoon, unpack it, rewrite their manifests to include the Cocoon-Libs section, then run the build which should convert the old libs to the new location and then install cocoon. Picture this scenario. You want to use cocoon for a front end to a powerful EJB based system. Your readers of your book want to download your source code and install it and get it running. They need a simple process. Right now the process is download the kitchen sink version, figure out what the hell you don't need, repack everything and deploy it. Not functional for users of the product. Therefore I keep rolling back around to having a single jar that I can drop in JBoss like an oversized golf ball and call cocoon installed and ready for users to deploy their OWN war files that use cocoon rather than asking them to modify cocoon's war. I'm not sure if I'm making sense here. -- Robert - Original Message - From: Luca Morandini [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Sunday, January 26, 2003 9:41 AM Subject: RE: Single JAR with all the libs? Robert, I'm not sure I've understood your question, but I like to give it a try. When you build Cocoon, it produces a WAR file, you just: 1) put the WAR under the webapps of your servlet container 2) re-start the container The you can deploy your Cocoon app under the mount directory, hence avoid editing the general sitemap.xmap (the one in webapps/cocoon). Regards, - Luca Morandini GIS Consultant [EMAIL PROTECTED] http://utenti.tripod.it/lmorandini/index.html - -Original Message- From: Robert Simmons [mailto:[EMAIL PROTECTED]] Sent: Sunday, January 26, 2003 9:07 AM To: Cocoon Users Subject: Single JAR with all the libs? Is there a way to compress all the cocoon jars into one jar so I can just drop in my application server like a golf ball and all cocoon deployments will have access to it ? -- Robert - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail
Re: Smileys Cocoon sample... the sequel
I do all my database work in the EJBs on the server side using JDO. JDO is basically god for persisting Java objects. =) I can probably figure out how to connect the suckers. In fact if I'm not too far off I can drop them in the container and just grab an initial context. However what I'm trying to envision is my reader deploying this and shot of reproducing the build file or telling my users to unpack the cocoon war, I don't know what to do exactly. If there was one jar they could include, it would be perfect. I envision a user being able to download a jar file that has every one of the classes all jared into one cocoon-all.jar and then dropping it as one unit in their WEB-INF/lib directory but I'm not sure how to accomplish that. I would also need to know if the path to the cocoon properties file and the xconf files are hardcoded as I would like to file them away too. but now I'm talking about developing on cocoon and that's what I was trying to avoid. Sigh. -- Robert. - Original Message - From: Luca Morandini [EMAIL PROTECTED] To: Cocoon-users [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Sunday, January 26, 2003 1:35 PM Subject: Smileys Cocoon sample... the sequel Robert, I've developed a tentative Cocoon implemtation of your sample. 1) I've defined a suitable selector in order to switch to different contents according to its value: map:selector name=command-selector src=org.apache.cocoon.selection.RequestParameterSelector parameter-namecommand/parameter-name /map:selector 2) Then use it to make the actual switching: map:match name=wildcard pattern=*.html map:select type=command-selector map:when test=SysAdminView map:generate type=file src=cocoon:/sp-getall-smileys.xml/ /map:when map:when test=SmileyEditView map:generate type=file src=cocoon:/sp-get-smiley.xml/ /map:when map:otherwise map:generate type=file src=documents/smileys.xml/ /map:otherwise /map:select map:transform src=stylesheets/jconfer-page.xsl/ map:serialize type=html/ /map:match You may notice that now you don't have to aearch the servlets to understand how the content-reading switching works, it is all in one place: the pipeline. This begs the question: where can you get your content from ? Or, better, how Cocoon deals with RDBMS (which are the most common persistence mechanism around). Well, I use (as you may infer from the names I gave to contents URIs), Stored Procedures via SQLTransformer. Probably not the fastest way, but sure the most flexible and SoC-oriented. You can use DatabaseActions, ESQL, or EJBs... which is the option appealing most to you, I guess. How to get an EJB from Cocoon... no idea sorry, I steered well clear of JSP, Servlets and EJBs. Regards, - Luca Morandini GIS Consultant [EMAIL PROTECTED] http://utenti.tripod.it/lmorandini/index.html - - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Smileys Cocoon sample... the sequel
dont forget that this is jsut a very small part of the application and a refactoring usign the sitemap is a good thing. But yes, the data will be retrieved from EJBs as that is my specialty and what has proven to be ubver powerful in the server side. Client side I think cocooncould lay all others to waste if I could just get it going down the road im thinkign of. -- Robert - Original Message - From: Luca Morandini [EMAIL PROTECTED] To: Cocoon-users [EMAIL PROTECTED] Sent: Sunday, January 26, 2003 2:01 PM Subject: RE: Smileys Cocoon sample... the sequel Robert, I think I misunderstood you. Did you want the same approach (servlets + EJB + XSL) to work In Cocoon ? It could be done, it's only a configuration problem... but what's the point ? I mean, if you want to show how Cocoon could help developing apps you should go the Cocoon way a little. This is why I thought useful re-factoring your sample using the sitemap... did you need something else, or what ? Regards, - Luca Morandini GIS Consultant [EMAIL PROTECTED] http://utenti.tripod.it/lmorandini/index.html - -Original Message- From: Robert Simmons [mailto:[EMAIL PROTECTED]] Sent: Sunday, January 26, 2003 1:55 PM To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: Smileys Cocoon sample... the sequel I do all my database work in the EJBs on the server side using JDO. JDO is basically god for persisting Java objects. =) I can probably figure out how to connect the suckers. In fact if I'm not too far off I can drop them in the container and just grab an initial context. However what I'm trying to envision is my reader deploying this and shot of reproducing the build file or telling my users to unpack the cocoon war, I don't know what to do exactly. If there was one jar they could include, it would be perfect. I envision a user being able to download a jar file that has every one of the classes all jared into one cocoon-all.jar and then dropping it as one unit in their WEB-INF/lib directory but I'm not sure how to accomplish that. I would also need to know if the path to the cocoon properties file and the xconf files are hardcoded as I would like to file them away too. but now I'm talking about developing on cocoon and that's what I was trying to avoid. Sigh. -- Robert. - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Smileys Cocoon sample... the sequel
Ahh, perhaps I'm not making myself clear. Enterprise programmers have a sort of different view of server and client side. To us, anything requesting services of an EJB that isn't an EJB itself is a client. My vision is the following EJBs implementing complex logic in a distributed manner. These Components will have a number of clients, some clients are things like the web and wireless devices (where I think cocoon might apply) other clients are things like GUI's, other businesses, other software and so on. Cocoon is a powerful presentation tier but I would never want to drop business logic into it. First of all it constrains me that all of my clients are web based. Second of all, its not scalable when talking about thousands of transactions per second (my normal ballpark in EJB systems) third of all its limiting in its scope. For these and other reasons I wouldn't use cocoon for more than a presentation tier. -- Robert - Original Message - From: Luca Morandini [EMAIL PROTECTED] To: Cocoon-users [EMAIL PROTECTED] Sent: Sunday, January 26, 2003 2:45 PM Subject: RE: Smileys Cocoon sample... the sequel -Original Message- From: Robert Simmons [mailto:[EMAIL PROTECTED]] Sent: Sunday, January 26, 2003 2:35 PM To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: Smileys Cocoon sample... the sequel dont forget that this is jsut a very small part of the application and a refactoring usign the sitemap is a good thing. But yes, the data will be retrieved from EJBs as that is my specialty and what has proven to be ubver powerful in the server side. Client side I think cocooncould lay all others to waste if I could just get it going down the road im thinkign of. Which I have not yet understood, I'm afraid. Anyway, I hold a different view: Cocoon can rule server-side, coupled with some business-logic tier, like Stored Procedures or EJBs. After all, the content-switching mechanism I've showed you in my pipeline belongs to the server-side, doesn't it ? Regards, - Luca Morandini GIS Consultant [EMAIL PROTECTED] http://utenti.tripod.it/lmorandini/index.html - - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Single JAR with all the libs? - rejar the distrib ...
Actually there is another option. Package all of the jars into a jar so that the contents of that jar are all of the files. Then alter the manifest of the containing jar (cocoon-all.jar) and add a Class-Path attribute with the names of each of the sub jars. Now putting the cocoon-all.jar in the path will cause them all to be in the classpath. ie: cocoon-all.jar -- META-INF/MANIFEST.MF -- avalon-framework-20020627.jar -- batik-all-1.5b2.jar -- bsf-2.2.jar -- (etc ...) MANIFEST.MF Created-By: Cocoon Developer Comittee. Class-Path: avalon-framework-20020627.jar batik-all-1.5b2.jar bsf-2.2.jar (etc ...) Viola .. one large jar containing many small jars. This would take a comitter with good knowledge of the build.xml abotu 10 min to implement. Make it 20 to test it. :) -- Robert - Original Message - From: SAXESS - Hussayn Dabbous [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Sunday, January 26, 2003 1:43 PM Subject: Re: Single JAR with all the libs? - rejar the distrib ... If i understand you correct, you simply want to avoid deploying several cocoon-based webapps all containing tons of the same jar files ? And in order to keep your customers happy, you want to simplify the deployment by bundling all cocoon jars into one big jar, deploying this golfball.jar independently from cocoon into your appserver? Then your webapps get significantly smaller because you only have to deploy the cocoon configs and the webapp specifics ...? If this is what you want, you can do it in two ways: WAY I - this is a very simplistic approach with some caveats, but it works. There may be a license problem here, but i don't know this for shure: 1.) unwar your cocoon distribution to any convenient place 2.) go to the WEB-INF/lib directory 3.) Now for each jarfile in the directory simply do: jar xf thefile.jar Of course you may skip all jars you dont need for your distribution ... 4.) throw away the .jar files 5.) jar cf golfball.jar * Now you have one single jar file, that you can distribute to whereever your container needs it to serve as common cocoon classes for your webapps. Finally you could repack the cocoon.war from step 1.) without the lib/*.jar files, add your webapp specific data (config/files/ programs) and deploy the result as co-webapps into your container ... But you have to keep one caveat in your mind: You may fall into strongly hidden compatibility issues when your webapps use other versions of the .jar modules you just have bundled to allclasses.jar If you take the single jars as they are, at least you can easier track down which module (.jar file) causes compatibility issues. And you can easier exchanche module jars if needed although i must admit, sometimes exchanging one jar out of a bunch may not be trivial at all ;-) The golfball.jar only allows to determine, which classes cause problems. WAY II -- If you are under unix, you can reach your goal by clever use of softlinks. In my development environment we sometimes have to run 5 to 10 cocoon-based webapps all across multiple platforms, multiple containers and so on. And we found a nice solution, that fits for our purposes. If this is something, anyone would be interested in, we could share knowledge here, but since this is kind of special i wouldn't bother this list and do this offline. just drop me an email. regards, hussayn hope, that helps Robert Simmons wrote: Is there a way to compress all the cocoon jars into one jar so I can just drop in my application server like a golf ball and all cocoon deployments will have access to it ? -- Robert -- Dr. Hussayn Dabbous SAXESS Software Design GmbH Neuenhöfer Allee 125 50935 Köln Telefon: +49-221-56011-0 Fax: +49-221-56011-20 E-Mail: [EMAIL PROTECTED] - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Single JAR with all the libs? - rejar the distrib ...
Incidentally you should probably index that jar since it will have lots of classes and make the classloader throw fits trying to find things. Performance wise its best to index. - Original Message - From: Robert Simmons [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Sunday, January 26, 2003 11:55 PM Subject: Re: Single JAR with all the libs? - rejar the distrib ... Actually there is another option. Package all of the jars into a jar so that the contents of that jar are all of the files. Then alter the manifest of the containing jar (cocoon-all.jar) and add a Class-Path attribute with the names of each of the sub jars. Now putting the cocoon-all.jar in the path will cause them all to be in the classpath. ie: cocoon-all.jar -- META-INF/MANIFEST.MF -- avalon-framework-20020627.jar -- batik-all-1.5b2.jar -- bsf-2.2.jar -- (etc ...) MANIFEST.MF Created-By: Cocoon Developer Comittee. Class-Path: avalon-framework-20020627.jar batik-all-1.5b2.jar bsf-2.2.jar (etc ...) Viola .. one large jar containing many small jars. This would take a comitter with good knowledge of the build.xml abotu 10 min to implement. Make it 20 to test it. :) -- Robert - Original Message - From: SAXESS - Hussayn Dabbous [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Sunday, January 26, 2003 1:43 PM Subject: Re: Single JAR with all the libs? - rejar the distrib ... If i understand you correct, you simply want to avoid deploying several cocoon-based webapps all containing tons of the same jar files ? And in order to keep your customers happy, you want to simplify the deployment by bundling all cocoon jars into one big jar, deploying this golfball.jar independently from cocoon into your appserver? Then your webapps get significantly smaller because you only have to deploy the cocoon configs and the webapp specifics ...? If this is what you want, you can do it in two ways: WAY I - this is a very simplistic approach with some caveats, but it works. There may be a license problem here, but i don't know this for shure: 1.) unwar your cocoon distribution to any convenient place 2.) go to the WEB-INF/lib directory 3.) Now for each jarfile in the directory simply do: jar xf thefile.jar Of course you may skip all jars you dont need for your distribution ... 4.) throw away the .jar files 5.) jar cf golfball.jar * Now you have one single jar file, that you can distribute to whereever your container needs it to serve as common cocoon classes for your webapps. Finally you could repack the cocoon.war from step 1.) without the lib/*.jar files, add your webapp specific data (config/files/ programs) and deploy the result as co-webapps into your container ... But you have to keep one caveat in your mind: You may fall into strongly hidden compatibility issues when your webapps use other versions of the .jar modules you just have bundled to allclasses.jar If you take the single jars as they are, at least you can easier track down which module (.jar file) causes compatibility issues. And you can easier exchanche module jars if needed although i must admit, sometimes exchanging one jar out of a bunch may not be trivial at all ;-) The golfball.jar only allows to determine, which classes cause problems. WAY II -- If you are under unix, you can reach your goal by clever use of softlinks. In my development environment we sometimes have to run 5 to 10 cocoon-based webapps all across multiple platforms, multiple containers and so on. And we found a nice solution, that fits for our purposes. If this is something, anyone would be interested in, we could share knowledge here, but since this is kind of special i wouldn't bother this list and do this offline. just drop me an email. regards, hussayn hope, that helps Robert Simmons wrote: Is there a way to compress all the cocoon jars into one jar so I can just drop in my application server like a golf ball and all cocoon deployments will have access to it ? -- Robert -- Dr. Hussayn Dabbous SAXESS Software Design GmbH Neuenhöfer Allee 125 50935 Köln Telefon: +49-221-56011-0 Fax: +49-221-56011-20 E-Mail: [EMAIL PROTECTED] - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail
CatalogManager.properties in WEB-INF/classes ??
What is this file for and can it be omitted from the package? If it cant be omitted is it something that the user should be editing? -- Robert
Cocoon 2.1 the usability release?
Given the recent discussion about the difficulty getting into cocoon, I am wondering if we should start an initiative to make a maintenance release for cocoon that would have a focus on usability for new users. The following is a list of features I propose for this release. 1) A binary distribution stripped of all examples and documentation. This distribution would have only a single static XML and XSL file in a subdirectory called welcome that would be set up as a welcome page. The main sitemap file in the cocoon root directory would have anything not needed to serve this page as HTML commented out or removed. It would contain the mount only for that part of the site. 2) A all of the jars are filed into a single containing jar called cocoon-all.jar and placed in the WEB-INF/lib directory. This should remove "jar shock" from the users new to the system while retaining the modularity. A user can always unpack the cocoon-all.jar or replace a jar in the file if he chooses. 3) A new jar called cocoon-ext.jar. This jar would contain only the needed classes for compiling extensions (such as generators) to cocoon. It would be for users to mount in their development IDEs instead of having to mount the entire cocoon-all.jar. In the distribution, a new directory called dev-libs would be created and this jar would be placed in there. 4) All properties and xconf files that the user doesn't need to routinely edit would be packed into the cocoon-all.jar. The code loading these files would be adapted so that if a user chooses to provide his own xconf files (at his own risk), he can do so. Perhaps the code looks for custom-cocoon.xconf in the classpath and if it doesn't find it, then it loads the default one in the cocoon-all.jar. 5) Creation of all of these parts would be in the build.xml file, perhaps we can use the target name "golfball" for building the whole cocoon-all.jar. *smirk* 6) Providing both the full documented kitchen sink as well as the stripped jar for binary distribution download. Features id like to see: a) Replacing logikit with Log4j. Log4j is by far the most widespread of the logging packages used today and users will typically want to have all of their logging functioning in one product. That way a network admin can use a Log4j viewer tool to monitor the health of the system instead of needing to parse several logs. b) A reference manual on all the included generators, actions,serializers and so on:and what they do. The target audience for this is the sitemap developer who just wants to wire together pipelines. b) Reorganization of the documentation to allow a more coherent approach to learning cocoon. Starting with including basic newbie guides to get hello-world up in 15 minutes or less. Users that can get it working fast get excited and go further and faster. Its the hook that draws them in. Keep in mind I am coming from a usability point only. My basic premise is that newbies coming here will mostly not have the tenaciousness that I do and will be under deadline guns. Hooking them on cocoon by getting them in the door can only be good for the project and its technology. -- Robert
Re: Single JAR with all the libs? - rejar the distrib ...
Attached is an incomplete attempt at building the jar. I don't have time to figure out how to convert the fileset into the space delimited list of files needed for the classpath attribute. -- Robert - Original Message - From: Robert Simmons [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Sunday, January 26, 2003 11:56 PM Subject: Re: Single JAR with all the libs? - rejar the distrib ... Incidentally you should probably index that jar since it will have lots of classes and make the classloader throw fits trying to find things. Performance wise its best to index. - Original Message - From: Robert Simmons [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Sunday, January 26, 2003 11:55 PM Subject: Re: Single JAR with all the libs? - rejar the distrib ... Actually there is another option. Package all of the jars into a jar so that the contents of that jar are all of the files. Then alter the manifest of the containing jar (cocoon-all.jar) and add a Class-Path attribute with the names of each of the sub jars. Now putting the cocoon-all.jar in the path will cause them all to be in the classpath. ie: cocoon-all.jar -- META-INF/MANIFEST.MF -- avalon-framework-20020627.jar -- batik-all-1.5b2.jar -- bsf-2.2.jar -- (etc ...) MANIFEST.MF Created-By: Cocoon Developer Comittee. Class-Path: avalon-framework-20020627.jar batik-all-1.5b2.jar bsf-2.2.jar (etc ...) Viola .. one large jar containing many small jars. This would take a comitter with good knowledge of the build.xml abotu 10 min to implement. Make it 20 to test it. :) -- Robert - Original Message - From: SAXESS - Hussayn Dabbous [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Sunday, January 26, 2003 1:43 PM Subject: Re: Single JAR with all the libs? - rejar the distrib ... If i understand you correct, you simply want to avoid deploying several cocoon-based webapps all containing tons of the same jar files ? And in order to keep your customers happy, you want to simplify the deployment by bundling all cocoon jars into one big jar, deploying this golfball.jar independently from cocoon into your appserver? Then your webapps get significantly smaller because you only have to deploy the cocoon configs and the webapp specifics ...? If this is what you want, you can do it in two ways: WAY I - this is a very simplistic approach with some caveats, but it works. There may be a license problem here, but i don't know this for shure: 1.) unwar your cocoon distribution to any convenient place 2.) go to the WEB-INF/lib directory 3.) Now for each jarfile in the directory simply do: jar xf thefile.jar Of course you may skip all jars you dont need for your distribution ... 4.) throw away the .jar files 5.) jar cf golfball.jar * Now you have one single jar file, that you can distribute to whereever your container needs it to serve as common cocoon classes for your webapps. Finally you could repack the cocoon.war from step 1.) without the lib/*.jar files, add your webapp specific data (config/files/ programs) and deploy the result as co-webapps into your container ... But you have to keep one caveat in your mind: You may fall into strongly hidden compatibility issues when your webapps use other versions of the .jar modules you just have bundled to allclasses.jar If you take the single jars as they are, at least you can easier track down which module (.jar file) causes compatibility issues. And you can easier exchanche module jars if needed although i must admit, sometimes exchanging one jar out of a bunch may not be trivial at all ;-) The golfball.jar only allows to determine, which classes cause problems. WAY II -- If you are under unix, you can reach your goal by clever use of softlinks. In my development environment we sometimes have to run 5 to 10 cocoon-based webapps all across multiple platforms, multiple containers and so on. And we found a nice solution, that fits for our purposes. If this is something, anyone would be interested in, we could share knowledge here, but since this is kind of special i wouldn't bother this list and do this offline. just drop me an email. regards, hussayn hope, that helps Robert Simmons wrote: Is there a way to compress all the cocoon jars into one jar so I can just drop in my application server like a golf ball and all cocoon deployments will have access to it ? -- Robert -- Dr. Hussayn Dabbous SAXESS Software Design GmbH Neuenhöfer Allee 125 50935 Köln Telefon: +49-221-56011-0 Fax: +49-221-56011-20 E-Mail: [EMAIL PROTECTED] - Please
Re: Cocoon 2.1 the usability release?
One other feature would be more extensive documentation in the API. To see what I mean, look at the class level documentation on LinkSerializer. Hrmm ... I still don't know what it does. Perhaps its time to bust people's chops to document things. What I meant about the component documentation, by the way, is basically what is listed if you look at the package page in the API for the various components. -- Robert - Original Message - From: Robert Simmons To: Cocoon Users Sent: Monday, January 27, 2003 12:23 AM Subject: Cocoon 2.1 the usability release? Given the recent discussion about the difficulty getting into cocoon, I am wondering if we should start an initiative to make a maintenance release for cocoon that would have a focus on usability for new users. The following is a list of features I propose for this release. 1) A binary distribution stripped of all examples and documentation. This distribution would have only a single static XML and XSL file in a subdirectory called welcome that would be set up as a welcome page. The main sitemap file in the cocoon root directory would have anything not needed to serve this page as HTML commented out or removed. It would contain the mount only for that part of the site. 2) A all of the jars are filed into a single containing jar called cocoon-all.jar and placed in the WEB-INF/lib directory. This should remove "jar shock" from the users new to the system while retaining the modularity. A user can always unpack the cocoon-all.jar or replace a jar in the file if he chooses. 3) A new jar called cocoon-ext.jar. This jar would contain only the needed classes for compiling extensions (such as generators) to cocoon. It would be for users to mount in their development IDEs instead of having to mount the entire cocoon-all.jar. In the distribution, a new directory called dev-libs would be created and this jar would be placed in there. 4) All properties and xconf files that the user doesn't need to routinely edit would be packed into the cocoon-all.jar. The code loading these files would be adapted so that if a user chooses to provide his own xconf files (at his own risk), he can do so. Perhaps the code looks for custom-cocoon.xconf in the classpath and if it doesn't find it, then it loads the default one in the cocoon-all.jar. 5) Creation of all of these parts would be in the build.xml file, perhaps we can use the target name "golfball" for building the whole cocoon-all.jar. *smirk* 6) Providing both the full documented kitchen sink as well as the stripped jar for binary distribution download. Features id like to see: a) Replacing logikit with Log4j. Log4j is by far the most widespread of the logging packages used today and users will typically want to have all of their logging functioning in one product. That way a network admin can use a Log4j viewer tool to monitor the health of the system instead of needing to parse several logs. b) A reference manual on all the included generators, actions,serializers and so on:and what they do. The target audience for this is the sitemap developer who just wants to wire together pipelines. b) Reorganization of the documentation to allow a more coherent approach to learning cocoon. Starting with including basic newbie guides to get hello-world up in 15 minutes or less. Users that can get it working fast get excited and go further and faster. Its the hook that draws them in. Keep in mind I am coming from a usability point only. My basic premise is that newbies coming here will mostly not have the tenaciousness that I do and will be under deadline guns. Hooking them on cocoon by getting them in the door can only be good for the project and its technology. -- Robert
URI of the Sitemap Schema?
Greetings, Is there a uri for a sitemap schema that users can use to validate the sitemap during development ? If so, Id like to have it. TIA -- Robert
Re: Cocoon is complex, HOLD ON, WHY IS THIS BOILING UP ?
We might consider smacking the developers around to start commenting things. Pretend you are writing generator for the first time and you are looking at the API documentation for documentation on what the parameters are to the AbstractGenerator.setup() method. After you are done looking at the 0 documentation there, look around and you will see that the API is very badly commented, if at all. -- Robert - Original Message - From: Derek Hohls To: [EMAIL PROTECTED] Sent: Monday, January 27, 2003 8:10 AM Subject: Re: Cocoon is complex, HOLD ON, WHY IS THIS BOILING UP ? stop-lurking Hussayn is absolutely right here - there is a huge case that has built up over the last year for givinga "newbie-friendly" face to Cocoon. We can go on for hours (and have, before) about power and scalability and performance and XSLT issues etc etc etc BUT all of those things should flow on *after* starting with Cocoon and NOT be part of the sales pitch. I am not saying Cocoon should try and be all things to all people... but there is clearly starting to be enough people who have picked up on the increased publicity around Cocoon and want to "give it a try" - for the most part their needs are simple and so their "getting" started path should be as well... IF we want to keep these users in the community (if only asusers ;-) THEN there is a very strong case to get a section of the website devoted solely with a newbie in mind (maybe once it is designed we can eat some humble pie and go back to ask some of the previously critical newbies to crit it for us) - ideally this should be quite separate from the main site [with an equivalent "DONT PANIC" sign pointing clearly to it from the index page]. Everything on that subsite should be geared towards a promise of "3 hours (or whatever time frame seems reasonable) until your first app" type of message.Work? Of course, but, maybe not as much as we think - all the bits and pieces are there (some on wiki, some on mailing list, some on main site) but just need to be assembled with thought and care (eg. no confusing links to obsure and non-relevant pages on the main site etc). Benefits? An influx of "new blood" and, maybe (dare I say it) some converts from the jsp/.net/php camps. Is xml/xsl really dead (as has been suggested)? If we don't think so it should really be possible to demonstrate this in a straightforward way! My 2c for the bonfire. Derek PS And yes, I am willing to help with testing and critical review of docs andinstalling etc - and, once it looks reasonable, willing to coerce 2 of my newbie colleagues, who have previously expressed interest in Cocoon, to try it out "cold". /stop-lurking [EMAIL PROTECTED] 26/01/2003 01:49:53 I wonder why sometimes when it comes to criticism of cocoonthe arguments fly higher and higher until someone getsreally pissed of and angry ...And why is it so many times a newbie who becomes the centerof this game ? (Also one of my first newbie questions boiledup beyond the limits, but i'm still there ...)Please dont missunderstand me. In general i think the comunitytakes care of many many questions and very valuable informationis flowing around, but we also should take special care about anystrong criticism on cocoon. And especially the newbies can giveso valuable insight, even if they seem to be ignorant (theyaren't ignorant at all. They are new to this !!!)Maybe we should calm down a bit and take this thread reallyserious. It contains much of material to think about.And in many senses the criticism here can't be discussedaway.regards, hussayn-- Dr. Hussayn DabbousSAXESS Software Design GmbHNeuenhöfer Allee 12550935 KölnTelefon: +49-221-56011-0Fax: +49-221-56011-20E-Mail: [EMAIL PROTECTED]-Please check that your question has not already been answered in theFAQ before posting. http://xml.apache.org/cocoon/faq/index.htmlTo unsubscribe, e-mail: [EMAIL PROTECTED]For additional commands, e-mail: [EMAIL PROTECTED]-- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. "The CSIR exercises no editorial control over E-mail messages and/or attachments thereto/links referred to therein originating in the organisation and the views in this message/attachments thereto are therefore not necessarily those of the CSIR and/or its employees. The sender of this e-mail is, moreover, in terms of the CSIR's Conditions of Service, subject to compliance with the CSIR's internal E-mail and Internet Policy."
Getting a generator class to reload.
I am working to create a custom generator and I have deployed my WAR in exploded format. The problem is that now when I change the class file that the generator uses, cocoon keeps using the old class file. How can I get the classloader in cocoon to reload the class? -- Robert
Re: Getting a generator class to reload.
Nope .. didn't work. Still has the old class cached. I hope I don have to redeploy the whole damn thing every time I update a class. -- Robert - Original Message - From: Niclas Hedhman [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, January 27, 2003 9:20 AM Subject: Re: Getting a generator class to reload. On Monday 27 January 2003 16:21, Robert Simmons wrote: I am working to create a custom generator and I have deployed my WAR in exploded format. The problem is that now when I change the class file that the generator uses, cocoon keeps using the old class file. How can I get the classloader in cocoon to reload the class? When that happens, I touch the sitemap. Always works. - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Getting a generator class to reload.
Hmm ... never needed to mess with tomcat settings before ... I will look around. Since tomcat is bundled with JBoss, I don't know were this stuff would be. -- Robert - Original Message - From: Luca Morandini [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, January 27, 2003 9:31 AM Subject: RE: Getting a generator class to reload. Robert, I guess you've alread set the reloadable=true in the context element of your Tomcat configuration (or something to that effect in the servlet container of choice), haven't you ? Regards, - Luca Morandini GIS Consultant [EMAIL PROTECTED] http://utenti.tripod.it/lmorandini/index.html - -Original Message- From: Robert Simmons [mailto:[EMAIL PROTECTED]] Sent: Monday, January 27, 2003 9:21 AM To: Cocoon Users Subject: Getting a generator class to reload. I am working to create a custom generator and I have deployed my WAR in exploded format. The problem is that now when I change the class file that the generator uses, cocoon keeps using the old class file. How can I get the classloader in cocoon to reload the class? -- Robert - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Getting a generator class to reload.
Hmm, well I'm running tomcat merges with JBoss so its probably a different story here. I'm not even sure I can get to the tomcat reload mechanism. I tried the link the user posted on my machine and it didn't go. Additionally, I don't even want the entire cocoon app to restart when I change one generator class. That's what I was trying to avoid by having an exploded war. If I wanted it to reload every time, Id deploy an unexploded war. I just want cocoon to reload this particular class. -- Robert - Original Message - From: SAXESS - Hussayn Dabbous [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, January 27, 2003 10:13 AM Subject: Re: Getting a generator class to reload. Assuming you run tomcat: When you enable reloadable='true' in your Context the whole webapp should restart every time a class is changed. Once in a while i get unpredictable behaviour like webapp doesnt restart, or hangs during restart or even VM exits. I never figured out, what my container complains about, but in general i'm happy with reloadable='true' during development. For production it would be a very bad idea to enable this feature ;-) I heard rumours about the possibility with tomcat to only reload the changed resources while keeping the webapp up and running, but i never found the howto... regards, hussayn Robert Simmons wrote: Nope .. didn't work. Still has the old class cached. I hope I don have to redeploy the whole damn thing every time I update a class. -- Robert - Original Message - From: Niclas Hedhman [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, January 27, 2003 9:20 AM Subject: Re: Getting a generator class to reload. On Monday 27 January 2003 16:21, Robert Simmons wrote: I am working to create a custom generator and I have deployed my WAR in exploded format. The problem is that now when I change the class file that the generator uses, cocoon keeps using the old class file. How can I get the classloader in cocoon to reload the class? When that happens, I touch the sitemap. Always works. - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Dr. Hussayn Dabbous SAXESS Software Design GmbH Neuenhöfer Allee 125 50935 Köln Telefon: +49-221-56011-0 Fax: +49-221-56011-20 E-Mail: [EMAIL PROTECTED] - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Cocoon 2.1 the usability release?
Oh well, I don't mean to be caustic but developers that work for me that don't document get yelled at allot. I don't tolerate it. Its quite easy to javadoc as you go and a massive pain in the ass to do it after the fact. With the lack of documentation though, it does make one wonder what is lurking in there that isn't needed anymore. But then I still think a usability focused release would be a good thing. Hell, Id be willing to do the Log4j conversion when I get done with my current project. -- Robert - Original Message - From: Jeff Turner [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, January 27, 2003 1:00 PM Subject: Re: Cocoon 2.1 the usability release? On Mon, Jan 27, 2003 at 01:28:30AM +0100, Robert Simmons wrote: One other feature would be more extensive documentation in the API. To see what I mean, look at the class level documentation on LinkSerializer. Hrmm ... I still don't know what it does. Perhaps its time to bust people's chops to document things. I'm glad to see you consider good documentation a priority. I have commit access to the relevant repositories, and I am willing to document anything you like for a very reasonable $A10/class. Please contact me offlist for further information. Of course... I ASSUME you'd be willing to pay someone, because how else could you get volunteers to scratch YOUR particular itch? :) --Jeff What I meant about the component documentation, by the way, is basically what is listed if you look at the package page in the API for the various components. -- Robert ... - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Cocoon User Meeting - Wuerzburg - Germany
I currently live in Munich and I believe in this technology enough to consider beating it in the head until its user friendly. =) After I get my book done (almost damnit!!!) I will be volunteering to work on some usability stuff if they will have me. -- Robert - Original Message - From: Michael Mertel [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, January 27, 2003 9:46 AM Subject: Cocoon User Meeting - Wuerzburg - Germany Hi there, are there any cocoon users in the wuerzburg area to meet on a regular/nonregular base ... we can provide the space for up to 10-15 people. Beginners (like me) and advanced users are more than welcome. If this sounds good to anyone, please drop me a note at [EMAIL PROTECTED] Sorry for bothering all the other cocoon users around, but thats currently all what I can give back to the community. --Michael - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: newbies documentation - yet another wiki?
What I don't get is why not put the new documentation in cocoon distribution? Everything else is in there: *smirk* Cocoon is built for web publishing, we could conspire to write volumes right in the product. Which reminds me, anyone know a word processor that saves primarily in XML and is good? -- Robert - Original Message - From: Bertrand Delacretaz [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, January 27, 2003 10:14 AM Subject: Re: newbies documentation - yet another wiki? Hi Hussayn, I mostly agree with your point of view, except on the separate wiki thing. (And by the way, thanks a lot for your less talking, more doing approach!) What worries me *a lot* with starting yet another documentation site is the dispersion of resources - wouldn't it be much more efficient to have you, Derek and possibly others joing the (mythical) Cocoon docs team with the aim of creating these newbies docs? See also http://wiki.cocoondev.org/Wiki.jsp?page=CocoonDocsPlan, I think your concept can fit nicely into this. I'm convinced that it is possible to create the newbies competence center that you mention *inside* the existing wiki - a well-designed start page and navigation should help newbies find their way. Maybe this needs some improvements to the existing wiki system, to help newbies find pages that are targeted for them, namely: a) Being able to search the wiki for NCC pages only or everything so that newbies are not distracted by deep technical discussions. b) Being able to clearly label pages as being part of the NCC, different color, icons or something. This might well be possible with JSPwiki, maybe by writing some kind of extension? We need to ask Steven or the JSPWiki folks if you think this is worth studying. What do you think? Join the party, or throw yet another one? :-) -Bertrand - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Single JAR with all the libs?
Does anyone know how, in Ant, to take a fileset and convert it to a space delimited list of files? -- Robert - Original Message - From: Luca Morandini [EMAIL PROTECTED] To: Cocoon-users [EMAIL PROTECTED] Sent: Sunday, January 26, 2003 10:45 AM Subject: RE: Single JAR with all the libs? Robert, well, if I were you I'd tweak the build.xml to tailor it to your needs, and just tell the readers to: 1) replace the native build.xml with yours 2) run it 3) deploy the resulting WAR. I have no idea of alternative approaches... sorry :( Regards, - Luca Morandini GIS Consultant [EMAIL PROTECTED] http://utenti.tripod.it/lmorandini/index.html - -Original Message- From: Robert Simmons [mailto:[EMAIL PROTECTED]] Sent: Sunday, January 26, 2003 9:57 AM To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: Single JAR with all the libs? Ya I know that. I'm not talking about the prebuilt, distributed web application. I am trying to develop a strategy for other users to be able to use cocoon from within JBoss without having to leap through 15 hoops. So I basically want a way I can build cocoon libs and then in each war file I make that uses cocoon, I merely need the config files and only things pertaining to my stuff and not to cocoon in general. Getting the kitchen sink build working was a matter of just dropping it in JBoss. Now I want to go further and make other applications with the product. Right now Id have to resort to telling readers to download cocoon, unpack it, rewrite their manifests to include the Cocoon-Libs section, then run the build which should convert the old libs to the new location and then install cocoon. Picture this scenario. You want to use cocoon for a front end to a powerful EJB based system. Your readers of your book want to download your source code and install it and get it running. They need a simple process. Right now the process is download the kitchen sink version, figure out what the hell you don't need, repack everything and deploy it. Not functional for users of the product. Therefore I keep rolling back around to having a single jar that I can drop in JBoss like an oversized golf ball and call cocoon installed and ready for users to deploy their OWN war files that use cocoon rather than asking them to modify cocoon's war. I'm not sure if I'm making sense here. -- Robert - Original Message - From: Luca Morandini [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Sunday, January 26, 2003 9:41 AM Subject: RE: Single JAR with all the libs? Robert, I'm not sure I've understood your question, but I like to give it a try. When you build Cocoon, it produces a WAR file, you just: 1) put the WAR under the webapps of your servlet container 2) re-start the container The you can deploy your Cocoon app under the mount directory, hence avoid editing the general sitemap.xmap (the one in webapps/cocoon). Regards, - Luca Morandini GIS Consultant [EMAIL PROTECTED] http://utenti.tripod.it/lmorandini/index.html - -Original Message- From: Robert Simmons [mailto:[EMAIL PROTECTED]] Sent: Sunday, January 26, 2003 9:07 AM To: Cocoon Users Subject: Single JAR with all the libs? Is there a way to compress all the cocoon jars into one jar so I can just drop in my application server like a golf ball and all cocoon deployments will have access to it ? -- Robert - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OT] Re: Single JAR with all the libs?
Ya I looked at that .. the problem is that I don't want the directories that they are coming from, just the file names. -- Robert - Original Message - From: Jeff Turner [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, January 27, 2003 1:33 PM Subject: [OT] Re: Single JAR with all the libs? On Mon, Jan 27, 2003 at 01:17:07PM +0100, Robert Simmons wrote: Does anyone know how, in Ant, to take a fileset and convert it to a space delimited list of files? Something like: pathconvert property=list dirsep= path refid=... /pathconvert --Jeff -- Robert - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: newbies documentation - yet another wiki?
Ya, I know MSoffice can save into HTML. I want it to save into XML. -- Robert - Original Message - From: Emmanuil Batsis (Manos) [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, January 27, 2003 1:31 PM Subject: Re: newbies documentation - yet another wiki? Star/OpenOffice as well as the new MSOffice. Then again, WYSIWYG HTML Editors - Tidy works great too. Manos Robert Simmons wrote: What I don't get is why not put the new documentation in cocoon distribution? Everything else is in there: *smirk* Cocoon is built for web publishing, we could conspire to write volumes right in the product. Which reminds me, anyone know a word processor that saves primarily in XML and is good? -- Robert - Original Message - From: Bertrand Delacretaz [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, January 27, 2003 10:14 AM Subject: Re: newbies documentation - yet another wiki? Hi Hussayn, I mostly agree with your point of view, except on the separate wiki thing. (And by the way, thanks a lot for your less talking, more doing approach!) What worries me *a lot* with starting yet another documentation site is the dispersion of resources - wouldn't it be much more efficient to have you, Derek and possibly others joing the (mythical) Cocoon docs team with the aim of creating these newbies docs? See also http://wiki.cocoondev.org/Wiki.jsp?page=CocoonDocsPlan, I think your concept can fit nicely into this. I'm convinced that it is possible to create the newbies competence center that you mention *inside* the existing wiki - a well-designed start page and navigation should help newbies find their way. Maybe this needs some improvements to the existing wiki system, to help newbies find pages that are targeted for them, namely: a) Being able to search the wiki for NCC pages only or everything so that newbies are not distracted by deep technical discussions. b) Being able to clearly label pages as being part of the NCC, different color, icons or something. This might well be possible with JSPwiki, maybe by writing some kind of extension? We need to ask Steven or the JSPWiki folks if you think this is worth studying. What do you think? Join the party, or throw yet another one? :-) -Bertrand - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Fantastic!!!! My first Generator that connects to an EJB.
This sucker connects to an EJB which runs the given JDO query and returns the set of found objects from the database. Best of all it works See the two attached files. Next thing you know I will be writing something useful. O_O -- Robert SmileyAdminView.java Description: Binary data GeneratorBase.java Description: Binary data - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: newbies documentation - yet another wiki?
Nice software. Too bad I don't have a thousand Euros to blow to buy it. -- Robert - Original Message - From: SAXESS - Hussayn Dabbous [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, January 27, 2003 1:37 PM Subject: Re: newbies documentation - yet another wiki? i personally enjoy XML-SPY, although it's tied to MS... regards, hussayn Robert Simmons wrote: Ya, I know MSoffice can save into HTML. I want it to save into XML. -- Robert - Original Message - From: Emmanuil Batsis (Manos) [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, January 27, 2003 1:31 PM Subject: Re: newbies documentation - yet another wiki? Star/OpenOffice as well as the new MSOffice. Then again, WYSIWYG HTML Editors - Tidy works great too. Manos Robert Simmons wrote: What I don't get is why not put the new documentation in cocoon distribution? Everything else is in there: *smirk* Cocoon is built for web publishing, we could conspire to write volumes right in the product. Which reminds me, anyone know a word processor that saves primarily in XML and is good? -- Robert - Original Message - From: Bertrand Delacretaz [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, January 27, 2003 10:14 AM Subject: Re: newbies documentation - yet another wiki? Hi Hussayn, I mostly agree with your point of view, except on the separate wiki thing. (And by the way, thanks a lot for your less talking, more doing approach!) What worries me *a lot* with starting yet another documentation site is the dispersion of resources - wouldn't it be much more efficient to have you, Derek and possibly others joing the (mythical) Cocoon docs team with the aim of creating these newbies docs? See also http://wiki.cocoondev.org/Wiki.jsp?page=CocoonDocsPlan, I think your concept can fit nicely into this. I'm convinced that it is possible to create the newbies competence center that you mention *inside* the existing wiki - a well-designed start page and navigation should help newbies find their way. Maybe this needs some improvements to the existing wiki system, to help newbies find pages that are targeted for them, namely: a) Being able to search the wiki for NCC pages only or everything so that newbies are not distracted by deep technical discussions. b) Being able to clearly label pages as being part of the NCC, different color, icons or something. This might well be possible with JSPwiki, maybe by writing some kind of extension? We need to ask Steven or the JSPWiki folks if you think this is worth studying. What do you think? Join the party, or throw yet another one? :-) -Bertrand - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Dr. Hussayn Dabbous SAXESS Software Design GmbH Neuenhöfer Allee 125 50935 Köln Telefon: +49-221-56011-0 Fax: +49-221-56011-20 E-Mail: [EMAIL PROTECTED] - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: proposal: The Newbies Competence Center
In my opinion cocoon needs to start architecting itself towards four types of cocoon consumers: Presentation Developer: This person uses editors to define style sheets for transforming data into presentation layers. This user should not be concerned with the extension mechanism of cocoon. In a real company, this user would be a graphic designer. Should this user need some special kind of transformation, they would ask the next a Content Developer. Administrator: This person is responsible for maintaining the health of the cocoon instance. This user would typically be a network engineer at a company. They should have functionality to track throughput and performance and get an idea of the kind of volume being handled by cocoon via some statistics pages. Content Developer: Data is the prime responsibility for the content developer. He builds data engines using custom generator classes, static XML and various other mechanisms of cocoon. This user is served by a programmer in a company. The developer Is concerned only with the interface to cocoon and not with any of the internals. He doesn't need to know why things work, he just needs to know that if he implements interface x and generates content via sax events, then cocoon magically spits out his XML. Cocoon Developer: This is a consumer that is concerned with altering the cocoon distribution. This person has varying levels of knowledge of the internals of cocoon and seeks to contribute to the general product via commits to CVS. --- To accomplish this we need, IMHO, to implement a few things in cocoon. The suggestions are annotated with the target roles indicated below their title. it is for these target roles that we do the task. Document the API: For (Cocoon Developer, Content Developer) Developers of cocoon should go through the entire API and document it. Using a tool like Jalopy, all of the source code can be formatted to standards set in the jalopy options. For each entry that is not documented, a todo list can be generated and worked through to remove all of the todo tag entries. Cocoon can be used to parse the javadoc files and, using XSLT, extract all of the todo entries. This would give the consumers the ability to use the API more effectively. Abstract Out References to third party libraries: (Cocoon Developer) Anytime the Cocoon Developer needs to build a new custom extension to cocoon, he should have to only import the cocoon.jar file into his classpath to compile. All of these interfaces will then be documented in one API document set for easy consumption. This would be accomplished by identifying all entry points and facading them with interfaces. So the avalon request object would instead be org.apache.cocoon.api.Request. The user deals only with the interfaces and not with anything internal. Convert logging to use Log4j: (Administrator, Content Developer, Cocoon Developer) This would involve converting Logikit logging to Log4j logging mechanisms. Although pervasive throughout the code, the changes are mostly a bunch of search and replace activities. It can hardly be denied that Log4j has won the Java logging market. There are already a number of professional tools used for viewing Log4j output. Such tools as those used in consuming JMS logging events are used by network engineers all over to monitor health of the system. There is little point trying to fight the tide. Making Cocoon use Log4j would have the advantage of allowing these network admins to configure single Log4j property files for their whole platform. Build documentation specifically targeted at each user role: (all) This documentation should include getting started guides for all four types of users and varying levels of tutorials. For instance Presentation Developers might get a tutorial on XSL and XML. Content Developers would get current tutorials such as making your own generator and introduction to forms in XSL. In addition, other tutorials such as the sitemap tutorial would be common to all roles. This documentation should be sectioned appropriate to the roles. Create a distribution stripped of every example except a single XML-XSL transform welcome page for use as a starter point. (Content Developer) Change the Libs format: (Content Developer) The libs should all be packaged into one big jar containing each of the other library jars. This library would contain a classpath for each of the entries in the big jar file. This would hide internals from the cocoon developers. A new jar called cocoon-ext.jar. (Content Developer) This jar would contain only the needed classes for compiling extensions (such as generators) to cocoon. It would be for users to mount in their development IDEs instead of having to mount the entire cocoon-all.jar. In the distribution, a new directory called dev-libs would be created and this jar would be placed in there. All properties and xconf files that the user doesn't need to routinely edit would be
Re: Cocoon Job opps in Frankfurt, Germany
Strange that I did a search on gulp.de and monster.de for Cocoon and came up empty. Where are you guys hearing about these contracts? -- Robert - Original Message - From: Jeremy Aston [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, January 28, 2003 3:32 PM Subject: RE: Cocoon Job opps in Frankfurt, Germany The UK rate has dropped significantly. You are really looking at something like £35-£40 per hour (as opposed to £60-£70 ph in the past couple of years. $500ph is v. reasonable. At the end of the day these angencies never put a rate since they want to get as good a person as cheap as possible! jez -Original Message- From: Niclas Hedhman [mailto:[EMAIL PROTECTED]] Sent: 28 January 2003 05:13 To: [EMAIL PROTECTED] Subject: Re: Cocoon Job opps in Frankfurt, Germany On Tuesday 28 January 2003 09:20, Jeremy Aston wrote: Hi, I keep seeing ads for contractors based in Frankfurt on a UK based job site... http://www.it.jobserve.com/jobserve/searchresults.asp?jobType=*d= 5order=R a nkpage=1q=cocoon They almost all list Rate: Market. What is that roughly? Just curious what it pays to be employed nowadays in this kind of field... Anyone willing to reveal? Me? I live in the low cost country so I charge only(?) around $500 per day, as consultant. Niclas I have tried to get in there as a UK based person (and Cocooon book co-author) but the company are 100% set on having an on site person and no remote workers/software houses/cooperatives. I can't move to Germany so am out of the picture - bah! These people have advertised reguarly over the past 4-6 months so the work must be ongoing. If anyone does get in there and find they can put in a word for remote workers (I will go to a couple of times a month for a couple of days) then I'm here! rgds Jeremy - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do You Yahoo!? Everything you'll ever need on one web page from News and Sport to Email and Music Charts http://uk.my.yahoo.com - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How to open 2 windows?
Just a warning. There has been a study recently that quite well confirms that using popups in a commercial web site is a good way to drive traffic AWAY from that site. Personally, they annoy the shit out of me. If I really needed to get my penis enlarged Id look it up on google.de. Getting offered it from half the web sites on the internet could be bad for self confidence. =) -- Robert - Original Message - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, January 28, 2003 10:27 AM Subject: How to open 2 windows? Hi, I want to open 2 windows on one event. The xml/xsp (I mean the data) would be the same, but the output would be: first window html, second window pdf. e.g. my dummy sitemap: ... !-- on submit generate *.html and *.pdf output -- map:match pattern=html-pdf map:generate type=serverpages src=html-pdf.xsp/ !-- generate a window with html output map:transform src=html.xsl/ map:serialize -- !-- generate another window with pdf output map:transform src=pdf.xsl/ map:serialize type=fo2pdf/ -- /map:match How can I manage this? Can I mange this from my sitemap? Cheers Jonny --- - This electronic message contains information from the mmo2 plc Group which may be privileged or confidential. The information is intended to be for the use of the individual(s) or entity named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information is prohibited. If you have received this electronic message in error, please notify us by telephone or email (to the numbers or address above) immediately. - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: IDE for cocoon
Well I don't have money to buy any tools. Usually I have to get companies to
buy them. However as a suggestion, fi you are trying to get more customers,
Id investigate a way to integrate your concepts with open platforms like
NetBeans or eclipse. Breaking people off from their normal IDEs is tough.
Getting them to add new functionality to them is much easier.
-- Robert
- Original Message -
From: Alexandru COSTIN [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Tuesday, January 28, 2003 9:52 AM
Subject: RE: IDE for cocoon
Hello,
We have a very powerful IDE called KrysalIDE especially designed to
understand the concept of XSP, taglibs and pipelines.
It already provides some interesting features for our Cocoon clone -
Krysalis, and we are considering porting it to coocon if there will be
enough interest. (it is a commercial product)
See more about KrysalIDE at http://www.interakt.ro/products/KrysalIDE/
We have tag completion capability for any taglib and for XSLs, visual
link between XML and XSL, etc,
Alexandru
On Wed, 2003-01-22 at 17:38, Geoff Howard wrote:
While we're talking about sunbow, are there any plans to provide some
kind
of support for xsp/xml editing? Maybe I haven't found the right settings
or
external plugins yet but xml editing doesn't seem very rich. Jedit at
least
has some tag completion capability etc.
Have I missed something?
Geoff
-Original Message-
From: Matthew Langham [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, January 22, 2003 9:34 AM
To: [EMAIL PROTECTED]
Subject: RE: IDE for cocoon
Hi,
the current free version of sunBow will remain free. At the moment we
require a licence key (because we originally thought this a good idea)
and
have not yet got round to removing the dependency.
Hopefully we will find some time to do that...but until then :-).
Matthew
--
Open Source Group Cocoon { Consulting, Training, Projects }
=
Matthew Langham, SN AG, Klingenderstrasse 5, D-33100 Paderborn
Tel:+49-5251-1581-30 [EMAIL PROTECTED] - http://www.s-und-n.de
-
Cocoon book:
http://www.amazon.com/exec/obidos/ASIN/0735712352/needacake-20
Weblogs:
http://radio.weblogs.com/0103021/
http://www.oreillynet.com/weblogs/author/1014
=
-Original Message-
From: Jordi Valldaura [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, January 22, 2003 3:27 PM
To: [EMAIL PROTECTED]
Subject: Re: IDE for cocoon
Hello,
I agree with u that eclipse is a very good ide. But the sunbow
plug in needs
a registration
key, I know they give it freely now but I don't think they will
do it in the
future.
- Original Message -
From: Geoff Howard [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Wednesday, January 22, 2003 2:27 PM
Subject: RE: IDE for cocoon
I've recently started using eclipse and have been very impressed.
The
information it provides helps make sense of what can seem like
a rats nest
of dependencies. I have brought in avalon and avalon-excalibur as
projects
alongside cocoon and my own cocoon-based projects which has been very
helpful in tracking down information that crosses the border
between the
projects.
All of that would be true with any good IDE, but this one's free and
has
the
added benefit of the sunBow stuff.
Hope that helps,
Geoff
-Original Message-
From: Martin Dulisch [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, January 22, 2003 4:20 AM
To: [EMAIL PROTECTED]
Subject: Re: IDE for cocoon
Hi Reza,
sunBow is a plugin for eclipse (www.eclipse.org). It contributes
some
Cocoon/XML/XSLT features to eclipse. You can find the download and
documentation here: http://radio.weblogs.com/0108489/
Martin
- Original Message -
From: Reza Aliakbari [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Wednesday, January 22, 2003 10:11 AM
Subject: IDE for cocoon
Dears,
I am new in cocoon.
I need some tools and IDE for cocoon.
Also I am waiting for any advise that could be useful for new
cocoon
developers.
Thanks,
Reza.
-
Please check that your question has not already been answered in
the
FAQ before posting.
http://xml.apache.org/cocoon/faq/index.html
To unsubscribe, e-mail:
[EMAIL PROTECTED]
For additional commands, e-mail:
[EMAIL PROTECTED]
-
Please check
Re: proposal: The Newbies Competence Center
Id be happy to write up some stuff on connecting to EJB servers now that I have actually figured out how to do it. -- Robert - Original Message - From: Niclas Hedhman [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, January 28, 2003 8:02 AM Subject: Re: proposal: The Newbies Competence Center On Tuesday 28 January 2003 15:00, Derek Hohls wrote: The First Steps chapter listed below is the one that needs some thought and attention. My feeling is that we need to focus on the problems that needs to be solved, rather than a lengthy description of what is *possible* with Cocoon. Good point! If that is also made from the background of user aspect, so that; You know XML/XSL and want to publish static content - click here You are a DB developer who wants to expose XML data - click here You are Stefano Mazzocchi and want to - you are in the wrong area Base it on use cases and add 1 hour or less exercises. I assume that a pre-condition here is a suitable distro to start from. Niclas - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: proposal: The Newbies Competence Center
I don't think that the word newbie is such a stigma. People know when they are newbies and not. Rarely do people take it offensively unless its an outside person telling them that they are a newbie. In fact people can take it tongue in cheek as the for Dummies or Idiots guide to ... books show. Despite their tongue in cheek titles they are amazingly popular. However, the documentation we are proposing is not just targeted at newbies but eventually will span the spectrum of users. For this reason I think the title you proposed is the right one. As to using Wiki, I never have but I will state that id like the documentation to actually be served by cocoon. The benefits to that is the multi-content publishing framework at its best. Users can get PDFs or post script or any number of other types of content as well as the surfed content. What I would like to see now is a style guide for XML documents that will be common to all published cocoon info. In this manner we can apply a standard XSLT transform to all documents and the writers would just be using XML to accomplish the task. This would give us allot of flexibility. What I am talking about is a custom schema (or borrowed one) that all of the documentation authors can validate against and that the template authors can use to transform. Then I would suggest that the full cocoon samples and documentation be put through this framework. It would take some thought because you want the ability to have it referencable and indexable. For example, I should be able to create a sitemap entry that will combine all cocoon docs into one big page and transform it into PDF. Its always best if you start with architecture and start filling things in. -- Robert - Original Message - From: SAXESS - Hussayn Dabbous [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, January 28, 2003 11:48 AM Subject: Re: proposal: The Newbies Competence Center seems as if my round up generqted even more input ;-) thanks to all of you. so what do we have now? i reround up here: 1.) there is a strong push towards role based documentation 2.) there is a strong recommendation to use cocoon-wiki 3.) the discussion roles on over the whole documentation set hmm... seems so as if this gets a bigger task, than expected ;-) by the way, i looked up the word newbie. It may be of interst, that this is the short from of new boy. Hey, we can't do that ... I'd recommend to rename this to The Cocoon Competence Center and start with the beginners section on the cocoon wiki... any doubts ? regards, Hussayn Derek Hohls wrote: This is getting periously close to documentation ;-) Seriously, this is the kind of description that is incredibly useful to have up front - never mind arguing over who should have what skills and how they should work together ... that is a project/company issue and will differ from case-case (the current view is that most people are multi-skilled anyway) BUT we can all agree on what skills are needed to work with Cocoon and can link our documentation (see other mail on wiki classifications) to those skills; what Peter elsewhere has called role based documentation. It will be of great help to the new user to see what he/she might be expected to know (or learn) before getting up in the intricacies of sitemaps, generators and the rest of the jargon! [EMAIL PROTECTED] 27/01/2003 11:59:41 Tony Collen wrote: For instance, with a typical installation of Cocoon, we could define the following roles: - Content Creator. This person authors XML for the site to be transformed. This role works when most of the content is static. However, if a lot of the data is being pulled out of a database, they would be in charge of something like data entry into the database, etc. I've been seeing this role work out well in practice. There is grumbling when they can't mark up their content significantly like they used to in Frontpage or Dreamweaver, but after seeing a demo, they usually acquiesce. - Graphic/Web designer. This person is in charge of the style of the site. Not only do they come up with how the site looks through the design of the final HTML, but they also write the XSL to transform the content into the desired format. Sometimes this person is also the content creator. This role, however, falls apart quickly. There are three roles here and it's rare that any one person satisfies all of the roles successfully. 1) The graphic designer: The artist/production manager who is a whiz with Photoshop/Paint Shop Pro/The GIMP. They design the overall look and feel for the site. Anyone who has seen a good graphic artist can attest to the fact that not everyone can do the job. 2) The HTML/CSS web monkey (term of endearment -- not meant to offend): Can take the layout design from the graphic artist and turn it into clean and useable
Re: proposal: The Newbies Competence Center
Hmm .. where do I find this? -- Robert - Original Message - From: SAXESS - Hussayn Dabbous [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, January 28, 2003 3:49 PM Subject: Re: proposal: The Newbies Competence Center Hy, the Cocoon Competence Center is Born ;-) I have changed the link on the WIki leftMenu from new to cocoon? into For Beginners and added the cocoon in 15 minutes: page. I invented a first set of metadata: - TARGET-AUDIENCE: beginners - COCOON-RELEASES: 2.0.3, 2.0.4 - AUTHOR: Hussayn Dabbous - AUTHOR-CONTACT: [EMAIL PROTECTED] - REVIEWED-BY: - REVIEWER-CONTACT: Maybe this needs review. regards, hussayn -- Dr. Hussayn Dabbous SAXESS Software Design GmbH Neuenhöfer Allee 125 50935 Köln Telefon: +49-221-56011-0 Fax: +49-221-56011-20 E-Mail: [EMAIL PROTECTED] - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Preloading parts of cocoon.
Greetings. Whenever I change a page in my sitemap and redeploy, I notice that the first time I hit a page it takes cocoon a few seconds to start the page. Is there any way we can get cocoon to preprocess this stuff at deployment time so that the users only see instant results ? -- Robert
Re: proposal: The Newbies Competence Center
Incidentally, I find that when I hit the Wiki page, I don't see half of the left menu until I pass my mouse over the links. IE6 problem? -- Robert - Original Message - From: Derek Hohls To: [EMAIL PROTECTED] Sent: Tuesday, January 28, 2003 8:00 AM Subject: Re: proposal: "The Newbies Competence Center" I think that Miles' outline below reflects a very good way of organising the primary Cocoon site. I am not sure that it is completely appropriate for new users (yes, I still think there is a distinction between a user and a 'hard core' developer - see later replies). The "First Steps" chapter listed below is the one that needs some thought and attention. My feeling is that we need to focus on the problems that needs to be solved, rather than a lengthy description of what is *possible* with Cocoon. This should be difficult to draw up; there are many common problems for web developers and it should not be that hard to create some example solutions. Comes back to what I am comfortable with "learning by seeing and then doing"... the light of in-depth understanding usually dawns a little later on. [EMAIL PROTECTED] 27/01/2003 10:10:48 Tony Collen wrote:On Mon, 27 Jan 2003, SAXESS - Hussayn Dabbous wrote: o There was an idea to redesign the cocoon documentation entry page and provide chapters like: 1) First steps 2) User's Manual 3) User's Reference 4) Architecture 5) Developer's Guide This is good. HOWEVER, occasionally the line between "user" and"developer" gets blurred, especially when a user realizes they need todevelop a custom component.All too often, I've gone to the developer section looking for informationthat was actually in the user guide, and vice versa.I totally agree. In fact, this is an item that I took issue with in Lajos and Jeremy's book: which "Generators" section should I be looking in? I also don't know that a quick reference and a manual must be distinct items. For a printed book, this makes a lot of sense. But the web is inherently a quick reference -- bouncing from relevant topic to relevant topic. This is an area where I think the existing documentation (for some components) shines. If you take a look at the Request XSP logicsheet (http://xml.apache.org/cocoon/userdocs/xsp/request.html), this is an example of what I mean. If the page simply had quick, in-page links to description, usage, examples, and quick reference, you would be done. A user looking up information says, "Hmmm, I know I want to use a serializer so I'll go to the serializer section." From there, they can select if they want an example, an API lookup, etc. Quick references exist because no one wants to haul around five hundred page books. But if you are on the web, you already have access to a million page book. The same rules don't apply.However, I think the above list has merit if you clearly define what "development" is. I tend to think that *anyone* who installs Cocoon and edits something to be a developer rather than a user. The users, in my mind, are the folks using the web browser. There are, however, different classes of developer. For example, if you write an XSP document, you've in essense written a generator. No, they didn't call javac themselves, but it's only slightly different. The difference mainly lies in its relative ease, not in the intent. If you set up a pipeline in the sitemap, what are you if not a developer assembling components together?On the other hand, making changes to the Flow engine, the cache store, the sitemap parser, etc. are definitely different from writing your own transformer. The distinction in the documentation should be "here are things you can do for your own benefit that affect no one else" and "here are things that fundamentally affect the requirements for other components."For example:1) Architecture Overview/Primer/First Steps a) Why Cocoon exists b) Quick start installation c) Hello World (XSP document going through a simple transformer and serializing to HTML) d) Very brief introduction to sitemaps, generators, etc. by explaining Hello World2) The Cocoon servlet a) Installation instructions i) Tomcat ii) Jetty iii) JBoss iv) etc. b) Web app layout i) Configuration locations (logkit.xconf, cocoon.xconf, etc.) a. cocoon.xconf b. logkit.xconf c. etc. ii) Library locations and itemization a. lib b. classes iii) Other3) Architecture in depth a) Generators i) What they are and why they exist ii) Listing of existing generators, their usage, and examples iii) How to write a custom generator (with a reference to XSP) b) Transformers i) What they are and why they exist ii) Listing of existing transformers, their usage, and examples iii) How to write a custom transformer ...repeat this model for the other
XML - XSL Editors?
What are the best XML and XSLT editors on the market. I'm looking for something that is easy to use and offers the chance to edit XSL in a WYSIWYG style. I tried XML Spy but it is not so easy to use. I couldn't even figure out how to get an XSL preview to work properly. It wanted me to create an sps file in order to show the transformation but in their sps editor I couldn't even tell it to use a file that I had already written. Way weird. I also tried eXcelon with is much easier to use. I want to know what other options are out there. -- Robert
Re: Cocoon Job opps in Frankfurt, Germany
Interesting. Well I wouldn't have enough cocoon knowledge quite yet to do a contract in it. Perhaps in a couple more months of study. I'm getting decidedly sick of working for pennies for some stupid company more interested in politics than product. I'm seriously considering branching out into contracting when my book hits the market. -- Robert - Original Message - From: Jeremy Aston [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, January 29, 2003 1:33 AM Subject: RE: Cocoon Job opps in Frankfurt, Germany These roles come up on jobserve.com, a UK based service for recruitment agencies. I just have a savedsearch that emails me if Cocoon comes up as a keyword in each day's listings. If you follow the link below then you will note that all the agencies are UK based. It is possible the client is using agencies based in other European countries but Jobserve only really covers the UK and Australia based agencies. Of course many of the UK agencies have international sections, plus seeing as the role is in Frankfurt there is a good chance that the client may be an international org in the financial sector and thus might use UK based agencies by default. -Original Message- From: Robert Simmons [mailto:[EMAIL PROTECTED]] Sent: 28 January 2003 21:17 To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: Cocoon Job opps in Frankfurt, Germany Strange that I did a search on gulp.de and monster.de for Cocoon and came up empty. Where are you guys hearing about these contracts? -- Robert - Original Message - From: Jeremy Aston [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, January 28, 2003 3:32 PM Subject: RE: Cocoon Job opps in Frankfurt, Germany The UK rate has dropped significantly. You are really looking at something like £35-£40 per hour (as opposed to £60-£70 ph in the past couple of years. $500ph is v. reasonable. At the end of the day these angencies never put a rate since they want to get as good a person as cheap as possible! jez -Original Message- From: Niclas Hedhman [mailto:[EMAIL PROTECTED]] Sent: 28 January 2003 05:13 To: [EMAIL PROTECTED] Subject: Re: Cocoon Job opps in Frankfurt, Germany On Tuesday 28 January 2003 09:20, Jeremy Aston wrote: Hi, I keep seeing ads for contractors based in Frankfurt on a UK based job site... http://www.it.jobserve.com/jobserve/searchresults.asp?jobType=*d= 5order=R a nkpage=1q=cocoon They almost all list Rate: Market. What is that roughly? Just curious what it pays to be employed nowadays in this kind of field... Anyone willing to reveal? Me? I live in the low cost country so I charge only(?) around $500 per day, as consultant. Niclas I have tried to get in there as a UK based person (and Cocooon book co-author) but the company are 100% set on having an on site person and no remote workers/software houses/cooperatives. I can't move to Germany so am out of the picture - bah! These people have advertised reguarly over the past 4-6 months so the work must be ongoing. If anyone does get in there and find they can put in a word for remote workers (I will go to a couple of times a month for a couple of days) then I'm here! rgds Jeremy - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do You Yahoo!? Everything you'll ever need on one web page from News and Sport to Email and Music Charts http://uk.my.yahoo.com - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do You Yahoo!? Everything you'll ever need on one web page from News and Sport to Email and Music Charts http://uk.my.yahoo.com - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org
Re: XML - XSL Editors?
Hmm, well my book has very little to do with cocoon. Its an advanced java book. id be suprised if I mentioned more than a couple pages on cocoon. Basically the book will talk about various java enterprise programing and I will be using cocoon for the interface to the remote ejbs. -- Robert - Original Message - From: Antonio Gallardo [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, January 29, 2003 2:24 AM Subject: Re: XML - XSL Editors? Hey?! Maybe and this article can be usefull for you and your work on the book: http://community.jedit.org/modules.php?op=modloadname=newsfile=articlesid= 202 By the way, what is the name of your future book? Antonio Gallardo. Antonio Gallardo dijo: Robert Simmons dijo: What are the best XML and XSLT editors on the market. I'm looking for something that is easy to use and offers the chance to edit XSL in a WYSIWYG style. I tried XML Spy but it is not so easy to use. I couldn't even figure out how to get an XSL preview to work properly. It wanted me to create an sps file in order to show the transformation but in their sps editor I couldn't even tell it to use a file that I had already written. Way weird. I also tried eXcelon with is much easier to use. I want to know what other options are out there. I dont know if this is the best. But I use jEdit to write Cocoon projects. It has a plug-in for XML, XSL highlighting and another plug-in for XSLT tranformation that make it very easy to check what your XSLT stylesheet do. Best of all is OpenSource and because it is coded in Java runs in any platform. Also for file Save you can configure the diferents char formats: ISO-8859-1, UTF-8 and more. There is also a plug-in to manage all your project. more info: http://www.jedit.org/ Antonio Gallardo - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Cocoon Job opps in Frankfurt, Germany
Ahhh ... well ... Im a tad more expensive than that. =) I was gettign 80 USD per hour in colorado before I moved to germany and took a perm job. -- Robert - Original Message - From: Niclas Hedhman [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, January 29, 2003 3:28 AM Subject: Re: Cocoon Job opps in Frankfurt, Germany On Tuesday 28 January 2003 22:32, Jeremy Aston wrote: The UK rate has dropped significantly. You are really looking at something like £35-£40 per hour (as opposed to £60-£70 ph in the past couple of years. $500ph is v. reasonable. Not ph, per day Well, I live in a low-cost country (Malaysia) which is 50-75% lower cost of living than northern Europe (Sweden, Germany is my experience) at large. On top of that, I don't pay much income tax (5%). Can really recommend it... At the end of the day these angencies never put a rate since they want to get as good a person as cheap as possible! So do I ;o) A average programmer here would cost me ~USD1000 a month, a top notch one with special competency would be about twice that. Niclas jez -Original Message- From: Niclas Hedhman [mailto:[EMAIL PROTECTED]] Sent: 28 January 2003 05:13 To: [EMAIL PROTECTED] Subject: Re: Cocoon Job opps in Frankfurt, Germany On Tuesday 28 January 2003 09:20, Jeremy Aston wrote: Hi, I keep seeing ads for contractors based in Frankfurt on a UK based job site... http://www.it.jobserve.com/jobserve/searchresults.asp?jobType=*d= 5order=R a nkpage=1q=cocoon They almost all list Rate: Market. What is that roughly? Just curious what it pays to be employed nowadays in this kind of field... Anyone willing to reveal? Me? I live in the low cost country so I charge only(?) around $500 per day, as consultant. Niclas I have tried to get in there as a UK based person (and Cocooon book co-author) but the company are 100% set on having an on site person and no remote workers/software houses/cooperatives. I can't move to Germany so am out of the picture - bah! These people have advertised reguarly over the past 4-6 months so the work must be ongoing. If anyone does get in there and find they can put in a word for remote workers (I will go to a couple of times a month for a couple of days) then I'm here! rgds Jeremy - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do You Yahoo!? Everything you'll ever need on one web page from News and Sport to Email and Music Charts http://uk.my.yahoo.com - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How to open 2 windows?
I had a great page today. The dumb shits put a JavaScript action on closing the page that popped up a dialog saying if you want to stay at our page, press ok. If you don't want to leave press cancel. The only way you could leave that page was to kill the browser with the task manager. They may think that is smart but I know one thing, Ill never buy a single product from them. I don't remember the URL though so don't ask. =) -- Robert - Original Message - From: Niclas Hedhman [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, January 29, 2003 3:31 AM Subject: Re: How to open 2 windows? On Wednesday 29 January 2003 05:21, Robert Simmons wrote: Just a warning. There has been a study recently that quite well confirms that using popups in a commercial web site is a good way to drive traffic AWAY from that site. Personally, they annoy the shit out of me. If I really needed to get my penis enlarged Id look it up on google.de. Getting offered it from half the web sites on the internet could be bad for self confidence. =) I agree ( where do you can you get the enlargement, you said?? ;o) ) A lot of people disables pop-ups, or (like me) have the browser ask me if I want it. First one on a site, I consider ok. If commercial, then permenantly turned off for that site. I can't turn it off all the time, since some sincere sites are using this technique, for other things than adverts. Niclas - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: XML - XSL Editors?
Lol .. the community is really good I think. Lots I havent figured out yet thats irritating me though. Like why the forms sample in the cocoon war doesnt match the same constructs as the XMLForm tutorial at http://xml.apache.org/cocoon/howto/xmlform-wizard/howto-xmlform-wizard-3.html . Prob is that the interface is pretty irrelevant to my book but now Ive spent two weeks workign on it .. UGH Beginnign to think I shoulda jsut gone quick and dirty with JSP. -- Robert - Original Message - From: Antonio Gallardo [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, January 29, 2003 3:58 AM Subject: Re: XML - XSL Editors? Will you be checking jedit.org? Please almost include it as a usefull link. I saw many books about Java and XML and all they use windows. And they totally ignore some of the wonderfull applications that people can use for free. I hope you will speak good about Cocoon and is fabulous community with 7-24 support on-line. in your book. ;-) Best Regards, Antonio Gallardo. Robert Simmons dijo: Hmm, well my book has very little to do with cocoon. Its an advanced java book. id be suprised if I mentioned more than a couple pages on cocoon. Basically the book will talk about various java enterprise programing and I will be using cocoon for the interface to the remote ejbs. -- Robert - Original Message - From: Antonio Gallardo [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, January 29, 2003 2:24 AM Subject: Re: XML - XSL Editors? Hey?! Maybe and this article can be usefull for you and your work on the book: http://community.jedit.org/modules.php?op=modloadname=newsfile=articlesid= 202 By the way, what is the name of your future book? Antonio Gallardo. Antonio Gallardo dijo: Robert Simmons dijo: What are the best XML and XSLT editors on the market. I'm looking for something that is easy to use and offers the chance to edit XSL in a WYSIWYG style. I tried XML Spy but it is not so easy to use. I couldn't even figure out how to get an XSL preview to work properly. It wanted me to create an sps file in order to show the transformation but in their sps editor I couldn't even tell it to use a file that I had already written. Way weird. I also tried eXcelon with is much easier to use. I want to know what other options are out there. I dont know if this is the best. But I use jEdit to write Cocoon projects. It has a plug-in for XML, XSL highlighting and another plug-in for XSLT tranformation that make it very easy to check what your XSLT stylesheet do. Best of all is OpenSource and because it is coded in Java runs in any platform. Also for file Save you can configure the diferents char formats: ISO-8859-1, UTF-8 and more. There is also a plug-in to manage all your project. more info: http://www.jedit.org/ Antonio Gallardo - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
XMLForms Versus Traditional HTML forms.
Greetings. I would like to know what people favor using. By my, admittedly limited, knowledge, the traditional HTML forms will still work with cocoon as the request will still have access to the data. Alternatively if I use XMLForms, I'm not sure how much learning effort Id have to invest. I read the XMLForm tutorial at http://xml.apache.org/cocoon/howto/xmlform-wizard/howto-xmlform-wizard-3.htmland am still a but unclear how I define how the form will be rendered. Does the user have control over that at all? If I use HTML forms then I would be imbedding a form into an XSL transform which would print out the form for the user. So basically I am asking what reasons are there to use XMLForms. -- Robert
Re: XMLForms Versus Traditional HTML forms.
Well actually I already have some generators running to fetch data from the database. I have put that data in manually. Now I want to do it dynamically. Simplicity wise I should use conventional forms, but I am not sure if that is the right way to do it. -- Robert - Original Message - From: Niclas Hedhman [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, January 29, 2003 4:39 AM Subject: Re: XMLForms Versus Traditional HTML forms. On Wednesday 29 January 2003 11:16, Robert Simmons wrote: Greetings. I would like to know what people favor using. By my, admittedly limited, knowledge, the traditional HTML forms will still work with cocoon as the request will still have access to the data. Alternatively if I use XMLForms, I'm not sure how much learning effort Id have to invest. I read the XMLForm tutorial at http://xml.apache.org/cocoon/howto/xmlform-wizard/howto-xmlform-wizard-3.ht ml and am still a but unclear how I define how the form will be rendered. Does the user have control over that at all? If I use HTML forms then I would be imbedding a form into an XSL transform which would print out the form for the user. Slightly beyond my experience (I also use 'conventional' approach), but I see it as; 1. The XMLForm generator creates a XML document of the POST request. 2. You can aggregate that with other XML documents, static or dynamic. 3. Feed that to the transformer(s). 4. Output Meaning, the main advantage would be that you can do a fair amount of logic on the posted request in XSL (XSL is Turing complete, right?), without writing any Java/XSP code. For some people (those who know XSL better than Java) that is more power with less hazzle. Niclas - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: XMLForms Versus Traditional HTML forms.
Lets not lump cocoon to XMLForms or no XMLForms. Nor should we pick out any other one feature of cocoon and say that if you don't use this feature you shouldn't use cocoon. Nor should we say something like if you aren't going pure XML XSL XSP that you shouldn't use cocoon. Cocoon is a toolkit and you should pick those tools appropriate to your use. I chose cocoon over JSP because I get the multi format content and clear separation of logic and presentation. To me, a form is presentation. As for multi-content, I could easily write a transform that converts things to WML based forms. Its a matter of taste. Its also a matter of necessity. I have already spent too long working on the presentation layer to my project and I don't care to invest another month. I am not merely a learner but a professional with tight deadlines. I'm not sure its worth the extra effort. But the not sure is why I posted the question. If I was sure, I wouldn't have posted. Another thing is if it is in draft than that would be one reason for me to do it the old way. Real business applications require something that works. That isn't always the same thing as something that is cool. -- Robert - Original Message - From: Kirchhoff, Lars [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, January 29, 2003 5:09 AM Subject: AW: XMLForms Versus Traditional HTML forms. But why you need then cocoon for? If you just use traditional html isn't cocoon a bit to much? i'm just curios? Wouldn't it then better just use jsp or something similar? The main advantage of cocoon and xmlform for me is still to create a xml document, which then can be transformed through the pipeline in nearly every possible format. This means creating applications or websites, which can serve multiple devices. Especially for xmlforms there is a strong seperation of concerns, which in the first moment and for small application is a bit to much, but helps to divide the programming of the actual dataflow and business logic from the presentation layer and keeps the code manageable. I don't like to mix up any program code with tags from either xml or html. That's why I use and tried xmlform and don't feel comfortable with xsp. Of course you can transform the xmlform tags to html form tags, as long as there are not to many browser out, which are understanding xforms, which are still in draft. BTW does anybody know an reference implementation of an xforms browser? regards Lars -Ursprüngliche Nachricht- Von: Robert Simmons [mailto:[EMAIL PROTECTED]] Gesendet: Mittwoch, 29. Januar 2003 11:50 An: [EMAIL PROTECTED] Betreff: Re: XMLForms Versus Traditional HTML forms. Well actually I already have some generators running to fetch data from the database. I have put that data in manually. Now I want to do it dynamically. Simplicity wise I should use conventional forms, but I am not sure if that is the right way to do it. -- Robert - Original Message - From: Niclas Hedhman [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, January 29, 2003 4:39 AM Subject: Re: XMLForms Versus Traditional HTML forms. On Wednesday 29 January 2003 11:16, Robert Simmons wrote: Greetings. I would like to know what people favor using. By my, admittedly limited, knowledge, the traditional HTML forms will still work with cocoon as the request will still have access to the data. Alternatively if I use XMLForms, I'm not sure how much learning effort Id have to invest. I read the XMLForm tutorial at http://xml.apache.org/cocoon/howto/xmlform-wizard/howto-xmlfor m-wizard-3.ht ml and am still a but unclear how I define how the form will be rendered. Does the user have control over that at all? If I use HTML forms then I would be imbedding a form into an XSL transform which would print out the form for the user. Slightly beyond my experience (I also use 'conventional' approach), but I see it as; 1. The XMLForm generator creates a XML document of the POST request. 2. You can aggregate that with other XML documents, static or dynamic. 3. Feed that to the transformer(s). 4. Output Meaning, the main advantage would be that you can do a fair amount of logic on the posted request in XSL (XSL is Turing complete, right?), without writing any Java/XSP code. For some people (those who know XSL better than Java) that is more power with less hazzle. Niclas - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e
Re: XMLForms Versus Traditional HTML forms.
Well, if you want my advice stay away from entity beans. They are evil in the extreme. As for forms being in draft, that bothers me. I do, however, have allot of actions I need to write and some common method of outputting the forms automatically based on the command being run would be interesting to me. I might take a hybrid approach here. What Id like to have happen is that a user decides to execute a command which hits a generator with the name of the command and any initialization parameters. Then the generator spits out a document containing the structure of needed information from the form. Then the style sheets take over and render the forms and then the user can submit them. To do this I might just borrow the XML form namespace and have the generator spit out valid XML form documents. Just thinking out loud. -- Robert - Original Message - From: Geoff Howard [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, January 29, 2003 5:59 AM Subject: RE: XMLForms Versus Traditional HTML forms. -Original Message- From: Robert Simmons [mailto:[EMAIL PROTECTED]] As for multi-content, I could easily write a transform that converts things to WML based forms. Its a matter of taste. Its also a matter of necessity. I have already spent too long working on the presentation layer to my project and I don't care to invest another month. I am not merely a learner but a professional with tight deadlines. I'm not sure its worth the extra effort. But the not sure is why I posted the question. If I was sure, I wouldn't have posted. One potential upside is the fact that XMLForms uses beans for the datamodel (I think). that being the case, I have assumed there'd be a way to let ejb's fill that role (which based on past discussions I assume you're using here) and you'd get the binding to/from the form for free as you can in jsp. Another thing is if it is in draft than that would be one reason for me to do it the old way. Real business applications require something that works. That isn't always the same thing as something that is cool. I've not used xmlform yet because of the draft status and the time to learn - same issues you raise. Looks quite promising though, especially if the bean hunch pans out. - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: XMLForms Versus Traditional HTML forms.
Theoretically, but if you were trying to deliver an action driven system, this would be difficult. You would have to validate inside the pipeline and that would be problematic for a number of reasons. You would have to write some sort of custom validator. The problem here is that configuration is being done at the sitemap level and that is resource intensive. IT would be much more efficient if you could drop in a set of beans, have a Java class read them via introspection and then generate forms based upon the needs of that command. Then you would have a command driven architecture that would be quickly adaptable. all you have to do is drop in another command (a bean object) and viola, a new form gets spit out the far end. I will screw with this and see if I can get it to work. Call it reflexive form generation =) -- Robert - Original Message - From: Geoff Howard [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, January 29, 2003 6:06 AM Subject: RE: XMLForms Versus Traditional HTML forms. also there's supposed to be support for validation, error handling, and persistence across calls, right? -Original Message- From: Geoff Howard [mailto:[EMAIL PROTECTED]] Sent: Tuesday, January 28, 2003 11:59 PM To: [EMAIL PROTECTED] Subject: RE: XMLForms Versus Traditional HTML forms. -Original Message- From: Robert Simmons [mailto:[EMAIL PROTECTED]] As for multi-content, I could easily write a transform that converts things to WML based forms. Its a matter of taste. Its also a matter of necessity. I have already spent too long working on the presentation layer to my project and I don't care to invest another month. I am not merely a learner but a professional with tight deadlines. I'm not sure its worth the extra effort. But the not sure is why I posted the question. If I was sure, I wouldn't have posted. One potential upside is the fact that XMLForms uses beans for the datamodel (I think). that being the case, I have assumed there'd be a way to let ejb's fill that role (which based on past discussions I assume you're using here) and you'd get the binding to/from the form for free as you can in jsp. Another thing is if it is in draft than that would be one reason for me to do it the old way. Real business applications require something that works. That isn't always the same thing as something that is cool. I've not used xmlform yet because of the draft status and the time to learn - same issues you raise. Looks quite promising though, especially if the bean hunch pans out. - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: XMLForms Versus Traditional HTML forms.
Hmm .. I cant seem to even find the samples on my cocoon installation. Are they not in the current binary distribution ? -- Robert - Original Message - From: Kirchhoff, Lars [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, January 29, 2003 5:09 AM Subject: AW: XMLForms Versus Traditional HTML forms. But why you need then cocoon for? If you just use traditional html isn't cocoon a bit to much? i'm just curios? Wouldn't it then better just use jsp or something similar? The main advantage of cocoon and xmlform for me is still to create a xml document, which then can be transformed through the pipeline in nearly every possible format. This means creating applications or websites, which can serve multiple devices. Especially for xmlforms there is a strong seperation of concerns, which in the first moment and for small application is a bit to much, but helps to divide the programming of the actual dataflow and business logic from the presentation layer and keeps the code manageable. I don't like to mix up any program code with tags from either xml or html. That's why I use and tried xmlform and don't feel comfortable with xsp. Of course you can transform the xmlform tags to html form tags, as long as there are not to many browser out, which are understanding xforms, which are still in draft. BTW does anybody know an reference implementation of an xforms browser? regards Lars -Ursprüngliche Nachricht- Von: Robert Simmons [mailto:[EMAIL PROTECTED]] Gesendet: Mittwoch, 29. Januar 2003 11:50 An: [EMAIL PROTECTED] Betreff: Re: XMLForms Versus Traditional HTML forms. Well actually I already have some generators running to fetch data from the database. I have put that data in manually. Now I want to do it dynamically. Simplicity wise I should use conventional forms, but I am not sure if that is the right way to do it. -- Robert - Original Message - From: Niclas Hedhman [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, January 29, 2003 4:39 AM Subject: Re: XMLForms Versus Traditional HTML forms. On Wednesday 29 January 2003 11:16, Robert Simmons wrote: Greetings. I would like to know what people favor using. By my, admittedly limited, knowledge, the traditional HTML forms will still work with cocoon as the request will still have access to the data. Alternatively if I use XMLForms, I'm not sure how much learning effort Id have to invest. I read the XMLForm tutorial at http://xml.apache.org/cocoon/howto/xmlform-wizard/howto-xmlfor m-wizard-3.ht ml and am still a but unclear how I define how the form will be rendered. Does the user have control over that at all? If I use HTML forms then I would be imbedding a form into an XSL transform which would print out the form for the user. Slightly beyond my experience (I also use 'conventional' approach), but I see it as; 1. The XMLForm generator creates a XML document of the POST request. 2. You can aggregate that with other XML documents, static or dynamic. 3. Feed that to the transformer(s). 4. Output Meaning, the main advantage would be that you can do a fair amount of logic on the posted request in XSL (XSL is Turing complete, right?), without writing any Java/XSP code. For some people (those who know XSL better than Java) that is more power with less hazzle. Niclas - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: XMLForms Versus Traditional HTML forms.
If there is any overlap, I'm not aware of it. Cocoon is XML centric and not
Java centric. What I'm thinking of is a way to drive XML with Java. So if you
had a bean like ...
public class ChangeAge extends Command {
private int age;
private String name;
// getter and setters.
}
Than a java class would spit out the following:
xf:form id=ChangeAge view= action=ChangeAge.html
xf:captionRegistration/xf:caption
error
xf:violations class=error/
/error
xf:textbox ref=/name
xf:captionName:/xf:caption
xf:violations class=error/
/xf:textbox
xf:textbox ref=/age
xf:captionage/xf:caption
xf:helpNew age/xf:help
xf:violations class=error/
/xf:textbox
xf:submit id=submit class=button
xf:captionChange Age/xf:caption
/xf:submit
/xf:form
And then the user could use XSLT to dynamically transform the form into what
they wanted. The problem is that the sitemap could no longer be effectively
used to configure individual actions because they would largely depend upon
what actions exist in the object model of the beans. But I do have a few
ideas. ;)
-- Robert
- Original Message -
From: Geoff Howard [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Wednesday, January 29, 2003 6:29 AM
Subject: RE: XMLForms Versus Traditional HTML forms.
As for forms being in draft, that bothers me.
Don't rely on my word here - that is my memory of what I learned (and
someone just said that tonight, too right?) looking into xmlform again
about
2-3 months ago, so things may have moved on.
I do, however, have
allot of actions I need to write and some common method of outputting the
forms automatically based on the command being run would be interesting
to
me. I might take a hybrid approach here.
I have recently been converted to the modular database actions which may
provide some inspiration and groundwork for actions hitting session beans
(assuming that's what you meant). One xml config file with db table
structure and a few other tidbits handles my insert, update and deletes
(for
simple cases) with no coding. I think they're in 2.0.4 but not positive.
Modular in this case refers to the use of input modules. Christian Haul
on the list appears to be the author/resident guru on both.
As a side note, I recently worked with Chris to make some trivial
modifications that allow multipart form file uploads to populate db blobs
automatically.
What Id like to have happen is that a user decides to execute a
command which
hits a generator with the name of the command and any initialization
parameters. Then the generator spits out a document containing
the structure
of needed information from the form. Then the style sheets take over and
render the forms and then the user can submit them. To do this I
might just
borrow the XML form namespace and have the generator spit out
valid XML form
documents.
This sounds great - is there no overlap with the current stuff?
Geoff
-
Please check that your question has not already been answered in the
FAQ before posting. http://xml.apache.org/cocoon/faq/index.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
Please check that your question has not already been answered in the
FAQ before posting. http://xml.apache.org/cocoon/faq/index.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: XMLForms Versus Traditional HTML forms.
Yeah .. well I meant the XMLForms samples. And I still haven't found those. The other samples I found easily. -- Robert - Original Message - From: Niclas Hedhman [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, January 29, 2003 6:25 AM Subject: Re: XMLForms Versus Traditional HTML forms. On Wednesday 29 January 2003 13:11, Robert Simmons wrote: Hmm .. I cant seem to even find the samples on my cocoon installation. Are they not in the current binary distribution ? Provided you have dropped the cocoon.war into $TOMCAT_HOME/webapps, you should find samples in; $TOMCAT_HOME/webapps/cocoon/samples/ Niclas -- Robert - Original Message - From: Kirchhoff, Lars [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, January 29, 2003 5:09 AM Subject: AW: XMLForms Versus Traditional HTML forms. But why you need then cocoon for? If you just use traditional html isn't cocoon a bit to much? i'm just curios? Wouldn't it then better just use jsp or something similar? The main advantage of cocoon and xmlform for me is still to create a xml document, which then can be transformed through the pipeline in nearly every possible format. This means creating applications or websites, which can serve multiple devices. Especially for xmlforms there is a strong seperation of concerns, which in the first moment and for small application is a bit to much, but helps to divide the programming of the actual dataflow and business logic from the presentation layer and keeps the code manageable. I don't like to mix up any program code with tags from either xml or html. That's why I use and tried xmlform and don't feel comfortable with xsp. Of course you can transform the xmlform tags to html form tags, as long as there are not to many browser out, which are understanding xforms, which are still in draft. BTW does anybody know an reference implementation of an xforms browser? regards Lars -Ursprüngliche Nachricht- Von: Robert Simmons [mailto:[EMAIL PROTECTED]] Gesendet: Mittwoch, 29. Januar 2003 11:50 An: [EMAIL PROTECTED] Betreff: Re: XMLForms Versus Traditional HTML forms. Well actually I already have some generators running to fetch data from the database. I have put that data in manually. Now I want to do it dynamically. Simplicity wise I should use conventional forms, but I am not sure if that is the right way to do it. -- Robert - Original Message - From: Niclas Hedhman [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, January 29, 2003 4:39 AM Subject: Re: XMLForms Versus Traditional HTML forms. On Wednesday 29 January 2003 11:16, Robert Simmons wrote: Greetings. I would like to know what people favor using. By my, admittedly limited, knowledge, the traditional HTML forms will still work with cocoon as the request will still have access to the data. Alternatively if I use XMLForms, I'm not sure how much learning effort Id have to invest. I read the XMLForm tutorial at http://xml.apache.org/cocoon/howto/xmlform-wizard/howto-xmlfor m-wizard-3.ht ml and am still a but unclear how I define how the form will be rendered. Does the user have control over that at all? If I use HTML forms then I would be imbedding a form into an XSL transform which would print out the form for the user. Slightly beyond my experience (I also use 'conventional' approach), but I see it as; 1. The XMLForm generator creates a XML document of the POST request. 2. You can aggregate that with other XML documents, static or dynamic. 3. Feed that to the transformer(s). 4. Output Meaning, the main advantage would be that you can do a fair amount of logic on the posted request in XSL (XSL is Turing complete, right?), without writing any Java/XSP code. For some people (those who know XSL better than Java) that is more power with less hazzle. Niclas - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Please check that your
Re: Cocoon Job opps in Frankfurt, Germany
Yes, my rates had to fall recently by about 12k Euros per year permanent. Its really irritating. Don't worry, it will pick back up soon. -- Robert - Original Message - From: Jeremy Aston [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, January 29, 2003 6:49 AM Subject: RE: Cocoon Job opps in Frankfurt, Germany snip/ On Tuesday 28 January 2003 22:32, Jeremy Aston wrote: The UK rate has dropped significantly. You are really looking at something like £35-£40 per hour (as opposed to £60-£70 ph in the past couple of years. $500ph is v. reasonable. Not ph, per day Yup - I meant per day. $500 is approx £300 = £37.5ph based on 8hr day. Which for an experienced web app developer with Java/XML/XSLT and experience of Cocoon is reasonable from an employers perspective. Having said that the best the same could hope to get at the moment in a perm role would be around 35k per annum and they would be expected to do a lead role for that. There is such a glut of coders, lack of roles and tight belts in the UK at the moment that even good guys might have to settle for less than 30k - the best could easily get twice that a couple of years ago... snip/ jez __ Do You Yahoo!? Everything you'll ever need on one web page from News and Sport to Email and Music Charts http://uk.my.yahoo.com - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Form processign and control flow?
Well, my newbieness to cocoon continues as does my
frustration. Anyway, another burning question.
I have a series of forms with pseudo code such as
if (user invokes edit) {
open edit form;
on submit of form {
attempt to execute
change.
if (attempt succeeds) route to
view page.
else route to error page with
the given error message from the attempt.
}
}
Both the error page and the pages beign routed to
are usign custom made generators. What I dont know how to do is to do the
routing. I can always invoke one generator to process the command and return an
error page if the command doesnt work. However, if the command doesnt work Id
like the generator to cause a redirect that forwards the user's browser to
another url. How in the world can I accomplish this? Im eagerly awaitign hearign
your ideas.
-- Robert
Cocoon Competence Center Updates
Greetings, I have added the following information to the cocoon competence center page on installing cocoon. Please feel free to review the following sections and smack me around if I said anything incorrect. The new sections are. *Deploying on an application server. *What is essential? -- Robert
Re: Cocoon Competence Center Updates
On the same topic, I am more distressed at this editing policy. Someone could easily be malicious and log in and erase everything. Are we sure there isn't a better way to do this? -- Robert - Original Message - From: Robert Simmons To: Cocoon Users Sent: Thursday, January 30, 2003 3:41 AM Subject: Cocoon Competence Center Updates Greetings, I have added the following information to the cocoon competence center page on installing cocoon. Please feel free to review the following sections and smack me around if I said anything incorrect. The new sections are. *Deploying on an application server. *What is essential? -- Robert
XSP Compiler Issue: Class Not found
Greetings. I decided that I wanted to try writing
an XSP page. I know about logicsheets but just to start I figured Idgo the
brute force approach. The following is theXSP page.
?xml version="1.0"
encoding="UTF-8"?xsp:page language="java" xmlns:xsp="http://apache.org/xsp"
xmlns:jconfer="http://www.jconfer.org/"
xsp:structure
xsp:includejavax.naming.InitialContext/xsp:include
xsp:includejavax.naming.NamingException/xsp:include
xsp:includejavax.rmi.PortableRemoteObject/xsp:include
xsp:includejava.util.Collection/xsp:include
xsp:includejava.util.Set/xsp:include
xsp:includejava.util.Iterator/xsp:include
xsp:includejava.util.Properties/xsp:include
xsp:includejconfer.data.Smiley/xsp:include
xsp:includemirror.datafetch.DataFetch/xsp:include
xsp:includemirror.datafetch.DataFetchHome/xsp:include
/xsp:structure
jconfer:page
xsp:logic try
{ InitialContext ictxt = new
InitialContext();
messagexsp:exprictxt.getNameInNamespace()/xsp:expr/message
DataFetchHome dfHome =
(DataFetchHome)PortableRemoteObject.narrow(
ictxt.lookup("JConfer/DataFetch"),
DataFetchHome.class); DataFetch
dataFetch = dfHome.create();
Collection smileys = dataFetch.performQuery(Smiley.class, null, null, null,
null, "code ascending"); Iterator
iter = smileys.iterator(); Smiley
tgtSmiley = null;
xsp:element
xsp:param
name="name"xsp:expr"smiley"/xsp:expr/xsp:param
while (iter.hasNext())
{
tgtSmiley =
(Smiley)iter.next();
xsp:attribute
name="code"xsp:exprtgtSmiley.getCode()/xsp:expr/xsp:attribute
xsp:attribute
name="code"xsp:exprtgtSmiley.getDescription()/xsp:expr/xsp:attribute
}
/xsp:element } catch (Exception ex)
{
messagexsp:exprex.getMessage()/xsp:expr/message
} /xsp:logic
/jconfer:page
/xsp:page
This page is basically a copy of a generator that
DOES work .. SHown below.
package jconfer.client.generators;
import java.io.IOException;import
java.util.Collection;import java.util.Date;import
java.util.Enumeration;import java.util.Iterator;import
java.util.Map;import javax.naming.InitialContext;import
javax.naming.NamingException;import
javax.rmi.PortableRemoteObject;import
javax.servlet.http.HttpServletRequest;import jconfer.data.Smiley;import
mirror.datafetch.DataFetch;import mirror.datafetch.DataFetchHome;import
org.apache.avalon.framework.parameters.Parameters;import
org.apache.cocoon.ProcessingException;import
org.apache.cocoon.environment.ObjectModelHelper;import
org.apache.cocoon.environment.Request;import
org.apache.cocoon.environment.SourceResolver;import
org.apache.cocoon.generation.AbstractGenerator;import
org.w3c.dom.Document;import org.w3c.dom.Element;import
org.xml.sax.SAXException;import
org.xml.sax.helpers.AttributesImpl;
/** Handles a command for getting an admin screen
for forum smileys.** pbsmallCurrent
CVS Tag: $Name$/b/small/p* @version
$Revision$* @author $author$*/public class
SmileyAdminView extends GeneratorBase {
/** {@inheritDoc} */ public void
generateContent() throws Exception { DataFetchHome dfHome
= (DataFetchHome)jndiLookup(DataFetchHome.class,
"JConfer/DataFetch"); DataFetch dataFetch =
dfHome.create(); // -- Collection
smileys = dataFetch.performQuery(Smiley.class, null, null, null,
null, "code ascending"); // --
AttributesImpl attributes = new AttributesImpl(); Smiley
tgtSmiley = null; // -- Start the
content this.contentHandler.startElement("",
"smiley-admin-view", "smiley-admin-view", EMPTY_ATTRS); //
-- Do internal elements. Iterator iter =
smileys.iterator(); while (iter.hasNext())
{ tgtSmiley =
(Smiley)iter.next();
attributes.clear();
attributes.addAttribute("", "code", "code", "",
tgtSmiley.getCode());
attributes.addAttribute("", "description", "description", "",
tgtSmiley.getDescription());
this.contentHandler.startElement("", "smiley", "smiley",
attributes);
this.contentHandler.endElement("", "smiley", "smiley");
} // -- End the document
this.contentHandler.endElement("", "smiley-admin-view",
"smiley-admin-view"); }}
The problem is that when I try to run the XSP page,
the compiler freaks out and cannot find any of the Mirror or JConfer classes. It
gives me a class not found on all of them. However the generator works. These
classes are deployed in another package and therefore are available to the
classloader of the application server but somehow cocoon isnt seeing them. Is
there any way I can tell cocoon that they are there? We know they are available
because the generator does in fact work.
-- Robert
Re: XSP Compiler Issue: Class Not found
More information. I think this might have to do
with the classpath setting on the compiler. It seems to be creating its own
classpath instead of passing the current cocoon classpath to the compiler. The
classloader, being different, cannot find any classes outside of the current WAR
to compile. This would mean that you would have to deploy every single library
you use in the WEB-INF/lib directory. That is untenable for large applications.
Further, for applications that have to wire into EJB, it is even worse. This is
because you will often have a set of interfaces for a server side component and
need to redeploy them. With this limitation, my classes in cocoon could get out
of synch with those deployed in the application server quite easily and cause
all sorts of nastiness.
Is this a bug perhaps? Has anyone else hit this?
-- Robert
- Original Message -
From:
Robert Simmons
To: Cocoon Users
Sent: Thursday, January 30, 2003 4:47
AM
Subject: XSP Compiler Issue: Class Not
found
Greetings. I decided that I wanted to try writing
an XSP page. I know about logicsheets but just to start I figured Idgo
the brute force approach. The following is theXSP page.
?xml version="1.0"
encoding="UTF-8"?xsp:page language="java" xmlns:xsp="http://apache.org/xsp"
xmlns:jconfer="http://www.jconfer.org/"
xsp:structure
xsp:includejavax.naming.InitialContext/xsp:include
xsp:includejavax.naming.NamingException/xsp:include
xsp:includejavax.rmi.PortableRemoteObject/xsp:include
xsp:includejava.util.Collection/xsp:include
xsp:includejava.util.Set/xsp:include
xsp:includejava.util.Iterator/xsp:include
xsp:includejava.util.Properties/xsp:include
xsp:includejconfer.data.Smiley/xsp:include
xsp:includemirror.datafetch.DataFetch/xsp:include
xsp:includemirror.datafetch.DataFetchHome/xsp:include
/xsp:structure
jconfer:page
xsp:logic try
{ InitialContext ictxt = new
InitialContext();
messagexsp:exprictxt.getNameInNamespace()/xsp:expr/message
DataFetchHome dfHome =
(DataFetchHome)PortableRemoteObject.narrow(
ictxt.lookup("JConfer/DataFetch"),
DataFetchHome.class); DataFetch
dataFetch = dfHome.create();
Collection smileys = dataFetch.performQuery(Smiley.class, null, null, null,
null, "code ascending");
Iterator iter =
smileys.iterator(); Smiley
tgtSmiley = null;
xsp:element
xsp:param
name="name"xsp:expr"smiley"/xsp:expr/xsp:param
while (iter.hasNext())
{
tgtSmiley =
(Smiley)iter.next();
xsp:attribute
name="code"xsp:exprtgtSmiley.getCode()/xsp:expr/xsp:attribute
xsp:attribute
name="code"xsp:exprtgtSmiley.getDescription()/xsp:expr/xsp:attribute
}
/xsp:element } catch (Exception ex)
{
messagexsp:exprex.getMessage()/xsp:expr/message
} /xsp:logic
/jconfer:page
/xsp:page
This page is basically a copy of a generator that
DOES work .. SHown below.
package jconfer.client.generators;
import java.io.IOException;import
java.util.Collection;import java.util.Date;import
java.util.Enumeration;import java.util.Iterator;import
java.util.Map;import javax.naming.InitialContext;import
javax.naming.NamingException;import
javax.rmi.PortableRemoteObject;import
javax.servlet.http.HttpServletRequest;import
jconfer.data.Smiley;import mirror.datafetch.DataFetch;import
mirror.datafetch.DataFetchHome;import
org.apache.avalon.framework.parameters.Parameters;import
org.apache.cocoon.ProcessingException;import
org.apache.cocoon.environment.ObjectModelHelper;import
org.apache.cocoon.environment.Request;import
org.apache.cocoon.environment.SourceResolver;import
org.apache.cocoon.generation.AbstractGenerator;import
org.w3c.dom.Document;import org.w3c.dom.Element;import
org.xml.sax.SAXException;import
org.xml.sax.helpers.AttributesImpl;
/** Handles a command for getting an admin screen
for forum smileys.**
pbsmallCurrent CVS Tag:
$Name$/b/small/p* @version
$Revision$* @author $author$*/public class
SmileyAdminView extends GeneratorBase {
/** {@inheritDoc} */ public void
generateContent() throws Exception { DataFetchHome
dfHome = (DataFetchHome)jndiLookup(DataFetchHome.class,
"JConfer/DataFetch"); DataFetch dataFetch =
dfHome.create(); // -- Collection
smileys = dataFetch.performQuery(Smiley.class, null, null, null,
null, "code ascending"); // --
AttributesImpl attributes = new AttributesImpl(); Smiley
tgtSmiley = null; // -- Start the
content this.contentHandler.startElement("",
"smiley-admin-view", "smiley-admin-view", EMPTY_ATTRS);
// -- Do internal elements. Iterator iter =
smileys.iterator(); while (iter.hasNext())
{ tgtSmiley =
(Smiley)iter.next(
Re: Cocoon Competence Center Updates
Fine ... I'm beginning to loose interest to be honest. Right now I cant do anything with XSP with cocoon at all. because of the classpath bug it looks like two weeks of my work are about to explode in my face. Sigh. -- Robert - Original Message - From: SAXESS - Hussayn Dabbous [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, January 30, 2003 9:12 AM Subject: Re: Cocoon Competence Center Updates Hy, Robert; Thank you very much for the contributions. I propose to move parts of your contrib into another page. reasons: 1.) this page deals with deploying cocoon. it should not cover essentials of cocoon internals. this is the next story to be covered, once cocoon is deployed. 2.) i want this document to be for beginning beginners, (we used to name them nebies ;-). Yes we should prepare a doc, that contains your hints and tips, but maybe this is an add on page ? if nobody complains, i will move your contribs to another page, but keep the super esssentials in the doc (and point to the new pages where relevant) is that ok for you Robert? regards, Hussayn Robert Simmons wrote: Greetings, I have added the following information to the cocoon competence center page on installing cocoon. Please feel free to review the following sections and smack me around if I said anything incorrect. The new sections are. * Deploying on an application server. * What is essential? -- Robert -- Dr. Hussayn Dabbous SAXESS Software Design GmbH Neuenhöfer Allee 125 50935 Köln Telefon: +49-221-56011-0 Fax: +49-221-56011-20 E-Mail: [EMAIL PROTECTED] - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Cocoon Competence Center Updates
Is not cocoon's power or anything else that I'm arguing with. There is an extremely serious bug in cocoon that is causing me to not be able to use it at all. It is clear that cocoon was developed to be a single solution and to not integrate with technologies such as application servers. The classloader issue, http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16580, would make it ridiculous for me to do anything in cocoon. If I have to deploy all 100 EJB libs of the company I work for in cocoon as well as in the application server, than my colleagues would rightly laugh themselves silly. In fact I cant believe this issue even exists in a product this mature. I am looking at probably 3 months to get this fixed, minimum, if it is ever fixed. At that point I will have to wait for a release of the product, as my company would throw me at the door for putting up a bleeding edge CVS build. So basically I'm screwed when I comes to my book and when it comes to my company. Cocoon is pretty much out. I guess I have to throw out 2 weeks of agonizing work and I dot know how many emails and recode the whole damn thing in JSP. Lovely. Well, I suppose it could be worse. I dot see much market for Cocoon developers anyway. -- Robert - Original Message - From: SAXESS - Hussayn Dabbous [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, January 30, 2003 9:44 AM Subject: Re: Cocoon Competence Center Updates Hy Robert, I appreciate your honesty. I hope, you keep with us. I think you can really help getting this into the next generation... just a few of my experiences if you don't mind ... 0.) i use to install minimalistic components when i start investigating. in this sense i only needed tomcat-4.*.* to start. just installed it and ready to go... 1.) When i started working with cocoon i first got very very frustrated: sitemap not working as i expected actions, uhh? logicsheets, sounds good, howto??? and so on ... I even did not know, what to ask in detail. 3.) very slowly i got a first overview. i only scratched the surface and one day (after about two weeks) i got hit by realizing the hidden mightiness of the beast. Hey that's great, this works fine, ahh what easy going here and there... Until now i still only was playing with the very basics (sitemap, generator, protocol handlers) 4.) After reviewing my first experiences with cocoon i came to the conclusions: - its very complex - it has great oportunities - it is complex documented - it moves fast - it neads quality assurance to get mature My decisions: - use cocoon in my own projects - help cocoon users to get a clear understanding with less frustrations I'm still happy with cocoon and im still only using the very basics. I am curious where i can get with XSP and ESQL ;-) regards, hussayn Robert Simmons wrote: Fine ... I'm beginning to loose interest to be honest. Right now I cant do anything with XSP with cocoon at all. because of the classpath bug it looks like two weeks of my work are about to explode in my face. Sigh. -- Robert - Original Message - From: SAXESS - Hussayn Dabbous [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, January 30, 2003 9:12 AM Subject: Re: Cocoon Competence Center Updates Hy, Robert; Thank you very much for the contributions. I propose to move parts of your contrib into another page. reasons: 1.) this page deals with deploying cocoon. it should not cover essentials of cocoon internals. this is the next story to be covered, once cocoon is deployed. 2.) i want this document to be for beginning beginners, (we used to name them nebies ;-). Yes we should prepare a doc, that contains your hints and tips, but maybe this is an add on page ? if nobody complains, i will move your contribs to another page, but keep the super esssentials in the doc (and point to the new pages where relevant) is that ok for you Robert? regards, Hussayn Robert Simmons wrote: Greetings, I have added the following information to the cocoon competence center page on installing cocoon. Please feel free to review the following sections and smack me around if I said anything incorrect. The new sections are. * Deploying on an application server. * What is essential? -- Robert -- Dr. Hussayn Dabbous SAXESS Software Design GmbH Neuenhöfer Allee 125 50935 Köln Telefon: +49-221-56011-0 Fax: +49-221-56011-20 E-Mail: [EMAIL PROTECTED] - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED
Time to go back to JSP. Cocoon just isnt ready.
I have reluctantly come to the conclusion that cocoon is not ready for professional development. Unlike tomcat, or Ant, this product has serious things blocking its use in production systems. I personally am completely and utterly stopped by the classpath bug indicated here: http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16580. Just another symptom of a product that needs more work to be used in professional products. That coupled with the lack of documentation makes the package difficult at best. I will possibly be back in a year or so when this technology has gone somewhere. This is assuming it is still alive by then. I have seen a plethora of new people come on this list and then just vanish. That doesn't bode well for its reputation. I don't want to take this step and throw away two weeks of work but the fact is that I also don't have time to wait for such massive bugs to be fixed and to spend another two weeks swimming through poor debugging tools. Its a massive bummer to me but in order to be true to myself I cant see alternatives. The fact is that however flawed JSPs are, I can crack together JSP pagers 40 times faster than cocoon pages. When it comes to deadlines, major bugs like this just stop a product cold. Anyway, Ill stop rambling now. Comments are invited. -- Robert
Re: Cocoon Competence Center Updates
From: Robert Simmons [EMAIL PROTECTED] Is not cocoon's power or anything else that I'm arguing with. There is an extremely serious bug in cocoon that is causing me to not be able to use it at all. It is clear that cocoon was developed to be a single solution and to not integrate with technologies such as application servers. This is not true. If Cocoon does not integrate with a particular application server then this doesn't mean that it was done intentionally. You can easily see even from comments in the source that Cocoon were used with WebSphere, WebLogic, iPlanet and several other servers. It is true. Noone in their right mind makign a large system woudl deploy every damn jar in the WAR file. That would be psycho. The maintenance alone to make sure you had the right versions in the appserver and war would be a nightmare. Perhaps if you are developing a littly SQL app to keep track of employess cocoon is fine. If you try doing anything serious,issues like hte classloader issue bring it to its knees. And no, that isnt the only issue. The classloader issue, http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16580, would make it ridiculous for me to do anything in cocoon. If I have to deploy all 100 EJB libs of the company I work for in cocoon as well as in the application server, than my colleagues would rightly laugh themselves silly. In fact I cant believe this issue even exists in a product this mature. I am looking at probably 3 months to get this fixed, minimum, if it is ever fixed. At that point I will have to wait for a release of the product, as my company would throw me at the door for putting up a bleeding edge CVS build. The good thing in open source is that you always can take care of any bug yourself and provide a patch which would be definitely applied if it's of a good quality. No no no... you dont get it. Im a consumer. Im a professional programmer. Im not some guy hackign in his dorm room between classes. I dotn have TIME to learn the detailed integrated architecture of every little product I use. What really broke the proverbial camel's back was that bug beign reclassified from high priority to normal. Its at that point that final irritation set in. it woudl take me 3 months just ot figure out how the internals of cocoon works. Lets face it, its not documented worth a damn. Even the API is documented extremely poorly. Once I figured out how it worked I would have to figure out a resolution to the problem and THEN get apache to accept the resolution. All this before my product is done and my customers are looking to download and use it. NOT. So basically I'm screwed when I comes to my book and when it comes to my company. Cocoon is pretty much out. I guess I have to throw out 2 weeks of agonizing work and I dot know how many emails and recode the whole damn thing in JSP. Lovely. I'd recommend to use Struts in case you choose JSP. But of course, that depends on requirements to your project. If you have to deal with various output formats, need customizable pages, need integrations with external XML datasources then it's worth trying to overcome Cocoon bug in some way: try to fix it, raise this issue on cocoon dev list, try to play with your app server settings (maybe declare those jars in Manifest - it's possible according to Servlet Spec), etc. No, Im notgoing to mess with struts. That would be another 2 weeks to learn. Im already severly bummed that it looks like ive wasted 2 weeks of work. Im not going o make it worse. The first version in the book is going to have to be straight JSP without frameworks. Do I like it? No. Do I have a choice? No. Ive even tried to build it from source even though I have little clue what im doing. You cant just jump into 500+ quasi documented source files and figure out the problem in 15 minutes. -- Konstantin Well, I suppose it could be worse. I dot see much market for Cocoon developers anyway. -- Robert - Original Message - From: SAXESS - Hussayn Dabbous [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, January 30, 2003 9:44 AM Subject: Re: Cocoon Competence Center Updates Hy Robert, I appreciate your honesty. I hope, you keep with us. I think you can really help getting this into the next generation... just a few of my experiences if you don't mind ... 0.) i use to install minimalistic components when i start investigating. in this sense i only needed tomcat-4.*.* to start. just installed it and ready to go... 1.) When i started working with cocoon i first got very very frustrated: sitemap not working as i expected actions, uhh? logicsheets, sounds good, howto??? and so on ... I even did not know, what to ask in detail. 3.) very slowly i got a first overview. i only scratched the surface and one day (after about two weeks) i
Re: Cocoon Competence Center Updates
my question is how other people can even use cocoon with this bug in it. Certainly if you are just doing SQL to a little database, it will work fine but has none before tried to integrate it with an enterprise development system? -- Robert - Original Message - From: Luca Morandini [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, January 30, 2003 1:27 PM Subject: RE: Cocoon Competence Center Updates -Original Message- From: Robert Simmons [mailto:[EMAIL PROTECTED]] Sent: Thursday, January 30, 2003 1:08 PM To: [EMAIL PROTECTED] Subject: Re: Cocoon Competence Center Updates No no no... you dont get it. Im a consumer. Im a professional programmer. Im not some guy hackign in his dorm room between classes. I dotn have TIME to learn the detailed integrated architecture of every little product I use. ... Once I figured out how it worked I would have to figure out a resolution to the problem and THEN get apache to accept the resolution. All this before my product is done and my customers are looking to download and use it. NOT. Robert, I agree on the sorry state of the doc in Cocoon; sorry state which I take, partially, as a fault of mine, since I wrote only 3-4 FAQ entries and a couple pages... and I could have done more. I don't agree on the bug resolution part: I uncovered a couple problems with the SQLTranformer: it was easy to fix them and have them (well, actually one) accepted by the committers. Compare that with a closed-source product: it would have taken me days struggling with the tech support to just have the problem recognised as such; and then, I would have ended up waiting for the next release. Regards, - Luca Morandini GIS Consultant [EMAIL PROTECTED] http://utenti.tripod.it/lmorandini/index.html - - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Time to go back to JSP. Cocoon just isnt ready.
Robert Simmons wrote: I have seen a plethora of new people come on this list and then just vanish. Comments are invited. That's a quick decision for someone who has been around here for only 2 weeks: http://marc.theaimsgroup.com/?a=10426232413r=1w=2 I have put in 14 to 16 hours a day for 2 weeks on this thing. Lets fuckign add it up shall we. That would be 210 hours averaging at 15 hours a day. Dividing by 40 hours (the standard workweek) means that i have put in nearly 5 weeks of work time compressed into 2 weeks. You can sit down and shut up now. Since you may havent gotten the picture yet, I dont like being flamed. If I didnt care I wouldnt have bothered to post the damn mail. Then again, we should feel honoured because of the email avalanche you caused during that short period, in comparison with: http://jboss.org/forums/search.jsp?search=trueq=forums=-1date=anyuser=der isorrange=10 Avalanche? Oh well just sue me. If you would get off that high horse for 15 seconds, you might realize that that avalanche would have never had happened if the product was documented properly. Fortunately most members of this list are a bit more far sighted than you and have initiated a documentation effort based on my comments. I would say that is a contribution. Im not interested in your arrogant attitude. Oh and if you would like to know why it is I have had so few posts on JBoss forums, the answer is quite simple. The product works properly and well and is very well documented. Anyway: http://forum.java.sun.com/thread.jsp?forum=31thread=243200 : Oh you are steamed about that? Yes many of us on that forum are sick of kids comming there asking people to do their homework for them. No, you didnt really read the thread it seems or you would have seen our willingness to answer questions as long as they arent my teacher said to do x, can someone write it for me? As for teaching yourself in cocoon, again I have an ace in the hole you have forgotten. The documentation in cocoon is minimal at best. This has been acknowledged by other more intelligent members of this mailing list. In 4 years of college I knew more about computers than all of my profs together. Why? Cause I taught myself. Teaching one's self is rewarding but difficult. You MUST struggle. You must figure things out the hard way. Point out the documentation on the classpath issue. Show me the rich and fully qualified API documentation. Ahem. There isnt any. Do you make a habbit of flaming while firing blanks? Pardon me if I find your decisions somehow 'unstable'. I find it a pity to see you post this kind of judgement after so many people have been actively trying to help you (and still do). Sure there is stuff that Cocoon fails to do. I just think you are the type of person who will always find something that will warrant _not_ using something you haven't created yourself. There have been several people willign to help and I appreciate their assistance. These people have also recognized the shortcommings of cocoon and have acknowledged my input as a pure user and non-cocoon hacker. Perhaps you should hjoin them. I dont make the decision lightly and if I could find any way of satisfying my requirements with cocoon in the time I have, than I would change my mind. Unfortunately, real life is a tad more demanding. In case you start wondering why I'm so up-close and personal about this: Like I care. you really seem to forget this is _not_ a product, but an open source _project_, envisioned, created and supported by a community of real people. If its not a product why bother? Anythign worth doing is worth doing right. If you arent intending to make somethign that can be widely used, why are you bothering? Just idle curriosity? if so label it as such so people can say oh, and move on to something that people intend to be real. I think, however, the cocoon developers have a bit more vision. We are not being protective about our work, and we will readily admit its problems, but if all we get is yet another gee I'm gonna leave 'coz this sucks reply from you, I'm pretty sure I won't be the only one who just stops reading your mails. Please do. You have nothing intelligent to contribute so please add me to my ignore filter. That is assuming your monitor hasnt exploded from your flame beign stuffed back into your face. Oh well - flame me, I can handle it. I'm sick of seeing nice people trying to help you, and you just spreading FUD in return. This is the third inflamatory email I composed to you during the past few days, and this time, I won't refrain from sending. Feel free. If you ever come up with something intelligent to say, please flag it as important. Others such as SAXESS have you beat by about 10,000 percent in brain power and I appreciate their input. You, are just another dork sittign in judgement of others. Shoo! Unfortunately for you, you caught me in a particularly punchy mood where I am not going
Re: Time to go back to JSP. Cocoon just isnt ready.
Sorry. To say I've had a bad week would be a massive understatement. Today was just not the right day to flame me. If he had done it yesterday I would have ignored him. But my mail was just as uncalled for as his. -- Robert - Original Message - From: Sorin Marti [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, January 30, 2003 2:22 PM Subject: Re: Time to go back to JSP. Cocoon just isnt ready. Ooooh!! I have not followed the list in the last days and now this. What's going on? If you got a problem with each other why can't you be polite? This list is (AFAIK) NOT to curse at somebody. If you want to vituperate please do it per PM!! Sorin Marti - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Cocoon Competence Center Updates
My book has nothing to do with cocoon. Its a side issue at best. That's why I was so irritated about spending 2 weeks on it to draw a blank. Nothing like spending 2 weeks on something you consider to be trivial to your main line of work. -- Robert - Original Message - From: Irving Salisbury To: [EMAIL PROTECTED] Sent: Thursday, January 30, 2003 2:54 PM Subject: Re: Cocoon Competence Center Updates You know, I have been coding in cocoon for about 2 years now, and have gotten by quite happily without XSP pages at all. The bug you are referring to only is a bug with XSP. Maybe you can look at cocoon without using XSP pages? There may be a reason you have to use XSP, but just wanted to chime in with this. I prefer to avoid using XSP pages and stick with plain Java code, mostly using custom actions and transformers. It has worked well on our projects. Sorry about your book.IrvRobert Simmons wrote: Is not cocoon's power or anything else that I'm arguing with. There is an extremely serious bug in cocoon that is causing me to not be able to use it at all. It is clear that cocoon was developed to be a single solution and to not integrate with technologies such as application servers. The classloader issue, http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16580, would make it ridiculous for me to do anything in cocoon. If I have to deploy all 100 EJB libs of the company I work for in cocoon as well as in the application server, than my colleagues would rightly laugh themselves silly. In fact I cant believe this issue even exists in a product this mature. I am looking at probably 3 months to get this fixed, minimum, if it is ever fixed. At that point I will have to wait for a release of the product, as my company would throw me at the door for putting up a bleeding edge CVS build. So basically I'm screwed when I comes to my book and when it comes to my company. Cocoon is pretty much out. I guess I have to throw out 2 weeks of agonizing work and I dot know how many emails and recode the whole damn thing in JSP. Lovely. Well, I suppose it could be worse. I dot see much market for Cocoon developers anyway. -- Robert - Original Message - From: "SAXESS - Hussayn Dabbous" [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, January 30, 2003 9:44 AM Subject: Re: Cocoon Competence Center Updates Hy Robert, I appreciate your honesty. I hope, you keep with us. I think you can really help getting this into the next generation... just a few of my experiences if you don't mind ... 0.) i use to install minimalistic components when i start investigating. in this sense i only needed tomcat-4.*.* to start. just installed it and ready to go... 1.) When i started working with cocoon i first got very very frustrated: sitemap not working as i expected actions, uhh? logicsheets, sounds good, howto??? and so on ... I even did not know, what to ask in detail. 3.) very slowly i got a first overview. i only scratched the surface and one day (after about two weeks) i got hit by realizing the hidden mightiness of the beast. "Hey that's great, this works fine, ahh what easy going here and there..." Until now i still only was playing with the very basics (sitemap, generator, protocol handlers) 4.) After reviewing my first experiences with cocoon i came to the conclusions: - its very complex - it has great oportunities - it is "complex documented" - it moves fast - it neads quality assurance to get mature My decisions: - use cocoon in my own projects - help cocoon users to get a clear understanding with less frustrations I'm still happy with cocoon and im still only using the very basics. I am curious where i can get with XSP and ESQL ;-) regards, hussayn Robert Simmons wrote: Fine ... I'm beginning to loose interest to be honest. Right now I cant do anything with XSP with cocoon at all. because of the classpath bug it looks like two weeks of my work are about to explode in my face. Sigh. -- Robert - Original Message - From: "SAXESS - Hussayn Dabbous" [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, January 30, 2003 9:12 AM Subject: Re: Cocoon Competence Center Updates Hy, Robert; Thank you very much for the contributions. I propose to move parts of your contrib into another page. reasons: 1.) this page deals with deploying cocoon. it should not cover essentials of cocoon internals. this is the next story to be covered, once cocoon is deployed. 2.) i want this document to be for "beginning beginners", (we used to name them nebies ;-). Yes we should prepare a doc, that contains your hints and tips, but maybe this is an add on page ? if nobody complains, i
2.1 ? Release date and stabiltiy?
I was wondering if there has been a target release date set for 2.1. Additionally what experiences have people had with the current CVS builds of 2.1 ? Is it stable in core functionality ? -- Robert
Sitemap Tag Reference
Is there a reference manualto the sitemap schema and tags ? If you, I would appreciate a link. -- Robert
To the Columbia and her crew.
Words cannot express the sorrow we feel at the loss of the Columbia. As scientists ourselves, we feel a kinship to those that died 200,000 feet above the state of Texas. We should all take a moment to say farewell and then to push on with science and exploration so that their deaths were not in vain. As we mourn their loss, we should also remember that they all died living their childhood dream. It should be some solace that they all realized the pinnacle of their aspirations before leaving this world. To all of the families involved, words cannot express the sorrow we feel for the loss of their loved ones. We would only ask that in your moment of grief, you remember not how they died, but how they lived. -- Robert Simmons jr. -- Senior Software Engineer -- American Living in Munich, Germany
Re: [XML EDITOR] Netbeans
I use NetBeans. It has a good XML editor built into it but it would do well to add a WYSIWYG XSLT editor. So you can go write it. =) -- Robert - Original Message - From: Antonio Gallardo [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Sunday, February 02, 2003 2:47 AM Subject: [XML EDITOR] Netbeans Is anyone here using netbeans? more info at: http://www.netbeans.org It looks like netbeans has a built-in powerfull XML editor. Can someone share his own experience with this? Regards, Antonio Gallardo - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Cocoon 2 with jboss-3.0.4_tomcat-4.1.12
The manifest is located, strangely enough, in the WEB-INF directory of the latest release version of the war. You will have to use the entries in that manifest to create your own war. Please look at the -m option to the jar command or, better yet, the ant jar task. -- Robert Hello! thx for your reply. can you post an example manifest file? and where do i have to put the manifest file? into the cocoon war file or into the ear file ? thx, Chris On Tue, Feb 04, 2003 at 11:28:06AM +0100, [EMAIL PROTECTED] wrote: The problem is that you need the manifest file that has the Cocoon-Libs entry and the other entries for the Jars in the cocoon.war. If oyu dont build using this manifest than cocoon will not be able to locate anything. If you deploy as an exploded war than you will not have this problem. - Original Nachricht has anybody cocoon 2 with jboss 3/tomcat 4.1 up and running? i have tried to deploy my c2 application which usually runs on jboss 2.4.4/tomcat 3.2 (j2sdk1.3) to the newly installed jboss3.0.4/tomcat 4.1.12 (j2sdk1.4) environment. i have also build an ear file with the c2 war file and an application.xml descriptor. in both cases i got the following exception: type fatal message Language Exception description org.apache.cocoon.ProcessingException: Language Exception: org.apache.cocoon.components.language.LanguageException: Error compiling - Original Message - From: Christian Joelly [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, February 04, 2003 12:03 PM Subject: Re: Cocoon 2 with jboss-3.0.4_tomcat-4.1.12 - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cocoon struts together
I dont think that using struts would be useful within an efficient cocoon
site. Cocoon takes another approach to web development that is, in my
opinion, superior to the jsp/struts approach. I do admit that the learnign
curve is high. in fact many on this list can tell you that ive been beatign
up cocoon over that issue a bit. However, I do think that it is worth it in
the end.
-- Robert
- Original Message -
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Monday, February 03, 2003 5:05 PM
Subject: AW: cocoon struts together
Hi Matthew,
Yes of course ;-) There is some experience with struts allready. With cocoon
not so much. And this question is a study about the possibilities. I think
the synergy of both frameworks can (perhaps) realize very powerful
solutioons.
Juraj
-Ursprüngliche Nachricht-
Von: Matthew Langham [mailto:[EMAIL PROTECTED]]
Gesendet: Montag, 3. Februar 2003 16:58
An: [EMAIL PROTECTED]
Betreff: RE: cocoon struts together
Hi Juraj,
like SAP. On this connects a webapplication which should be done
with with struts. Some areas of this application should be
why are you considering Struts (at all)? I am interested in this as we often
meet this kind of setup/discussion and we try to convince people to go for a
Cocoon-only solution (of course) :-)
Matthew
--
Open Source Group Cocoon { Consulting, Training, Projects }
=
Matthew Langham, SN AG, Klingenderstrasse 5, D-33100 Paderborn
Tel:+49-5251-1581-30 [EMAIL PROTECTED] - http://www.s-und-n.de
-
Cocoon book:
http://www.amazon.com/exec/obidos/ASIN/0735712352/needacake-20
Weblogs:
http://radio.weblogs.com/0103021/
http://www.oreillynet.com/weblogs/author/1014
=
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]
Sent: Monday, February 03, 2003 4:46 PM
To: [EMAIL PROTECTED]
Subject: cocoon struts together
Hi,
has someone any experiences with the comosition of struts and cocoon?
I have a middleware on EJB and JCA which connects to some Systems
like SAP. On this connects a webapplication which should be done
with with struts. Some areas of this application should be
transformed by cocoon in different outputs. My idea was to run
some views with cocoon. A struts action would connect a pipeline
from cocoon and passe the file which has to be transformed and visualized.
Any suggestions or practices?
Juraj
-
Please check that your question has not already been answered in the
FAQ before posting. http://xml.apache.org/cocoon/faq/index.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
Please check that your question has not already been answered in the
FAQ before posting. http://xml.apache.org/cocoon/faq/index.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
Please check that your question has not already been answered in the
FAQ before posting. http://xml.apache.org/cocoon/faq/index.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
Please check that your question has not already been answered in the
FAQ before posting. http://xml.apache.org/cocoon/faq/index.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Simple example
Once more ? =) Its in progress. Right now beginner documentation is a little thin. -- Robert - Original Message - From: Stefan Riegel [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, February 03, 2003 8:41 PM Subject: Re: Simple example Alireza Fattahi wrote: Hi, The currently cocoon web application is very complex. Is there any light weight example out there; some thing like blank web application in struts. Alireza. - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Alireza, I remember my first steps with cocoon some time ago. I removed step by step lines from the sitemap until I reached a minimal hello-world application. While removing lines, I did read the comments etc. I was a good exercise. I did plan doing the same with the cocoon.xconf, but I lost patience. Regards Stefan - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cocoon struts together
Actually I'm an EJB specialist and I don't generally work on projects conducive to web interfaces. The complexity level of the stuff I do is too high. (Pharmaceutical industry and genetic research). My customers generally require a higher range of functionality than a web interface can provide. That being said, I do, however, do some web work which is why I took up the idea of cocoon. I use the same technique that I use for GUI programming. Basically a command centric architecture. I hate to say struts is for amateurs but it kind of is. It has low complexity and thus low functionality. It also has high cost in terms of content delivery and maintenance costs. I personally chose to avoid all that and let Java objects do all the work and let the framework just concentrate on presentation. Enter cocoon. My programs consist of allot of specially designed generators that generate pure data. Then I use XSLT to translate that into the appropriate media. I also use XSLT to output the forms though I am experimenting with reflexive techniques that I have used in GUI applications to make generation of forms be based on reflexive command analysis. Frameworks like struts mix functionality with presentation, which IMHO is a very bad thing. Its a high maintenance cost solution with a low development cost. That is the wrong way around. To be professional you want high development cost and low maintenance cost. This causes your feature turn around, post release, to be much faster. Since you are able to react quickly to the demands of your users, your company or customers win. The guy that slapped it together with low development costs may make some sales coming out the door, but will bleed customers as they seek more stable solutions with faster turn-around time for new features and fault correction. I guess that is a long way of saying, put all your work into the back end. Cocoon is perfect for this because you can develop custom generators to deliver data and let a web designer with a couple weeks of training worry about the XSLT translation. In the meantime your valuable programmer resources are implementing new features and stabilizing the product. Well that's my opinion on the matter. -- Robert - Original Message - From: Antonio Gallardo [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, February 04, 2003 11:48 PM Subject: Re: cocoon struts together Robert Simmons dijo: I dont think that using struts would be useful within an efficient cocoon site. Cocoon takes another approach to web development that is, in my opinion, superior to the jsp/struts approach. Thanks for the comment. I was trying to start learning about this stuff. As a bean specialist (a book writer) what tools you recommend to manage all the beans stuff (creation, changes, etc.) Thanks for the comments. Antonio Gallardo - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: curious problem with new instalation--where are the XML files?
I'm afraid you are a bit confused. -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello, I just installed Cocoon on my system and I have an interesting problem. I copied the war package into ~/jboss-3.0.4_tomcat-4.1.12/server/default/deploy and restarted the server using the script: No need. Its a servlet. JBoss will do all the deployment for you. ~/jboss-3.0.4_tomcat-4.1.12/bin/run.sh. I got the welcome page at http://localhost:8080/cocoon/ and I was very happy. Happy is good. =) I ran through several of the samples and lthey seemed neat. This would be great for a personal web site. Anyway, I wanted to do some of the exercises so i entered http://localhost:8080/cocoon/mount and got an error. I decided to find the mount directory. What error did you get ? Cocoon doesnt quite work this way. In cocoon you map a URL to a pipeline, a combination of generator, 0 to n transformers, and a serializer. So all URLS are blocked unless they are mapped to a pipeline. Wheras mount may be mapped to a pipeline, that doesnt guarantee that it will give you a directory view. This is where things get interesting. The cocoon directory was not under ~/jboss-3.0.4_tomcat-4.1.12/tomcat-4.1.x/webapps Why should it be? Its in the WAR file you dropped in the deploy directory. Unpack it and deploy it exploded and you will see what I mean. but under ~/jboss-3.0.4_tomcat-4.1.12/work/mainengine/localhost . I found some files under ~/jboss-3.0.4_tomcat-4.1.12/work/mainengine/localhost/cocoon-files/org/ apache/cocoon/www/jndi_/localhost/cocoon/ but no xml source files No no, thats just a tomcat work directory. Temporary files there. Cocoon takes the sitemap and actually generates a java file and compiles it. It does that stuff in this directory. The only time you should ever have to look here is if you get some strange exception in a sitemap or XSP page and cant figure it out from the XML. Then you can go to the work directory and look up the source. Otherwise forget this directory. Where are the xml source files? Why did the war install Cocoon to such a weird directory? Is not this a strange problem? The war isntalled to your deploy directory. Unpack it with the jar command and you will see all the gory guts of cocoon. You can create a directory named cocoon.war and unpack the actual war file into this directory. Then you can move this directory to the deploy directory of JBoss and it will treat it exactly as if it was a war file. Refer to the JBoss documentation on deploying exploded archives. It is within this war that you will find what you are lookign for. David Novogrodsky http://www.novogrodsky.net -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (Darwin) -- Derisor - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Simple example / XML / XSLT In production
Comparing JAVA to XML is roughly like comparing a outhouse to a Ferrari. They are two totally different things that are made to solve totally different problems. -- Robert - Original Message - From: Adrian Boston [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, February 05, 2003 1:18 AM Subject: RE: Simple example / XML / XSLT In production Actually, I'm comparing xml to java, not product to product. And that was not my opinion; I've been sold on xml for some time; however my experience has been system to system, not webby front-end. Btw. It seems most people like mopeds. Adrian Boston -Original Message- From: Robert Simmons [mailto:[EMAIL PROTECTED]] Sent: Tuesday, February 04, 2003 3:59 PM To: [EMAIL PROTECTED] Subject: Re: Simple example / XML / XSLT In production Huh? JSP has no object hierarchy. JSP is basically a way to write a servlet without having to implement the servlet interfaces. In short it is a shortcut. The end result of JSP is always a servlet (one per JSP page). XML/XSLT is a totally different paradigm. In cocoon generators are used to deliver DATA. This data is in XML form. There is no logic mixed into this data as is the case with JSP. Then The XML data is transformed (very mathematically) into content. This content can be HTML, another XML document such as a soap request, WML, PDF and so on. So, as a matter of fact JSP mixes not only model and view but also model view AND controller. In the cocoon world the Generators and actions are controllers. The XML is the model and the view is accomplished through XSLT transforms. Its the same for XSP. In this case an XSP is translated into, not a servlet like JSP, but a generator. So even though you write an XSP to implement some functionality, this XSP is still going to be spitting out XML which must be transformed into content. Comparing the two is like comparing a moped to a Ferrari. The cocoon way is CLEARLY superior for any number of project planning, resource management and software engineering reasons. -- Derisor - Original Message - From: Adrian Boston [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, February 05, 2003 12:45 AM Subject: RE: Simple example / XML / XSLT In production Ah, thanks for the linx. I was debating xml, xslt versus jsp with a colleague. He noted that although xml, xslt works well in a divided graphics/analyst/developer big team, it eventually was scrapped for JSP. The lack of object hierarchy and polymorphism made changes very difficult. Can anyone provide tales of xml, xslt in a major production? (sans company name, of course) Thanks, -Original Message- From: Yves Vindevogel [mailto:[EMAIL PROTECTED]] Sent: Tuesday, February 04, 2003 3:31 PM To: [EMAIL PROTECTED] Subject: Re: Simple example Jeremy Ashton, who recently published a book on Cocoon, wrote a very good two idots guide to Cocoon. This document is still online somewhere. I guess Jeremy can point it out, he's a frequent reader of this user-list. That document gave me a lot of support and help, back in the days Re: Hopefully some encouragement An introductory document would prove extremely useful for the Cocoon cause, as it sounds great in both concept and implementation. Some of us are in positions to recommend xml, xslt over the forsaken jsp, struts, ejb method, but cannot afford the time to master yet another complex st*nking framework. -Original Message- From: Robert Simmons [mailto:[EMAIL PROTECTED]] Sent: Tuesday, February 04, 2003 2:10 PM To: [EMAIL PROTECTED] Subject: Re: Simple example Once more ? =) Its in progress. Right now beginner documentation is a little thin. -- Robert - Original Message - From: Stefan Riegel [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, February 03, 2003 8:41 PM Subject: Re: Simple example Alireza Fattahi wrote: Hi, The currently cocoon web application is very complex. Is there any light weight example out there; some thing like blank web application in struts. Alireza. - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Alireza, I remember my first steps with cocoon some time ago. I removed step by step lines from the sitemap until I reached a minimal hello-world application. While removing lines, I did read the comments etc. I was a good exercise. I did plan doing the same with the cocoon.xconf, but I lost patience. Regards Stefan - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED
Re: Simple example / XML / XSLT In production
you can have the 100k Porsche, Ill take the half a million dollar Ferrari. I have been doing XSL for quite a while. I'm relatively new to cocoon, not to XML. People that use XML for logic and programming need to have their head examined IMHO. -- Robert - Original Message - From: Adrian Boston [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, February 05, 2003 1:34 AM Subject: RE: Simple example / XML / XSLT In production Oh. OK. We shall see when you start programming in xml, xslt, xpath, xthis, xthat. Unless you're well endowed with a bushy moustache and still love disco, I'd recommend stay away from Ferrari's. Move on up to a Porsche. -Original Message- From: Robert Simmons [mailto:[EMAIL PROTECTED]] Sent: Tuesday, February 04, 2003 4:27 PM To: [EMAIL PROTECTED] Subject: Re: Simple example / XML / XSLT In production Comparing JAVA to XML is roughly like comparing a outhouse to a Ferrari. They are two totally different things that are made to solve totally different problems. -- Robert - Original Message - From: Adrian Boston [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, February 05, 2003 1:18 AM Subject: RE: Simple example / XML / XSLT In production Actually, I'm comparing xml to java, not product to product. And that was not my opinion; I've been sold on xml for some time; however my experience has been system to system, not webby front-end. Btw. It seems most people like mopeds. Adrian Boston -Original Message- From: Robert Simmons [mailto:[EMAIL PROTECTED]] Sent: Tuesday, February 04, 2003 3:59 PM To: [EMAIL PROTECTED] Subject: Re: Simple example / XML / XSLT In production Huh? JSP has no object hierarchy. JSP is basically a way to write a servlet without having to implement the servlet interfaces. In short it is a shortcut. The end result of JSP is always a servlet (one per JSP page). XML/XSLT is a totally different paradigm. In cocoon generators are used to deliver DATA. This data is in XML form. There is no logic mixed into this data as is the case with JSP. Then The XML data is transformed (very mathematically) into content. This content can be HTML, another XML document such as a soap request, WML, PDF and so on. So, as a matter of fact JSP mixes not only model and view but also model view AND controller. In the cocoon world the Generators and actions are controllers. The XML is the model and the view is accomplished through XSLT transforms. Its the same for XSP. In this case an XSP is translated into, not a servlet like JSP, but a generator. So even though you write an XSP to implement some functionality, this XSP is still going to be spitting out XML which must be transformed into content. Comparing the two is like comparing a moped to a Ferrari. The cocoon way is CLEARLY superior for any number of project planning, resource management and software engineering reasons. -- Derisor - Original Message - From: Adrian Boston [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, February 05, 2003 12:45 AM Subject: RE: Simple example / XML / XSLT In production Ah, thanks for the linx. I was debating xml, xslt versus jsp with a colleague. He noted that although xml, xslt works well in a divided graphics/analyst/developer big team, it eventually was scrapped for JSP. The lack of object hierarchy and polymorphism made changes very difficult. Can anyone provide tales of xml, xslt in a major production? (sans company name, of course) Thanks, -Original Message- From: Yves Vindevogel [mailto:[EMAIL PROTECTED]] Sent: Tuesday, February 04, 2003 3:31 PM To: [EMAIL PROTECTED] Subject: Re: Simple example Jeremy Ashton, who recently published a book on Cocoon, wrote a very good two idots guide to Cocoon. This document is still online somewhere. I guess Jeremy can point it out, he's a frequent reader of this user-list. That document gave me a lot of support and help, back in the days Re: Hopefully some encouragement An introductory document would prove extremely useful for the Cocoon cause, as it sounds great in both concept and implementation. Some of us are in positions to recommend xml, xslt over the forsaken jsp, struts, ejb method, but cannot afford the time to master yet another complex st*nking framework. -Original Message- From: Robert Simmons [mailto:[EMAIL PROTECTED]] Sent: Tuesday, February 04, 2003 2:10 PM To: [EMAIL PROTECTED] Subject: Re: Simple example Once more ? =) Its in progress. Right now beginner documentation is a little thin. -- Robert - Original Message - From: Stefan Riegel [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, February 03, 2003 8:41 PM Subject: Re: Simple example Alireza Fattahi wrote: Hi, The currently cocoon web application is very complex. Is there any light weight example out there; some thing like blank web application in struts. Alireza
Re: [OT] RE: cocoon struts together
Struts is a horrible basis for business logic for a thousand reasons. Business logic best lives within an enterprise container and an application server. The basis of concurrency, fault tolerance, transaction management, clustering and the rest of the EJB contract make it pretty psycho to NOT use it. I would NEVER EVER do anything important in any web framework, be it cocoon or struts. No thanks the J2EE environment is the god of business logic as cocoon is, IMHO, the god of web presentation. Cocoon should be a CONSUMER of the J2EE functionality and not make any decisions whatsoever. Many people whip up some struts-JSP based applications, which basically become servlets, and then pretend that the problems are solved. I could list a thousand ways this paradigm is garbage, but I really don't have to because other books do it quite well for me. My advice to you is to use EJB and J2EE on the back end, cocoon on the web end, JDO for persistence and Swing for complex clients. -- Robert - Original Message - From: Todd Pierce [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, February 05, 2003 1:36 AM Subject: [OT] RE: cocoon struts together Re the comment Frameworks like struts mix functionality with presentation The presumption that functionality and presentation are mixed in Struts needs qualification. Struts is an application framework. It's most valuable component is the application layer. The presentation layer don't have to be JSP/taglib. You can serve out xml for presentation if you wish, or (shudder) even Flash. Reasonable separation of functionality and presentation can be achieved using any framework, if you follow 2 simple rules: Rule 1 - ensure that the application layer does not generate any presentation. Rule 2 - ensure that the presentation layer does not make any decisions. I use a tiles-based template system, with screens defined in an XML doc, but y'know, what-ever. I'm not trying to sell Struts to hardened Cocoon users. I use both Cocoon and Struts, but not together. Cocoon for data delivery systems, because of its fantastic separation of content and presentation, and Struts for business applications simply because it's such a good application framework. I don't believe either of these technologies should be considered to be a panacaea for the ills of the web world. -Original Message- From: Robert Simmons [mailto:[EMAIL PROTECTED]] Sent: Wednesday, 5 February 2003 10:43 AM To: [EMAIL PROTECTED] Subject: Re: cocoon struts together Actually I'm an EJB specialist and I don't generally work on projects conducive to web interfaces. The complexity level of the stuff I do is too high. (Pharmaceutical industry and genetic research). My customers generally require a higher range of functionality than a web interface can provide. That being said, I do, however, do some web work which is why I took up the idea of cocoon. I use the same technique that I use for GUI programming. Basically a command centric architecture. I hate to say struts is for amateurs but it kind of is. It has low complexity and thus low functionality. It also has high cost in terms of content delivery and maintenance costs. I personally chose to avoid all that and let Java objects do all the work and let the framework just concentrate on presentation. Enter cocoon. My programs consist of allot of specially designed generators that generate pure data. Then I use XSLT to translate that into the appropriate media. I also use XSLT to output the forms though I am experimenting with reflexive techniques that I have used in GUI applications to make generation of forms be based on reflexive command analysis. Frameworks like struts mix functionality with presentation, which IMHO is a very bad thing. Its a high maintenance cost solution with a low development cost. That is the wrong way around. To be professional you want high development cost and low maintenance cost. This causes your feature turn around, post release, to be much faster. Since you are able to react quickly to the demands of your users, your company or customers win. The guy that slapped it together with low development costs may make some sales coming out the door, but will bleed customers as they seek more stable solutions with faster turn-around time for new features and fault correction. I guess that is a long way of saying, put all your work into the back end. Cocoon is perfect for this because you can develop custom generators to deliver data and let a web designer with a couple weeks of training worry about the XSLT translation. In the meantime your valuable programmer resources are implementing new features and stabilizing the product. Well that's my opinion on the matter. -- Robert - Original Message - From: Antonio Gallardo [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, February 04, 2003 11:48 PM Subject: Re: cocoon struts together
Re: cocoon struts together
It was a painful road and I'm still nursing the bruises. But ya, I see its value. -- Robert - Original Message - From: Antonio Gallardo [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, February 05, 2003 1:55 AM Subject: Re: cocoon struts together Thanks for the answer. Good speach. I saw you now as a Cocoon fan! :-) You finally saw the light at the end of the pipeline. ;-) Best Regards, Antonio Gallardo. Robert Simmons dijo: Actually I'm an EJB specialist and I don't generally work on projects conducive to web interfaces. The complexity level of the stuff I do is too high. (Pharmaceutical industry and genetic research). My customers generally require a higher range of functionality than a web interface can provide. That being said, I do, however, do some web work which is why I took up the idea of cocoon. I use the same technique that I use for GUI programming. Basically a command centric architecture. I hate to say struts is for amateurs but it kind of is. It has low complexity and thus low functionality. It also has high cost in terms of content delivery and maintenance costs. I personally chose to avoid all that and let Java objects do all the work and let the framework just concentrate on presentation. Enter cocoon. My programs consist of allot of specially designed generators that generate pure data. Then I use XSLT to translate that into the appropriate media. I also use XSLT to output the forms though I am experimenting with reflexive techniques that I have used in GUI applications to make generation of forms be based on reflexive command analysis. Frameworks like struts mix functionality with presentation, which IMHO is a very bad thing. Its a high maintenance cost solution with a low development cost. That is the wrong way around. To be professional you want high development cost and low maintenance cost. This causes your feature turn around, post release, to be much faster. Since you are able to react quickly to the demands of your users, your company or customers win. The guy that slapped it together with low development costs may make some sales coming out the door, but will bleed customers as they seek more stable solutions with faster turn-around time for new features and fault correction. I guess that is a long way of saying, put all your work into the back end. Cocoon is perfect for this because you can develop custom generators to deliver data and let a web designer with a couple weeks of training worry about the XSLT translation. In the meantime your valuable programmer resources are implementing new features and stabilizing the product. Well that's my opinion on the matter. -- Robert - Original Message - From: Antonio Gallardo [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, February 04, 2003 11:48 PM Subject: Re: cocoon struts together Robert Simmons dijo: I dont think that using struts would be useful within an efficient cocoon site. Cocoon takes another approach to web development that is, in my opinion, superior to the jsp/struts approach. Thanks for the comment. I was trying to start learning about this stuff. As a bean specialist (a book writer) what tools you recommend to manage all the beans stuff (creation, changes, etc.) Thanks for the comments. Antonio Gallardo - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Please check that your question has not already been answered in the FAQ before posting. http://xml.apache.org/cocoon/faq/index.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Simple example / XML / XSLT In production
What exactly does this attitude serve. If you don't want people's opinion, don't post to a public mailing list. Enough of this topic, its quite clear that you value your sarcasm over honest answers. -- Robert - Original Message - From: Adrian Boston [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, February 05, 2003 2:12 AM Subject: RE: Simple example / XML / XSLT In production Greaaat. Thanks for saving me a couple of weeks work. I'll make a note in my documents, Robert said XML was OK. It's fine to hold you responsible right? Once again, as carefully noted in my first post: a) not my opinion. b) xml is cool. If you want to comment on your xml success in your production systems, great, otherwise, drsvp. -Original Message- From: Robert Simmons [mailto:[EMAIL PROTECTED]] Sent: Tuesday, February 04, 2003 4:44 PM To: [EMAIL PROTECTED] Subject: Re: Simple example / XML / XSLT In production you can have the 100k Porsche, Ill take the half a million dollar Ferrari. I have been doing XSL for quite a while. I'm relatively new to cocoon, not to XML. People that use XML for logic and programming need to have their head examined IMHO. -- Robert - Original Message - From: Adrian Boston [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, February 05, 2003 1:34 AM Subject: RE: Simple example / XML / XSLT In production Oh. OK. We shall see when you start programming in xml, xslt, xpath, xthis, xthat. Unless you're well endowed with a bushy moustache and still love disco, I'd recommend stay away from Ferrari's. Move on up to a Porsche. -Original Message- From: Robert Simmons [mailto:[EMAIL PROTECTED]] Sent: Tuesday, February 04, 2003 4:27 PM To: [EMAIL PROTECTED] Subject: Re: Simple example / XML / XSLT In production Comparing JAVA to XML is roughly like comparing a outhouse to a Ferrari. They are two totally different things that are made to solve totally different problems. -- Robert - Original Message - From: Adrian Boston [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, February 05, 2003 1:18 AM Subject: RE: Simple example / XML / XSLT In production Actually, I'm comparing xml to java, not product to product. And that was not my opinion; I've been sold on xml for some time; however my experience has been system to system, not webby front-end. Btw. It seems most people like mopeds. Adrian Boston -Original Message- From: Robert Simmons [mailto:[EMAIL PROTECTED]] Sent: Tuesday, February 04, 2003 3:59 PM To: [EMAIL PROTECTED] Subject: Re: Simple example / XML / XSLT In production Huh? JSP has no object hierarchy. JSP is basically a way to write a servlet without having to implement the servlet interfaces. In short it is a shortcut. The end result of JSP is always a servlet (one per JSP page). XML/XSLT is a totally different paradigm. In cocoon generators are used to deliver DATA. This data is in XML form. There is no logic mixed into this data as is the case with JSP. Then The XML data is transformed (very mathematically) into content. This content can be HTML, another XML document such as a soap request, WML, PDF and so on. So, as a matter of fact JSP mixes not only model and view but also model view AND controller. In the cocoon world the Generators and actions are controllers. The XML is the model and the view is accomplished through XSLT transforms. Its the same for XSP. In this case an XSP is translated into, not a servlet like JSP, but a generator. So even though you write an XSP to implement some functionality, this XSP is still going to be spitting out XML which must be transformed into content. Comparing the two is like comparing a moped to a Ferrari. The cocoon way is CLEARLY superior for any number of project planning, resource management and software engineering reasons. -- Derisor - Original Message - From: Adrian Boston [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, February 05, 2003 12:45 AM Subject: RE: Simple example / XML / XSLT In production Ah, thanks for the linx. I was debating xml, xslt versus jsp with a colleague. He noted that although xml, xslt works well in a divided graphics/analyst/developer big team, it eventually was scrapped for JSP. The lack of object hierarchy and polymorphism made changes very difficult. Can anyone provide tales of xml, xslt in a major production? (sans company name, of course) Thanks, -Original Message- From: Yves Vindevogel [mailto:[EMAIL PROTECTED]] Sent: Tuesday, February 04, 2003 3:31 PM To: [EMAIL PROTECTED] Subject: Re: Simple example Jeremy Ashton, who recently published a book on Cocoon, wrote a very good two idots guide to Cocoon. This document is still online somewhere. I guess Jeremy can point it out, he's a frequent reader of this user-list. That document gave me a lot of support and help, back in the days Re: Hopefully some encouragement An introductory document would prove extremely useful for the Cocoon cause
