Re: Clarification on converter concept
Joerg Heinicke wrote: > Issue 3 to hand in there :) :) > Ok, I just did not found anything about the bean map. And compared the > number of classes (20+) with the number of pages regarding functionality > (4: running modes, property handling, bean configuration, log4j). Maybe > I jumped the conclusions :-) They main topics seem indeed to be covered, > only (?) bean map docs are missing. Ah, great, yes bean map has been added later - I'll document it in the next days. Carsten -- Carsten Ziegeler [EMAIL PROTECTED]
[flowscript] cocoon.load() to load non-javascript file?
Hi, In flowscript, cocoon.load() is used for loading a javascript. Is there other way to load a source other than javascript? By studying the source code, the source reslover is stored in javascript intrepreter but not accessible to user's flow script. Given no modification to the flowscript source code, is there a way to access the source resolver? Rice
The usage of Spring in Cocoon
Hello Spring team,
I write this message more or less on behalf of the Apache Cocoon
(http://cocoon.apache.org) team. I don't know if somebody of you follows
Cocoon's development: We have changed the internal container Cocoon is
based on from Apache Avalon ECM to Spring for Cocoon 2.2. I used the
quite common subject since we have quite different issues.
First the technical ones. When we started to talk about some converter
concept recently [1] we originally had some generalization of the
converters in Cocoon Forms [2] in mind. I made the proposal to do it the
Spring way using PropertyEditors. Unfortunately 2 issues arose: The
first is about lacking internationalization support, the second about
(let's call it) "inflexible" editor selection.
1. Cocoon is known to have sophisticated i18n support. The property
editors are lacking any built-in i18n support, Spring does not add
anything on top of it. It is considered to be implemented into the
editors like for the CustomDateEditor:
new CustomDateEditor(DateFormat, boolean)
It is only the DateFormat that gets locale information, e.g. from the
request in the initBinder() method of the controllers. Since that's
necessary in every controller it scatters the editor setup through the
application. The new way of registering PropertyEditors using
PropertyEditorRegistrar makes this even completely impossible since it
has no access to the request.
The CForms Convertor interface [3] has the locale in its methods
convertFromString() and convertToString() in contrary to PropertyEditor
[4] as you know. Our idea was know anyway to remove it from the actual
converters to the registry. So the locale would be another property you
can register a PropertyEditor to as it is done with "path". The
PropertyEditorRegistry would need to be extended correspondingly which
can even happen in a backwards-compatible way I guess. The
BeanWrapperImpl would need to search for editors using the locale
additionally.
What do you think about it? Is it something that could it even make it
into Spring 2.1?
2. The second issue with Spring's converter infrastructure is about the
selection of editors by "path". It is not possible to show one property
in two different representations on one page, e.g. a date in "full" and
"short" form according to DateFormat [5]. That's what I called
"inflexible" above.
Our original approach was to use a "variant" in the expression language
like ${myobj.startDate#short}. That could even make it into the current
"path", so it's actually an extended understanding of "path". There is
also an approach passing this "variant" information back to the request
binder.
I only wonder if you had this possible requirement at any place in mind.
How would you address the need for different representations of the same
property in one page?
3. The third "issue" is about some enhancements Carsten Ziegler
implemented for "providing support in common configuration issues when
using the Spring framework". It's called spring-configurator [6] and is
used in Cocoon, but it's not tied in any way to Cocoon except for the
package name at the moment. It has additional support for configuration
like running modes (selecting property files according to running modes
like "test" or "production"), automatic selection of property files and
bean configuration from standard directories. Additionally there is a
bean map which adds all beans of a particular type to a map as shown in
[7] without the need to register it by hand.
The scope of these components is a bit beyond Cocoon's actual scope.
Furthermore all this stuff is of rather general use, so we wonder if you
are interested in the one or the other component. A move nearer to
Spring community seems to be natural.
What do you think about it?
Thanks for any exchanges of ideas with the Cocoon community in advance.
Regards,
Joerg
[1] http://marc.info/?t=11834921986&r=1&w=4
[2] http://cocoon.apache.org/2.1/userdocs/widgetconcepts/datatypes.html
[3]
http://cocoon.apache.org/2.1/apidocs/org/apache/cocoon/forms/datatype/convertor/Convertor.html
[4] http://java.sun.com/j2se/1.4.2/docs/api/java/beans/PropertyEditor.html
[5] http://java.sun.com/j2se/1.4.2/docs/api/java/text/DateFormat.html
[6] http://cocoon.zones.apache.org/daisy/cdocs-spring-configurator/
[7]
http://svn.apache.org/viewvc/cocoon/trunk/core/cocoon-expression-language/cocoon-expression-language-impl/src/main/resources/META-INF/cocoon/spring/DefaultExpressionFactory.xml?view=markup
Re: Clarification on converter concept
On 16.07.2007 02:48, Carsten Ziegeler wrote: Hmm, was the first time I had a look into it today. Really? :) Unfortunately :( So if anyone thinks that it makes sense to promote this stuff "somewhere", let's do it :) Issue 3 to hand in there :) For the latter it would be good to have documented what's there and how it is supposed to be used. The documentation at Daisy is a bit spare. Hmm, I haven't looked at the docs recently, but I thought i had documented everything which is in it. Ok, I just did not found anything about the bean map. And compared the number of classes (20+) with the number of pages regarding functionality (4: running modes, property handling, bean configuration, log4j). Maybe I jumped the conclusions :-) They main topics seem indeed to be covered, only (?) bean map docs are missing. Joerg
Re: Clarification on converter concept
On 16.07.2007 04:58, Daniel Fagerstrom wrote: Actually I'm not very keen on any templating approach at all. I prefer a push approach as well. But this project is not about creating the ideal template framework. You digress :-) I did not want to get into this discussion about the best approach at all. I only wanted to point out that there are different approaches to do things, where you don't have an EL available, so where variants can't be used. That's why I'd like to see at least a combined path/variant approach instead of a variant-only approach. OTOH switching to a path-only approach seems also not possible since this can't handle all use cases as you outlined with the multiple date representations. Joerg
Re: Clarification on converter concept
On 15.07.2007 00:45, Vadim Gritsenko wrote: I also wonder how you are going to use CForms without CTemplate? You must use some template mechanism to produce data representing form and its state. FormsTransformer? It has a template approach as well [1], but no EL at all. FormsTransformer is sort of on its way out (right, Jeremy?) It was only an example for independent usage of either CForms or CTemplate. It is also possible to not use CForms, but just some plain simple form. When you use a converter here you somehow need to get the value converted back as well. With Spring I can do this, I'm not tied to use their taglib since the converter wraps the object. Actually I'm not very keen on any templating approach at all. FormsGenerator? I'm aware of it. Again it was just an example of independent usage. Joerg
Re: Clarification on converter concept
On 14.07.2007 15:55, Daniel Fagerstrom wrote: The main difference in my view is that with paths the choice of presentation is connected to the model and with anchors it is connected to the presentation. Ok, I agree. Both cases have legitimate uses. A particular date could be presented both in its short form in a table and in its long form in a text. That is clearly a presentation issue. I'd really like to involve Spring guys here. I'm interested how they think this can be solved. Doesn't this variant selection go very much into the direction of assumption about the data type? It is up to the user. The user could as an example have a "short" variant for the short form of a couple of different data types. This argument is a bit lousy, isn't it? ;-) It also completely decouples the object-to-string conversion from the templating while with the "select a variant"-approach in the template the conversion can not be done without the template. That is an implementation detail. We have an object model that an expression language can be applied on where the result in turn can be converted by a converter and the result in turn can be used in a template. We have 4 different parts that can be used both together and in parts if implemented in the right way. For me it's 1. object model, 2. object-to-string conversion and 3. referencing the value in the template via the EL. If the EL influences the conversion 2. and 3. are coupled. That's not just an implementation detail. Further, using an EL and format variants on a bean model would probably be possible for a web designer. Writing Spring bean configurations seem to be a little bit to much. I agree that the different date representations are presentation issues, not model issue. I don't have any solution for it except those variants. Also if you have e.g. a regexp defined format, will you need to repeat it for each property path you would like to apply it on? You don't need to. Similar to the setup of the "short" variant you can set up the regexp-defined editor. You only would need to reference it multiple times in the bean definition as shown with my MapBasedPropertyEditorRegistrar sample [1]. That's similar to referencing "short" in the EL. There is indeed no way to select a converter based on the locale at the moment. To me this sounds like Spring doesn't have a satisfying solution to the locale problem right now. Didn't I confirm this already? :-) That's the second thing I'd like to get Spring community involved. Joerg [1] http://marc.info/?l=xml-cocoon-dev&m=118438238711044&w=4
Re: 2.2 does not build with JDK1.4.2
On 16.07.2007 02:49, Carsten Ziegeler wrote: What's so specific about this spring-dao.jar or it's pom that only for it this property is retrieved? How does this dependency come in at all? It's not a direct dependency of Cocoon. Aren't all direct and transitive dependencies supposed to be declared in our POM? I guess its an oversight Can somebody please try out to add this dependency explicitly or exclude it if we don't need it. I don't have a pc available at the moment (and probably another few days/weeks) where I can do this. Thanks, Joerg
Re: JSP integration
On 16.07.2007 04:32, Daniel Fagerstrom wrote: From what I understand other servlets need to be registered in Cocoon (or the underlying Spring container). Doesn't that make it a servlet container in a servlet container? Yes, but the internal "container" is very light weight. So I would say that it is very far from the "almighty Cocoon syndrome". Ok, sorry for implying that. The only alternative is probably to use the shared application context as mentioned in the thread about "interblock communication" [1]. With the current servlet service framework I just don't know how to integrate JSPs - what this thread was actually about. Joerg [1] http://marc.info/?l=xml-cocoon-dev&m=118269446927501&w=4
[jira] Closed: (COCOON-2089) ServletService-FW handles missing i18n catalogue files incorrect
[ https://issues.apache.org/jira/browse/COCOON-2089?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Knecht closed COCOON-2089. Resolution: Fixed Fix Version/s: 2.2-dev (Current SVN) Reader in sitemap-pipline used to get resource via servlet-services throws CascadingIOException when Resource not found. Adding CascadingIOException to catched exceptions and handle the same way like a SourceNotFoundException. > ServletService-FW handles missing i18n catalogue files incorrect > > > Key: COCOON-2089 > URL: https://issues.apache.org/jira/browse/COCOON-2089 > Project: Cocoon > Issue Type: Bug > Components: - Servlet service framework >Affects Versions: 2.2-dev (Current SVN) >Reporter: Felix Knecht >Assignee: Felix Knecht > Fix For: 2.2-dev (Current SVN) > > Attachments: i18n_errorless.patch > > > ServletService throws an exception when a specific language catalogue in a > connected block is not found, even when a general catalogue exists. > Forcing the error: > - Run the cocoon-webapp with the form samples > - Choose following link: > http://localhost:/blocks/cocoon-forms-sample/form1.flow?locale=de-DE > - Click on the "Submit Query" button > You will see the errors in the log file: > btpool0-3 ERROR cocoon - Bundle > not loaded: > Exception > org.apache.cocoon.CascadingIOException: Error during resolving of the input > stream > at - > file:/home/felix/svn/apache/cocoon/trunk/core/cocoon-webapp/target/work/blocks/cocoon-forms-impl/sitemap.xmap:29:76 > OTH when you copy the > cocoon-forms-impl/src/main/resources/org/apache/cocoon/forms/system/i18n/messages.xml > into cocoon-forms-sample/src/main/resources/COB-INF/messages and adapt the > cocoon-forms-sample root sitemap to use the local message.xml catalogue file > instead of the one from the cocoon-forms-impl block you don't get an error > and the general catalogue (messages.xml) is silently used instead of the > missing messages_de_DE.xml. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (COCOON-2089) ServletService-FW handles missing i18n catalogue files incorrect
[ https://issues.apache.org/jira/browse/COCOON-2089?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Knecht reassigned COCOON-2089: Assignee: Felix Knecht > ServletService-FW handles missing i18n catalogue files incorrect > > > Key: COCOON-2089 > URL: https://issues.apache.org/jira/browse/COCOON-2089 > Project: Cocoon > Issue Type: Bug > Components: - Servlet service framework >Affects Versions: 2.2-dev (Current SVN) >Reporter: Felix Knecht >Assignee: Felix Knecht > Attachments: i18n_errorless.patch > > > ServletService throws an exception when a specific language catalogue in a > connected block is not found, even when a general catalogue exists. > Forcing the error: > - Run the cocoon-webapp with the form samples > - Choose following link: > http://localhost:/blocks/cocoon-forms-sample/form1.flow?locale=de-DE > - Click on the "Submit Query" button > You will see the errors in the log file: > btpool0-3 ERROR cocoon - Bundle > not loaded: > Exception > org.apache.cocoon.CascadingIOException: Error during resolving of the input > stream > at - > file:/home/felix/svn/apache/cocoon/trunk/core/cocoon-webapp/target/work/blocks/cocoon-forms-impl/sitemap.xmap:29:76 > OTH when you copy the > cocoon-forms-impl/src/main/resources/org/apache/cocoon/forms/system/i18n/messages.xml > into cocoon-forms-sample/src/main/resources/COB-INF/messages and adapt the > cocoon-forms-sample root sitemap to use the local message.xml catalogue file > instead of the one from the cocoon-forms-impl block you don't get an error > and the general catalogue (messages.xml) is silently used instead of the > missing messages_de_DE.xml. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
XML to Excel template examples Required.
Hi All, I am just beginner in cocoon. I have the following requirements: 1.I have input XML Ferrari Water Mercedes Air 2.I have a Excel template Which already has headers (Car Name & Car Type) Task for me is to use the XML as a source generater & serilize the output using the predefined template. I would appreciate if you could share any working example of such type. I visited XML.com article (http://www.xml.com/lpt/a/1096) and they have no examples where we can take the input feed from XML and generate on a Template. All example includes SQL and due to some freak problem, I am still struggling to get the SQL part running. Thanks in advance, -Siddhu
Re: spring webflow
Bart Molenkamp wrote: > Cocoon's SoC made writing web applications better because of the strong > separation of logic, content and styling. And javaflow improved it because > it took some request/response details away. I think Wicket has achieved > the same goal, but I think it's more productive to use than Cocoon is > these days. Maybe Cocoon should focus on XML transformation stuff again, > and not trying to integrate yet anohter product... > I agree with you that Cocoon should not integrate additional stuff - there is too muc in it already. Now, I think Cocoon should do the opposite and just provide the framework and enable you to use other stuff. Now, this sounds a little bit like the "you can do everything but you have to figure out yourself how", I know. But if you look at the switch to Spring, it's the way I think it should be. We removed our own container implementation (nearly completly if we forget about the avalon support) and you can integrate Cocoon into Spring. And I guess the same could be try with Spring WebFlow, so this would mean that you don't have to care about all the current flow stuff in Cocoon and just use what is out there. Carsten -- Carsten Ziegeler [EMAIL PROTECTED]
RE: spring webflow
I'm not sure if Cocoon should be used for writing web applications at all. If you want to write a simple application, you need to write (and learn) the sitemap, flowscript and probably JXTemplate. If you want to use cforms, you need to know how to write form definitions, form templates and maybe even form bindings. If you want to apply some styling you need to know about XSLT as well. And it even makes it more difficult if you want to reuse some of these parts (try to extend or override parts in cforms, jxtemplate or flow - it wasn't designed for this). I've switched to use Wicket for the new application that we've been creating here. I think it's much easier to create web applications with wicket (because one of the things that make it easier to use is that it takes the request/response cycles away). It's back to basic html (or xhtml) with Java. And onf of the best things is that you can reuse and extend your components (including reuse of markup). Cocoon's SoC made writing web applications better because of the strong separation of logic, content and styling. And javaflow improved it because it took some request/response details away. I think Wicket has achieved the same goal, but I think it's more productive to use than Cocoon is these days. Maybe Cocoon should focus on XML transformation stuff again, and not trying to integrate yet anohter product... Just my 2 cents. > -Oorspronkelijk bericht- > Van: Carsten Ziegeler [mailto:[EMAIL PROTECTED] > > To be honest I'm not sure if javascript is better than xml :) Though I > don't like both of them when it comes to describing a flow, Spring > Webflow as imho to big plus points: a visual editor and it's > well known > outside of Cocoon. This doesn't imply that it's really better > or better > usable.
Re: spring webflow
Yes, I've brought this up a couple of times in the past. First, I tried to use the sitemap as the flow controller for my business logic. This worked fine for small and simple things. However, when the page flow turned into anything of any substance it quickly became unworkable. I then looked at javaflow. I liked it because it was Java. But I also hated it because it was Java. Managing the application flow through a programming language just makes for something that is still pretty messy but it is hard to change. My one adventure into flowscript was quite by accident. A coworker used one of Cocoon's sample calculators in a website. After the release went live threads started looping periodically. After reviewing dumps I discovered that Rhino was causing the loop. As it was virtually impossible to figure out what was causing the problem we pretty much decided flowscript was not such a great idea. Secondly, it really isn't that much better than Javaflow in terms of being hard to change the flow. We've been developing some of our applications using JSF. While it isn't all that bad, when I compare it with Spring WebFlow I find I just like the way it works better. Since we wrap all of our JSF portlets with Spring anyway it just seems to make more sense. Finally, I've always felt that Cocoon's strength was as a View generator. I could never recommend that folks use some of the blocks as they are huge security problems are horribly clumsy ways to access the business data. That being said, as a View generator Cocoon is fabulous. So to me, since 2.2 is already Spring based it just seems that providing support for integrated WebFlow makes a lot of sense. Ralph Torsten Curdt wrote: I really, really want to integrate Cocoon with Spring WebFlow as I feel that that is a much more workable solution than trying to build applications using flowscript or javaflow and this only really makes sense with 2.2 since it is Spring based. You brought this already a couple of times. Years and years ago (when I was still working at dff) we developed a xml based flow engine way before what we call flow these days existed. It was so horrible to maintain that we dropped it. Maybe just the lack of tools ...or maybe just the lack of resources writing those tools ...but I am still afraid when ever someone pushes into a similar direction. There was also a talk at FOSDEM about such an approach and I only barely could hold back to comment during his talk ...he was so excited and convinced about the solution. For us just a minimal flow resulted in so much xml ...bah! Make sure you evaluate it's what you really want before you go down that road. Just my 2 cents cheers -- Torsten
Re: spring webflow
On 16.07.2007, at 15:35, Carsten Ziegeler wrote: Torsten Curdt wrote: I really, really want to integrate Cocoon with Spring WebFlow as I feel that that is a much more workable solution than trying to build applications using flowscript or javaflow and this only really makes sense with 2.2 since it is Spring based. You brought this already a couple of times. Years and years ago (when I was still working at dff) we developed a xml based flow engine way before what we call flow these days existed. It was so horrible to maintain that we dropped it. Maybe just the lack of tools ...or maybe just the lack of resources writing those tools ...but I am still afraid when ever someone pushes into a similar direction. There was also a talk at FOSDEM about such an approach and I only barely could hold back to comment during his talk ...he was so excited and convinced about the solution. For us just a minimal flow resulted in so much xml ...bah! Make sure you evaluate it's what you really want before you go down that road. Just my 2 cents To be honest I'm not sure if javascript is better than xml :) ...it's just less verbose :) Though I don't like both of them when it comes to describing a flow, Spring Webflow as imho to big plus points: a visual editor and it's well known outside of Cocoon. This doesn't imply that it's really better or better usable. I guess those were also the two things that we were missing those days :) cheers -- Torsten
Re: spring webflow
Torsten Curdt wrote: >> I really, really want to integrate Cocoon with Spring WebFlow as I >> feel that that is a much more workable solution than trying to build >> applications using flowscript or javaflow and this only really makes >> sense with 2.2 since it is Spring based. > > You brought this already a couple of times. > > Years and years ago (when I was still working at dff) we developed a xml > based flow engine way before what we call flow these days existed. It > was so horrible to maintain that we dropped it. Maybe just the lack of > tools ...or maybe just the lack of resources writing those tools ...but > I am still afraid when ever someone pushes into a similar direction. > There was also a talk at FOSDEM about such an approach and I only barely > could hold back to comment during his talk ...he was so excited and > convinced about the solution. For us just a minimal flow resulted in so > much xml ...bah! Make sure you evaluate it's what you really want before > you go down that road. > > Just my 2 cents > To be honest I'm not sure if javascript is better than xml :) Though I don't like both of them when it comes to describing a flow, Spring Webflow as imho to big plus points: a visual editor and it's well known outside of Cocoon. This doesn't imply that it's really better or better usable. Carsten -- Carsten Ziegeler [EMAIL PROTECTED]
spring webflow
I really, really want to integrate Cocoon with Spring WebFlow as I feel that that is a much more workable solution than trying to build applications using flowscript or javaflow and this only really makes sense with 2.2 since it is Spring based. You brought this already a couple of times. Years and years ago (when I was still working at dff) we developed a xml based flow engine way before what we call flow these days existed. It was so horrible to maintain that we dropped it. Maybe just the lack of tools ...or maybe just the lack of resources writing those tools ...but I am still afraid when ever someone pushes into a similar direction. There was also a talk at FOSDEM about such an approach and I only barely could hold back to comment during his talk ...he was so excited and convinced about the solution. For us just a minimal flow resulted in so much xml ...bah! Make sure you evaluate it's what you really want before you go down that road. Just my 2 cents cheers -- Torsten
Re: Clarification on converter concept
Daniel Fagerstrom pisze: Joerg Heinicke skrev: On 13.07.2007 10:31, Grzegorz Kossakowski wrote: ... Actually I'm not very keen on any templating approach at all. I don't like to first provide data to some template context and second retrieve it from there in the template. IMO it's much better to have a complete push approach and only encroach if it is necessary (like XSLT templates). (My diploma thesis was about this btw.) I prefer a push approach as well. But this project is not about creating the ideal template framework. It is about keeping back compatibility and at the same time giving users a simpler and cleaner way forward for new development and possible refactoring of old stuff. Yes, I think Daniel is right about my goal. AFAIU, it will be possible to use the object model without any default content, (is that true Grzegorz?). In such a scenario you can have a pure push approach, by only pushing the data that should be rendered into the object model. Yes, there will be default ObjectModel implementation that will collect environmental data and expose in unified way but you can easily write your own implementation (it will have very light-weight interface) that could expose any data you like and any form you like. It's a worth to say that thanks to Spring Configurator capabilities it will be extremely easy to force any our component to use your own ObjectModel implementation. I preferred that kind of solution once. But now I find it unnecessary complicated in most cases. The first problem is that it requires some work to convert bean structure to XML data. You will probably need some configuration file that handle part of the conversion. In comparison to just applying an EL to a bean structure it is more complicated. Second, many people find XSLT much more complicated than a simple template language. Third, the development of XSLT processors and tooling, has been a disappointment. Xalan, still doesn't implement XSLT 2.0, and the error messages from both Xalan and Saxon can often be cryptic or non existent. Same feelings here, unfortunately (I find XSLT really nice as idea). -- Grzegorz Kossakowski http://reflectingonthevicissitudes.wordpress.com/
Re: Clarification on converter concept
Joerg Heinicke skrev: On 13.07.2007 10:31, Grzegorz Kossakowski wrote: ... Actually I'm not very keen on any templating approach at all. I don't like to first provide data to some template context and second retrieve it from there in the template. IMO it's much better to have a complete push approach and only encroach if it is necessary (like XSLT templates). (My diploma thesis was about this btw.) I prefer a push approach as well. But this project is not about creating the ideal template framework. It is about keeping back compatibility and at the same time giving users a simpler and cleaner way forward for new development and possible refactoring of old stuff. AFAIU, it will be possible to use the object model without any default content, (is that true Grzegorz?). In such a scenario you can have a pure push approach, by only pushing the data that should be rendered into the object model. A possible implementation for this is to convert the form model into an XML representation Not everything is in forms. We need a mechanism for rendering model data without connecting it to a form. and let a quite generic XSLT do the rest. With this approach no EL come into play. This also means there is a separate object-to-string step. I preferred that kind of solution once. But now I find it unnecessary complicated in most cases. The first problem is that it requires some work to convert bean structure to XML data. You will probably need some configuration file that handle part of the conversion. In comparison to just applying an EL to a bean structure it is more complicated. Second, many people find XSLT much more complicated than a simple template language. Third, the development of XSLT processors and tooling, has been a disappointment. Xalan, still doesn't implement XSLT 2.0, and the error messages from both Xalan and Saxon can often be cryptic or non existent. In the end XSLT has its uses, but for simple rendering of beans I find simple template languages like JXTG much more productive (and I have written tons of XSLT). /Daniel
Re: JSP integration
Joerg Heinicke skrev: ... From what I understand other servlets need to be registered in Cocoon (or the underlying Spring container). Doesn't that make it a servlet container in a servlet container? Yes, but the internal "container" is very light weight. This approach still seems to suffer from the "almighty Cocoon" syndrome (doing everything itself, not delegating stuff to e.g. the servlet container). As much as possible is delegated. But servlet containers doesn't contain any mechanisms for building webapps based on plugins that can communicate and share components, so I don't see how we can achieve the goals without creating some own infrastructure. Do you have any concrete suggestions? Otherwise the servlet service and block architecture is really non intrusive. As you can see http://svn.apache.org/repos/asf/cocoon/trunk/core/cocoon-servlet-service/cocoon-servlet-service-impl/pom.xml it haven't any dependencies on the rest of Cocoon, the only API, the user need to care about is the servlet one. Configurations is done with Spring. The architecture consists of a dispatcher and an own ServletContext implementation that allow for inter block communication and some support classes. So I would say that it is very far from the "almighty Cocoon syndrome". /Daniel
