Re: EJB + Cocoon, Best Practices
Reinhard Poetz wrote: From: Joerg Heinicke Not until now though it was planned and we finished work 2 months ago. I know we have a presentation system, which is normally not reachable from outside. I will ask the /decision-makers/ tomorrow :-) Thanks for your interest, Joerg PS: Reinhard also asked some time ago when we haven't finished it. Yep, I was very impressed by that you showed me. It's also the first business application that uses XUL. So the work of your company could encourage many people using XUL - in the future XUL is an equivalent possibility how to create the UI. Reinhard IIRC you only have seen the help :-) Now you can see the real application from the users view: url: http://conweb.virbus.de/ login: cocoon password: usingxul *Before* you can use it, you unfortunately have to prepare your Mozilla. This is because of the default security restrictions of Mozilla, where you are not even asked if you want to grant permissions to scripts to access the XPConnect object. Adding a user.js to your Mozilla profile (do you know where to find it?) that contains the line (or simply adding the line to an existing user.js) user_pref(signed.applets.codebase_principal_support, true); changes this behaviour (after a Mozilla restart) and you are asked to grant permissions. The XPConnect object is needed for access on RDFDataSources. (See http://www.mozilla.org/rdf/doc/faq.html#rdf_examples for more information. There is something written about this line.) Furthermore Mozilla's bugzilla already contains a bug at this topic for simplifying this handling in the future: http://bugzilla.mozilla.org/show_bug.cgi?id=122846. The application itself: It's a controlling tool for (not only) venture capital companies. The work was done before using Excel sheets, now with a self developed J2EE component WebSheet, the ConWeb application (also J2EE) in the backend and the XUL application in the frontend. So this application should replace Excel ;-) The sheets can be exported in PDF and Excel. Though the application is completely i18n-ed, the application is only available in German at the moment. There is also an online help (with an additional context sensitive mode), but this is in German too. (It is also available outside the app, but with some JavaScript errors then: http://conweb.virbus.de/conweb/conweb/help.xul. This is what Reinhard already saw IIRC.) The usage of Cocoon is relative low, but effectively. (I'm working on a Struts app with JSP at the moment and I really don't love it.) It delivers all resources, does the transformations and serializations, so it only handles the view. The connection to the backend is handled by an EJBConnectorAction and a FilterGenerator. The advantage of XUL are the static pages, every user in every role gets the same static XUL files. They are personnalized through RDF and CSS. For example an admin has more tabs as you can see in one screenshot in the help. With the RDF and the template mechanism, the data can be easily updated without updating/reloading the XUL files. You only update the data. The app is based on Cocoon 2.0.4, JBoss 3.0.6 and Tomcat 4.1.18. We switched off Cocoon's caching completely, because of the bug http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17924 for the static resources and our non-cachable generator (the caching is prepared in the FilterDocuments, but the generator does not handle it at the moment). This gave us a big performance improvement (from 600 to below 100 ms for a simply sheet). I hope I have not written to much ... Regards, Joerg -- System Development VIRBUS AG Fon +49(0)341-979-7419 Fax +49(0)341-979-7409 [EMAIL PROTECTED] www.virbus.de - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Forms + XUL (Was: Re: EJB + Cocoon, Best Practices)
Tony Collen wrote:
Reinhard Poetz wrote:
snip/
Yep, I was very impressed by that you showed me. It's also the first
business application that uses XUL. So the work of your company could
encourage many people using XUL - in the future XUL is an equivalent
possibility how to create the UI.
Hrmm... this makes me wonder if there's any sort of cool way that we
can connect something like Woody and XUL for really cool forms.
Imagine a formerly multi-page form that is sent to the client in one
shot, and appears as a tabbed set of widgets hmmm *gears turning*
You should check out the Woody samples (Various and Flowscript
pages) in the latest CVS : it includes tabbed forms, switching panels
with a popup to select the panel, etc. It's based on some high-level
grouping tags that automatically produce the needed HTML, CSS and
JavaScript stuff.
I also added yesterday server-side event handling features, and the
ability for a widget to trigger form submit. Checkout the carselector
sample (updated a few minutes ago) that demonstrates this, and also the
number panel in the Various page.
It certainly doesn't provide the same user experience as Joerg's
impressive XUL application but, well... works on any browser ;-)
Of course, we could also have stylesheets producing XUL for Woody forms.
Any taker ?
Enjoy,
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance - http://www.orixo.com
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: EJB + Cocoon, Best Practices
From: Joerg Heinicke Not until now though it was planned and we finished work 2 months ago. I know we have a presentation system, which is normally not reachable from outside. I will ask the /decision-makers/ tomorrow :-) Thanks for your interest, Joerg PS: Reinhard also asked some time ago when we haven't finished it. Yep, I was very impressed by that you showed me. It's also the first business application that uses XUL. So the work of your company could encourage many people using XUL - in the future XUL is an equivalent possibility how to create the UI. Reinhard - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: EJB + Cocoon, Best Practices
From: Reinhard Poetz From: Joerg Heinicke Not until now though it was planned and we finished work 2 months ago. I know we have a presentation system, which is normally not reachable from outside. I will ask the /decision-makers/ tomorrow :-) Thanks for your interest, Joerg PS: Reinhard also asked some time ago when we haven't finished it. Yep, I was very impressed by that you showed me. It's also the first business application that uses XUL. ... of course the first business appliation I know from ;) So the work of your company could encourage many people using XUL - in the future XUL is an equivalent possibility how to create the UI. Reinhard - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Forms + XUL (Was: Re: EJB + Cocoon, Best Practices)
Reinhard Poetz wrote: snip/ Yep, I was very impressed by that you showed me. It's also the first business application that uses XUL. So the work of your company could encourage many people using XUL - in the future XUL is an equivalent possibility how to create the UI. Hrmm... this makes me wonder if there's any sort of cool way that we can connect something like Woody and XUL for really cool forms. Imagine a formerly multi-page form that is sent to the client in one shot, and appears as a tabbed set of widgets hmmm *gears turning* Tony - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Forms + XUL (Was: Re: EJB + Cocoon, Best Practices)
WOW Great idea. That would be COOL. -M Michael McConnellPerficient, Inc. - Advanced Technology ServicesSRS Extension: 785-296-4854Perficient, Inc email: [EMAIL PROTECTED]Mobile: 952-240-3940"All truth passes through three stages. First, it is ridiculed, second it is violently opposed, and third, it is accepted as self-evident." (Arthur Schopenhauer) [EMAIL PROTECTED] 9/24/2003 7:22:37 AM Reinhard Poetz wrote:snip/ Yep, I was very impressed by that you showed me. It's also the first business application that uses XUL. So the work of your company could encourage many people using XUL - in the future XUL is an equivalent possibility how to create the UI.Hrmm... this makes me wonder if there's any sort of cool way that we can connect something like Woody and XUL for really cool forms. Imagine a formerly multi-page form that is sent to the client in one shot, and appears as a tabbed set of widgets hmmm *gears turning*Tony-To unsubscribe, e-mail: [EMAIL PROTECTED]For additional commands, e-mail: [EMAIL PROTECTED]
Re: EJB + Cocoon, Best Practices
Niclas Hedhman wrote: On Monday 22 September 2003 06:29, Joerg Heinicke wrote: We used EJB + Cocoon 2.0.4 for our project ConWeb. Is this a Internet site where you con, scam, cheat and defraud people? ;o) Such a negative word! But of course not: http://conweb.virbus.de (XUL application = Mozilla). Joerg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: EJB + Cocoon, Best Practices (became Flow Script discussion )
there are a few reasons we didn't use flow scripts even though they are quite cool technologically. -- we wanted to execute a series of actions which can not only follow different paths like selectors but can also emit XML which is concatenated into the response stream. there's no cocoon component like this so we're already into custom code. -- flow scripts seem to present the same problem as ASPs, JSPs, and XSPs in that too much process logic ends up on the web server, disjoined from the business objects they work with. granted, if you write them correctly they are simple, but i've never seen this in practice. it's too tempting for someone to put code in the view layer to just get it done -- flow scripts encourage you to link multiple pages together into a series, but i think this is a bad idea in terms of maintenance. on any given page of our site, there are 20-50 outlinks for the user to choose from, so it's very important for us to maintain modularity between pages. to achive this, we've broken our backend actions into two parts: actions you invoke while leaving page A and actions you invoke while entering page B. we then can mix-and-match page A to page C or C to B etc. writing flow scripts which cross page boundries would make our navigation logic a nightmare. -- the action engine we wrote not only handles long-running-request continuations but can also provide an updated view of the data processing. that is, our long-running backend actions can iteratively add data to the response stream, and our continuation controller will display whatever results have been given so far. this allows us to do things like show progress bars that change with every refresh. while a flow script could be made to do this, you would have to (artifically) break your long-running process into multiple stages and return different pages between each. in our solution, you can have a single long-running stage and a single progress page. -Original Message- From: Christopher Oliver [mailto:[EMAIL PROTECTED] Sent: Monday, September 22, 2003 11:33 PM To: [EMAIL PROTECTED] Subject: Re: EJB + Cocoon, Best Practices Tim Olson wrote: to get EJBs into cocoon, we have a custom Action / Generator pair. the action can be configured to make any EJB call (uses reflection) and stuff the results into a HashMap. the custom generator then sends that hashmap through Castor to generate SAX events. it's very nice, since we can turn any series of ejb calls into XML data with just a few lines of sitemap code. note: remote interfaces are tricky to castorize so use the value object (aka data transfer object) pattern. we eschewed flow scripts and wrote our own action engine, but i should post separately about that. Why did you eschew flow scripts? Just curious. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: EJB + Cocoon, Best Practices (became Flow Script discussion )
Tim Olson wrote: there are a few reasons we didn't use flow scripts even though they are quite cool technologically. snip type=nice rationale/ Out of the blue: did you take a look at the (hopelessly underdocumented) Apples controller? /Steven -- Steven Noelshttp://outerthought.org/ Outerthought - Open Source Java XMLAn Orixo Member Read my weblog athttp://blogs.cocoondev.org/stevenn/ stevenn at outerthought.orgstevenn at apache.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: EJB + Cocoon, Best Practices
Not until now though it was planned and we finished work 2 months ago. I know we have a presentation system, which is normally not reachable from outside. I will ask the /decision-makers/ tomorrow :-) Thanks for your interest, Joerg PS: Reinhard also asked some time ago when we haven't finished it. Upayavira wrote: Joerg, Do you have a demo account on this site? I'd really love to see a XUL based site at work. Regards, Upayavira Joerg Heinicke wrote: Niclas Hedhman wrote: On Monday 22 September 2003 06:29, Joerg Heinicke wrote: We used EJB + Cocoon 2.0.4 for our project ConWeb. Is this a Internet site where you con, scam, cheat and defraud people? ;o) Such a negative word! But of course not: http://conweb.virbus.de (XUL application = Mozilla). Joerg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: EJB + Cocoon, Best Practices
See http://cocoon.apache.org/2.1/userdocs/flow/index.html Also please look at the Flowscript samples in the core and in the Petstore block rather than in Woody. Other than for Woody, Flowscript should be stable, usable, and documented. Regards, Chris - Original Message - I checked what I could find in terms of documentation and code related to the Flow, certainly I am missing something (is there is a document that clearly presents Flow from a conceptual to a lower level?). My objection is that so much emphasis has been made in terms of using as much as possible the sitemap and sitemap components, so applications are easily maintainable, and all of a sudden I see this Flow concept in which one really ends up burying the page chaining info in Javascript. Because that's what I see in the form2xml.flow example: the invocation of form2-display-pipeline and form2-success-pipeline is hardcoded in the binding_example.js script. That's totally the opposite of the sitemap concept. I really don't know how this could be done, but I would like to see that type of information specified in some sort of pipeline too. Sorry for my ignorance... jlerm - Original Message - From: Geoff Howard [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, September 08, 2003 8:28 PM Subject: Re: EJB + Cocoon, Best Practices Bastian Breithaupt wrote: Hi! I would like to set up a Model2 application with Cocoon end EJBs. Cocoon would be the presentation layer (also the controller layer?) and the business logic would be represented by the EJBs. (?) Excellent - I have always thought this use needed more press. Are there any Best Practices for Cocoon working with EJBs? (suggestions, links, publications, documentation, ...) Unfortunately, precious little has been written about the subject. Those who have used Cocoon and EJBs have not written much about it. I suppose, calling the EJB-API is done by Cocoon-Actions...? (for example by using business delegation pattern) When using flow scripts, does it make sense to use actions? (how mature is flow script?) Usually you would not need to call actions and flow. As you are designing from scratch, I'd recommend starting with flow. If done right, your logic would be re-usable as an action should the need arise. Conceptually flow will probably turn out to be pretty stable. The implementation is fairly new so using it may turn up unexpected issues. The good news is that most developers are paying a lot of attention to it, so there may be quick turn-around on resolving whatever comes up. In the end, the flow is just supposed to glue together your business logic especially as it relates to page flow within your application. This may make its young age less important. Any help, hint, link, ... is appreciated. No links that I'm aware of, but there are several people on list interested in writing up some examples of EJB and Cocoon who I'm sure would help you navigate the process. Give a little info about your specific needs/questions and some useful info is bound to turn up. For starters, are your EJBs on a remote server from Cocoon? Geoff - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: EJB + Cocoon, Best Practices
Joerg! we implemented a similar system to bind to our EJBs. it makes me wonder whether this kind of system should be present in the standard cocoon package. i'd really like to see a a selector which can also generate sax events, so you can trigger a sequence of backend actions which give output. in our system, the output gets collected into a hashmap which a custom generator transforms into sax events. -Original Message- From: Joerg Heinicke [mailto:[EMAIL PROTECTED] Sent: Sunday, September 21, 2003 6:29 PM To: [EMAIL PROTECTED] Subject: Re: EJB + Cocoon, Best Practices We used EJB + Cocoon 2.0.4 for our project ConWeb. We have an EJBConnectorAction that handles the authorization and calls a WorkFlowBean with the request information. This one is calling actions doing the business logic. It returns the workflow information in a HashMap, the sitemap decides on this information which generator to call (e.g. simple XML or FilterGenerator). The FilterGenerator knows the components to call in the backend, especially a prepared FilterDocument. The FilterGenerator gets the SAX events directly from the backend without any XML binding. The advantage is the cacheability of the FilterDocuments. They can be reused on the next request (the caching is only not implemented in the generator until now). The architecture is highly pluggable. Joerg Bastian Breithaupt wrote: Hi! I would like to set up a Model2 application with Cocoon end EJBs. Cocoon would be the presentation layer (also the controller layer?) and the business logic would be represented by the EJBs. (?) Are there any Best Practices for Cocoon working with EJBs? (suggestions, links, publications, documentation, ...) I suppose, calling the EJB-API is done by Cocoon-Actions...? (for example by using business delegation pattern) When using flow scripts, does it make sense to use actions? (how mature is flow script?) Any help, hint, link, ... is appreciated. Thank you in advance, Bastian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: EJB + Cocoon, Best Practices
On Monday 22 September 2003 06:29, Joerg Heinicke wrote: We used EJB + Cocoon 2.0.4 for our project ConWeb. Is this a Internet site where you con, scam, cheat and defraud people? ;o) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: EJB + Cocoon, Best Practices
Tim, why don't you consider droping your custom generator in favor of the CastorTransformer ? Castor is - amongst other things - an XML binding framework that allows you un/marshall arbitrary obejct hierarchies to/from XML. In other words, you'd still use your actions to make the actual EJB call and have the data returned to you. But rather than stuffing them into a HashMap and have your custom generator produce the SAX events off this data, I'd bind the object (hierarchy) returned into teh HttpRequest or the HttpSession and have the CastorTransformer marshall the object(s) to XML. All that is required - that is, if you are not pleased by the default marshalling provided out of the box - is a binding file that defines simple rules how the XML should look like (rather than relying on reflection to derive the names of the XML elements/attributes). Werner On Wed, 10 Sep 2003 00:29:02 +0200, Christoph Gaffga wrote: On Tue, 9 Sep 2003 16:21:26 -0400, Tim Olson wrote: to get EJBs into cocoon, we have a custom Action / Generator pair. the action can be configured to make any EJB call (uses reflection) and stuff the results into a HashMap. the custom generator then sends that hashmap through Castor to generate SAX events. it's very nice, since we can turn any series of ejb calls into XML data with just a few lines of sitemap code. note: remote interfaces are tricky to castorize so use the value object (aka data transfer object) pattern. we eschewed flow scripts and wrote our own action engine, but i should post separately about that. -Original Message- From: Bastian Breithaupt [mailto:[EMAIL PROTECTED] Sent: Monday, September 08, 2003 5:33 PM To: [EMAIL PROTECTED] Subject: EJB + Cocoon, Best Practices Hi! I would like to set up a Model2 application with Cocoon end EJBs. Cocoon would be the presentation layer (also the controller layer?) and the business logic would be represented by the EJBs. (?) Are there any Best Practices for Cocoon working with EJBs? (suggestions, links, publications, documentation, ...) I suppose, calling the EJB-API is done by Cocoon-Actions...? (for example by using business delegation pattern) When using flow scripts, does it make sense to use actions? (how mature is flow script?) Any help, hint, link, ... is appreciated. Thank you in advance, Bastian __ 38xTestsieger - WEB.DE FreeMail - Deutschlands beste E-Mail Jeden Monat mit 10% mehr Leistung! http://f.web.de/?mc=021138 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: EJB + Cocoon, Best Practices / Betwixt
can you briefly explain the differences between the two transformers. Whilst I am very familiar with the CastorTransformer (and Castor XML/JDO), I'd appreciate a quick overview of the functionality of the BetwixtTransformer, and what advantages it would offer to using the CastorTransformer. I just compared some XML-Binding frameworks like JAXB, Castor, XMLBeans, JiBX etc. The one I most liked was Betwixt. It is very easy to use, produces SAX events, it works with EJBs RemoteInterface, easy to use mapping files, clean XML, supports Maps and Collection in a way I like it. And it is more Beans-centric, good if you want to use your existing beans (Castor is more Schema-centric, I think). Some links: How does Betwixt compare to technologies like JAXB and Castor? http://jakarta.apache.org/commons/betwixt/faq.html#comparison Writing Entity Beans http://jakarta.apache.org/commons/betwixt/guide/writing.html#EJB And the javadoc for BetwixtTransformer: Betwixt transformer marshals a object from the Sitemap, Session, Request or the Conext into a series of SAX events. Configuation: The betwixt transformer can be configured to not output element reference ids. The default setting is to output reference IDs. map:transformer name=betwixt src=org.apache.cocoon.transformation.BetwixtTransformer ref-idstrue/ref-ids /map:transformer Sample: root xmlns:betwixt=http://apache.org/cocoon/betwixt-transfomer; betwixt:include name=invoice/ betwixt:include name=product scope=sitemap/ betwixt:include name=product2 element=other-product/ /root The BetwixtTransfomer support only one Element betwixt:include. This element is replaced with the marshalled object. The Object given through the attribute name will be searched in the request, session, context and at least in sitemap. If the scope is explicitly given, the object will ge located only there. The attribute element can be given to specify an alternativ root element for the object. Collections are marshalled by marshalling each object it contains. @see Betwixt Projekt Homepage (http://jakarta.apache.org/commons/betwixt/) @author Christoph Gaffga ([EMAIL PROTECTED]) So, you see, it's very similar to the CastorTransformer usage. If you test it, let me here, what you think about. regards Christoph - Original Message - From: Werner Guttmann [EMAIL PROTECTED] To: Christoph Gaffga [EMAIL PROTECTED]; [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Wednesday, September 10, 2003 10:04 AM Subject: Re: EJB + Cocoon, Best Practices / Betwixt Christoph, can you briefly explain the differences between the two transformers. Whilst I am very familiar with the CastorTransformer (and Castor XML/JDO), I'd appreciate a quick overview of the functionality of the BetwixtTransformer, and what advantages it would offer to using the CastorTransformer. that invokes the EJB and returns the DTO. It then passes the DTO to Betwixt which converts it to SAX events. I posted the BeanGenerator on the list a Perheaps you are also interested in a BetwixtTransformer, analoge to CastorTransformer? I post it here, perheaps anyone can put it in the scratchpad? regards Christoph org.apache.cocoon.tranformation.BetwixtTransformer: --- /* === = The Apache Software License, Version 1.1 === = Copyright (C) 1999-2003 The Apache Software Foundation. All rights reserved. Redistribution and use in source and binary forms, with or without modifica- tion, are permitted provided that the following conditions are met: 1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. 2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. 3. The end-user documentation included with the redistribution, if any, must include the following acknowledgment: This product includes software developed by the Apache Software Foundation (http://www.apache.org/). Alternately, this acknowledgment may appear in the software itself, if and wherever such third-party acknowledgments normally appear. 4. The names Apache Cocoon and Apache Software Foundation must not be used to endorse or promote products derived from this software without prior written permission. For written permission, please contact [EMAIL PROTECTED] 5. Products derived from this software may not be called Apache, nor may Apache appear in their name, without prior written permission of the Apache Software Foundation. THIS SOFTWARE
Re: EJB + Cocoon, Best Practices / Betwixt
Christoph, thanks for the explanation(s) and the links. I'll definitely read up on some of these things. Just a few comments inline, though. On Wed, 10 Sep 2003 12:28:42 +0200, Christoph Gaffga wrote: can you briefly explain the differences between the two transformers. Whilst I am very familiar with the CastorTransformer (and Castor XML/JDO), I'd appreciate a quick overview of the functionality of the BetwixtTransformer, and what advantages it would offer to using the CastorTransformer. I just compared some XML-Binding frameworks like JAXB, Castor, XMLBeans, JiBX etc. The one I most liked was Betwixt. It is very easy to use, produces SAX events, it works with EJBs RemoteInterface, easy to use mapping files, clean XML, supports Maps and Collection in a way I like it. And it is more Beans-centric, good if you want to use your existing beans (Castor is more Schema-centric, I think). Castor can work in both modes. Iow, use existing beans/Java classes by supplying a binding file, or start with a XML Schema and have FieldHandlers generated for you that assist you in un-/marshalling to/from XML. Some links: How does Betwixt compare to technologies like JAXB and Castor? http://jakarta.apache.org/commons/betwixt/faq.html#comparison Writing Entity Beans http://jakarta.apache.org/commons/betwixt/guide/writing.html#EJB And the javadoc for BetwixtTransformer: Betwixt transformer marshals a object from the Sitemap, Session, Request or the Conext into a series of SAX events. Configuation: The betwixt transformer can be configured to not output element reference ids. The default setting is to output reference IDs. map:transformer name=betwixt src=org.apache.cocoon.transformation.BetwixtTransformer ref-idstrue/ref-ids /map:transformer Sample: root xmlns:betwixt=http://apache.org/cocoon/betwixt-transfomer; betwixt:include name=invoice/ betwixt:include name=product scope=sitemap/ betwixt:include name=product2 element=other-product/ /root Very similar, indeed .. ;-). The BetwixtTransfomer support only one Element betwixt:include. This element is replaced with the marshalled object. The Object given through the attribute name will be searched in the request, session, context and at least in sitemap. If the scope is explicitly given, the object will ge located only there. The attribute element can be given to specify an alternativ root element for the object. Collections are marshalled by marshalling each object it contains. @see Betwixt Projekt Homepage (http://jakarta.apache.org/commons/betwixt/) @author Christoph Gaffga ([EMAIL PROTECTED]) So, you see, it's very similar to the CastorTransformer usage. If you test it, let me here, what you think about. regards Christoph - Original Message - From: Werner Guttmann [EMAIL PROTECTED] To: Christoph Gaffga [EMAIL PROTECTED]; [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Wednesday, September 10, 2003 10:04 AM Subject: Re: EJB + Cocoon, Best Practices / Betwixt Christoph, can you briefly explain the differences between the two transformers. Whilst I am very familiar with the CastorTransformer (and Castor XML/JDO), I'd appreciate a quick overview of the functionality of the BetwixtTransformer, and what advantages it would offer to using the CastorTransformer. that invokes the EJB and returns the DTO. It then passes the DTO to Betwixt which converts it to SAX events. I posted the BeanGenerator on the list a Perheaps you are also interested in a BetwixtTransformer, analoge to CastorTransformer? I post it here, perheaps anyone can put it in the scratchpad? regards Christoph org.apache.cocoon.tranformation.BetwixtTransformer: --- /* === = The Apache Software License, Version 1.1 === = Copyright (C) 1999-2003 The Apache Software Foundation. All rights reserved. Redistribution and use in source and binary forms, with or without modifica- tion, are permitted provided that the following conditions are met: 1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. 2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. 3. The end-user documentation included with the redistribution, if any, must include the following acknowledgment: This product includes software developed by the Apache Software Foundation (http://www.apache.org/). Alternately, this acknowledgment may appear in the software itself, if and wherever such third-party acknowledgments normally appear
Re: EJB + Cocoon, Best Practices / Betwixt
Christoph, can you briefly explain the differences between the two transformers. Whilst I am very familiar with the CastorTransformer (and Castor XML/JDO), I'd appreciate a quick overview of the functionality of the BetwixtTransformer, and what advantages it would offer to using the CastorTransformer. that invokes the EJB and returns the DTO. It then passes the DTO to Betwixt which converts it to SAX events. I posted the BeanGenerator on the list a Perheaps you are also interested in a BetwixtTransformer, analoge to CastorTransformer? I post it here, perheaps anyone can put it in the scratchpad? regards Christoph org.apache.cocoon.tranformation.BetwixtTransformer: --- /* The Apache Software License, Version 1.1 Copyright (C) 1999-2003 The Apache Software Foundation. All rights reserved. Redistribution and use in source and binary forms, with or without modifica- tion, are permitted provided that the following conditions are met: 1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. 2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. 3. The end-user documentation included with the redistribution, if any, must include the following acknowledgment: This product includes software developed by the Apache Software Foundation (http://www.apache.org/). Alternately, this acknowledgment may appear in the software itself, if and wherever such third-party acknowledgments normally appear. 4. The names Apache Cocoon and Apache Software Foundation must not be used to endorse or promote products derived from this software without prior written permission. For written permission, please contact [EMAIL PROTECTED] 5. Products derived from this software may not be called Apache, nor may Apache appear in their name, without prior written permission of the Apache Software Foundation. THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE APACHE SOFTWARE FOUNDATION OR ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLU- DING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. This software consists of voluntary contributions made by many individuals on behalf of the Apache Software Foundation and was originally created by Stefano Mazzocchi [EMAIL PROTECTED]. For more information on the Apache Software Foundation, please see http://www.apache.org/. */ package org.apache.cocoon.transformation; import java.lang.reflect.Proxy; import java.util.Collection; import java.util.Iterator; import java.util.Map; import org.apache.avalon.framework.configuration.Configurable; import org.apache.avalon.framework.configuration.Configuration; import org.apache.avalon.framework.configuration.ConfigurationException; import org.apache.avalon.framework.parameters.Parameters; import org.apache.cocoon.environment.Context; import org.apache.cocoon.environment.ObjectModelHelper; import org.apache.cocoon.environment.Request; import org.apache.cocoon.environment.Session; import org.apache.cocoon.environment.SourceResolver; import org.apache.commons.betwixt.XMLIntrospector; import org.apache.commons.betwixt.io.SAXBeanWriter; import org.apache.commons.betwixt.strategy.ClassNormalizer; import org.apache.commons.logging.impl.LogKitLogger; import org.xml.sax.Attributes; import org.xml.sax.SAXException; /** * Betwixt transformer marshals a object from the Sitemap, Session, Request or * the Conext into a series of SAX events. * * Configuation: The betwixt transformer can be configured to not output element * reference ids. The default setting is to output reference IDs. * pre * lt;map:transformer name=betwixt src=org.apache.cocoon.transformation.BetwixtTransformer * lt;ref-idsgt;truelt;/ref-idsgt; * lt;/map:transformergt; * /pre * * A sample for the use: * pre * lt;root xmlns:betwixt=http://apache.org/cocoon/betwixt-transfomergt; *lt;betwixt:include name=invoice /gt; *lt;betwixt:include name=product scope=sitemap /gt; *
RE: EJB + Cocoon, Best Practices
We are doing exactly that. Although our project is still in the very early stages, we have our EJBs returning Data Transfer Objects which are just Java Beans. We then wrote a BeanGenerator that calls a method on a service class that invokes the EJB and returns the DTO. It then passes the DTO to Betwixt which converts it to SAX events. I posted the BeanGenerator on the list a few days ago. Ralph -Original Message- From: Bastian Breithaupt [mailto:[EMAIL PROTECTED] Sent: Monday, September 08, 2003 2:33 PM To: [EMAIL PROTECTED] Subject: EJB + Cocoon, Best Practices Hi! I would like to set up a Model2 application with Cocoon end EJBs. Cocoon would be the presentation layer (also the controller layer?) and the business logic would be represented by the EJBs. (?) Are there any Best Practices for Cocoon working with EJBs? (suggestions, links, publications, documentation, ...) I suppose, calling the EJB-API is done by Cocoon-Actions...? (for example by using business delegation pattern) When using flow scripts, does it make sense to use actions? (how mature is flow script?) Any help, hint, link, ... is appreciated. Thank you in advance, Bastian __ 38xTestsieger - WEB.DE FreeMail - Deutschlands beste E-Mail Jeden Monat mit 10% mehr Leistung! http://f.web.de/?mc=021138 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: EJB + Cocoon, Best Practices
I haven't used flow either, primarily because it doesn't seem mature - at least from a documentation standpoint. However, my take on what I read was a little different than yours. I've looked at things like Weblogic's Java Page Flow and Cocoon's version seems similar. I believe the concept here is to manage a sequence of views. The pipeline seems to do a very good job in causing a single view to be presented but it is hard to make sure that pages are presented in the correct order. I belive Cocoon flow tries to address that problem. I see it more as a wrapper around a set of pipelines. Of course, if I have it wrong please correct me. Ralph -Original Message- From: jcplerm [mailto:[EMAIL PROTECTED] Sent: Monday, September 08, 2003 6:56 PM To: [EMAIL PROTECTED] Subject: Re: EJB + Cocoon, Best Practices I checked what I could find in terms of documentation and code related to the Flow, certainly I am missing something (is there is a document that clearly presents Flow from a conceptual to a lower level?). My objection is that so much emphasis has been made in terms of using as much as possible the sitemap and sitemap components, so applications are easily maintainable, and all of a sudden I see this Flow concept in which one really ends up burying the page chaining info in Javascript. Because that's what I see in the form2xml.flow example: the invocation of form2-display-pipeline and form2-success-pipeline is hardcoded in the binding_example.js script. That's totally the opposite of the sitemap concept. I really don't know how this could be done, but I would like to see that type of information specified in some sort of pipeline too. Sorry for my ignorance... jlerm - Original Message - From: Geoff Howard [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, September 08, 2003 8:28 PM Subject: Re: EJB + Cocoon, Best Practices Bastian Breithaupt wrote: Hi! I would like to set up a Model2 application with Cocoon end EJBs. Cocoon would be the presentation layer (also the controller layer?) and the business logic would be represented by the EJBs. (?) Excellent - I have always thought this use needed more press. Are there any Best Practices for Cocoon working with EJBs? (suggestions, links, publications, documentation, ...) Unfortunately, precious little has been written about the subject. Those who have used Cocoon and EJBs have not written much about it. I suppose, calling the EJB-API is done by Cocoon-Actions...? (for example by using business delegation pattern) When using flow scripts, does it make sense to use actions? (how mature is flow script?) Usually you would not need to call actions and flow. As you are designing from scratch, I'd recommend starting with flow. If done right, your logic would be re-usable as an action should the need arise. Conceptually flow will probably turn out to be pretty stable. The implementation is fairly new so using it may turn up unexpected issues. The good news is that most developers are paying a lot of attention to it, so there may be quick turn-around on resolving whatever comes up. In the end, the flow is just supposed to glue together your business logic especially as it relates to page flow within your application. This may make its young age less important. Any help, hint, link, ... is appreciated. No links that I'm aware of, but there are several people on list interested in writing up some examples of EJB and Cocoon who I'm sure would help you navigate the process. Give a little info about your specific needs/questions and some useful info is bound to turn up. For starters, are your EJBs on a remote server from Cocoon? Geoff - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: EJB + Cocoon, Best Practices / Betwixt
that invokes the EJB and returns the DTO. It then passes the DTO to Betwixt which converts it to SAX events. I posted the BeanGenerator on the list a Perheaps you are also interested in a BetwixtTransformer, analoge to CastorTransformer? I post it here, perheaps anyone can put it in the scratchpad? regards Christoph org.apache.cocoon.tranformation.BetwixtTransformer: --- /* The Apache Software License, Version 1.1 Copyright (C) 1999-2003 The Apache Software Foundation. All rights reserved. Redistribution and use in source and binary forms, with or without modifica- tion, are permitted provided that the following conditions are met: 1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. 2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. 3. The end-user documentation included with the redistribution, if any, must include the following acknowledgment: This product includes software developed by the Apache Software Foundation (http://www.apache.org/). Alternately, this acknowledgment may appear in the software itself, if and wherever such third-party acknowledgments normally appear. 4. The names Apache Cocoon and Apache Software Foundation must not be used to endorse or promote products derived from this software without prior written permission. For written permission, please contact [EMAIL PROTECTED] 5. Products derived from this software may not be called Apache, nor may Apache appear in their name, without prior written permission of the Apache Software Foundation. THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE APACHE SOFTWARE FOUNDATION OR ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLU- DING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. This software consists of voluntary contributions made by many individuals on behalf of the Apache Software Foundation and was originally created by Stefano Mazzocchi [EMAIL PROTECTED]. For more information on the Apache Software Foundation, please see http://www.apache.org/. */ package org.apache.cocoon.transformation; import java.lang.reflect.Proxy; import java.util.Collection; import java.util.Iterator; import java.util.Map; import org.apache.avalon.framework.configuration.Configurable; import org.apache.avalon.framework.configuration.Configuration; import org.apache.avalon.framework.configuration.ConfigurationException; import org.apache.avalon.framework.parameters.Parameters; import org.apache.cocoon.environment.Context; import org.apache.cocoon.environment.ObjectModelHelper; import org.apache.cocoon.environment.Request; import org.apache.cocoon.environment.Session; import org.apache.cocoon.environment.SourceResolver; import org.apache.commons.betwixt.XMLIntrospector; import org.apache.commons.betwixt.io.SAXBeanWriter; import org.apache.commons.betwixt.strategy.ClassNormalizer; import org.apache.commons.logging.impl.LogKitLogger; import org.xml.sax.Attributes; import org.xml.sax.SAXException; /** * Betwixt transformer marshals a object from the Sitemap, Session, Request or * the Conext into a series of SAX events. * * Configuation: The betwixt transformer can be configured to not output element * reference ids. The default setting is to output reference IDs. * pre * lt;map:transformer name=betwixt src=org.apache.cocoon.transformation.BetwixtTransformer * lt;ref-idsgt;truelt;/ref-idsgt; * lt;/map:transformergt; * /pre * * A sample for the use: * pre * lt;root xmlns:betwixt=http://apache.org/cocoon/betwixt-transfomergt; *lt;betwixt:include name=invoice /gt; *lt;betwixt:include name=product scope=sitemap /gt; *lt;betwixt:include name=product2 element=other-product /gt; * lt;/rootgt; * /pre * The codeBetwixtTransfomer/code support only one Element codebetwixt:include/code. * This element is replaced with the marshalled object. The Object given through the * attribute codename/code will be searched in the
Re: EJB + Cocoon, Best Practices
I checked what I could find in terms of documentation and code related to the Flow, certainly I am missing something (is there is a document that clearly presents Flow from a conceptual to a lower level?). My objection is that so much emphasis has been made in terms of using as much as possible the sitemap and sitemap components, so applications are easily maintainable, and all of a sudden I see this Flow concept in which one really ends up burying the page chaining info in Javascript. Because that's what I see in the form2xml.flow example: the invocation of form2-display-pipeline and form2-success-pipeline is hardcoded in the binding_example.js script. That's totally the opposite of the sitemap concept. I really don't know how this could be done, but I would like to see that type of information specified in some sort of pipeline too. Sorry for my ignorance... jlerm - Original Message - From: Geoff Howard [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, September 08, 2003 8:28 PM Subject: Re: EJB + Cocoon, Best Practices Bastian Breithaupt wrote: Hi! I would like to set up a Model2 application with Cocoon end EJBs. Cocoon would be the presentation layer (also the controller layer?) and the business logic would be represented by the EJBs. (?) Excellent - I have always thought this use needed more press. Are there any Best Practices for Cocoon working with EJBs? (suggestions, links, publications, documentation, ...) Unfortunately, precious little has been written about the subject. Those who have used Cocoon and EJBs have not written much about it. I suppose, calling the EJB-API is done by Cocoon-Actions...? (for example by using business delegation pattern) When using flow scripts, does it make sense to use actions? (how mature is flow script?) Usually you would not need to call actions and flow. As you are designing from scratch, I'd recommend starting with flow. If done right, your logic would be re-usable as an action should the need arise. Conceptually flow will probably turn out to be pretty stable. The implementation is fairly new so using it may turn up unexpected issues. The good news is that most developers are paying a lot of attention to it, so there may be quick turn-around on resolving whatever comes up. In the end, the flow is just supposed to glue together your business logic especially as it relates to page flow within your application. This may make its young age less important. Any help, hint, link, ... is appreciated. No links that I'm aware of, but there are several people on list interested in writing up some examples of EJB and Cocoon who I'm sure would help you navigate the process. Give a little info about your specific needs/questions and some useful info is bound to turn up. For starters, are your EJBs on a remote server from Cocoon? Geoff - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
