Re: [RT] The next shiny thing?
On 06.12.2005 13:18, Steven Noels wrote: I'm surprised to finally see evidence of an anti-OSGI camp in Cocoon. Not that this surprises me, but it's just sad that this hasn't been clarified much earlier. That damned community tax again, I guess. Waste of time and energy for everyone. At least for me it is more a "I'm not happy with 'yet another beast', but I can't provide another solution." I did not work with any container up to recently, so how should I take part in such a discussion? At the end it is probably even an "I don't care." as I can't read about and evaluate everything and have to care about other things in my work with Cocoon. Jörg
Cocoon F2F at ApacheCon
I really think the current discussions on CocoonReloaded could do with some higher bandwidth talks to formulate a first "plan". How many Cocoonites will be at ApacheCon and could perhaps get together? I won't be there but Carsten is (for example). Discussing the "plan" via various email-threads doesn't seem to me to be that effective - at this initial stage - and could eventually lead to everyone giving up in frustration. Just a suggestion. Matthew
Re: ajax cform and forms_onsubmitHandlers issues
Quoin Developers wrote: So the forms_onsubmit() method needs boolean indicator as to whether the form has already been submitted for server processing (distinct from an ajax forms submission) to know whether it should process the onsubmit handlers array. It should no longer simply use the forms_onsubmtHandlers stack for that indication. When ajax is submitting the form, maybe it can pass an object to the forms_onsubmit() indicating that this is an Ajax call. Exaclty. The current implementation works for non-AJAX forms. I was thinking further about this. For the AJAX mode, we need implemented a handler manager. One version: Every widget can have a method with a predefined name, then in AJAX mode, before commiting, the AJAX controller call this methods. We don't need a stack. Only a boolean indicator to keep track that the user already pressed a button on the page. Another version is: We have an stack (as we have now). But every item on the stack contains also the widget name to keep track of them. In AJAX mode, when the response comes back from the server, the AJAX controller only delete the methods in the stack for the widget that comes in the response. The will keep the methods for all the no changed widgets. That way they will be executed in the next submit event. Also I will like to get rid of the "generate-id()" call in the XSLT. They simply don't work for AJAX. It would also be nice to have an object to hold all the global forms variables (so that we could scope them and eventually support mutliple forms on the same page). Good idea. WDYT? Best Regards, Antonio Gallardo.
Re: [Poll] We need to align on one point (was Re: [Vision] Knowing When We are Done)
Though I am not a dev guy, I can't resist to vote, too. IMHO a mix makes no sense. Too make a long story short I made struggled my way into cocoon with -first writing custom actions as I was not aware that I should use flow instead -then switching to flow using JavaScript -and finally port everything to JavaFlow JavaFlow is a really nice thing, as some of you have written before, everything is in one IDE, it's much easier too integrate the backend classes, and though most people in the web area know something about javascript, almost nobody really masters javascript. It's easier to debug, document with javadoc, and it's compiled and typesafe. Second argument: It was hard to explain, why I kicked struts out, and used cocoon instead. And it was even harder to explain that there is JavaScript in the server part. Managers who buy oracle don't like to hear things like this... Last comment: Though this is not the question in this poll, I would even kick out the pipeline xml stuff. XML was not designed to be "procedural", basically it's a markup language, which focuses on data exchange. On a recent open source talk in vienna a committer from RoR was joking about the java frameworks and their tons of configuration and even worse "flow" description files. Though the RoR approach goes a bit too far for a compiled language like java, I do believe it makes sense to stick to the language choosen. So, please :-), only one language, and as cocoon (or whatever it's name will be :-) ) is a J2EE framework: _Java_ Sorry for the interference :-), regards, tom Berin Loritsch wrote: What's your preference for the vision? [ ] All web apps written in JavaScript [x] All web apps written in pure Java [ ] Mix and match (not as simple, but is status quo with today)
JavaScript BOF at ApacheCon
Hi all, I was contacted recently by Martin Cooper, Struts PMC chair -- yikes! :-) -- that happens to know quite well the people behind DojoToolkit, and we chatted about the opportunity to have some coordinated effort wrt to JavaScript at Apache, both client-side and server-side. So we've setup a BOF [1] on this subject next Monday at ApacheCon. Interested people are warmly invited to join! Sylvain [1] http://wiki.apache.org/apachecon/BirdsOfaFeather -- Sylvain WallezAnyware Technologies http://bluxte.net http://www.anyware-tech.com Apache Software Foundation Member Research & Technology Director
Re: [RT] The next shiny thing?
On 04.12.2005 17:00, Sylvain Wallez wrote: Start a whiteboard prototype if you feel like it, but to me it seem quite risky to try to rewrite everything from scratch, although I have felt the urge myself countless time while struggling with the messy internals. But before you go ahead and rewrite everything from scratch, take some minutes and read why Joel Spolesky thinks that rewriting software from scratch is the: *single worst strategic mistake* that any software company can make http://www.joelonsoftware.com/articles/fog69.html. Although I most often find Joel Spolsky's writings very enlightning, I always disagreed with that one. And to understand why, consider what is your main browser and what mail software you used to write this. The headers say "User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)". IMO Joel mixes two different things in his post: parts of code and a complete code base of any software. His samples with string function and the "two page function" can probably be refactored without any problem and he is absolutely right about not just throwing it away. But it might be very different for complete code bases. How many of these "bug fixes" in the code base are for fixing obsolete things (e.g. Netscape's way of rendering HTML following the standards not that well)? And also what's the effort of getting such a code base refactored in comparison to its rewriting - including the maintenance phase, fixing of bugs should be much easier than before. Now what about Cocoon? Is Cocoon a 500.000 LOC beast which can not be refactored or maintained? Or is Cocoon more or less a collection of many components? IMO it is the latter and we should follow Marc's proposal of separating these components into layers. The effort should not be that high to this in an incremental way instead of starting from scratch. Jörg
Re: [Poll] We need to align on one point (was Re: [Vision] Knowing When We are Done)
Aurélien DEHAY wrote: Hello. Sorry for the intervention of a non-dev on the dev list, but shouldn't this question be asked on the user mailing list? :) Yes and no. Check this article out for more information: http://headrush.typepad.com/creating_passionate_users/2005/09/listening_to_us.html In all honesty, while we are day dreaming about our vision we don't necessarily want to alarm users or generate too much noise on the user list. However, since you are on this list, your input is valued if you have any.
Re: An entirely new beast
Ralph Goers wrote: Ugo Cei wrote: Il giorno 07/dic/05, alle ore 15:28, Vadim Gritsenko ha scritto: Cocoon NG is nice, even too nice. Cocoon NT or Cocoon XP are much better. No chance that it could be released without renaming. Hmmm ... maybe Cocoon 360? ;-) Ugo MS Cocoon :-) Yep. Note there is no innovation at all (Cocoon 360 --> xbox 360 --> IBM 360). (Sorry for not being clear in the first mail) :-S Best Regards, Antonio Gallardo.
Re: [Poll] We need to align on one point (was Re: [Vision] Knowing When We are Done)
Hello. Sorry for the intervention of a non-dev on the dev list, but shouldn't this question be asked on the user mailing list? Aurélien
Re: [Poll] We need to align on one point (was Re: [Vision] Knowing When We are Done)
[X] Mix and match (not as simple, but is status quo with today) However, to be effective we need a core development effort, therefore the *official* support should be for a limited subset of what is in use today: Javascript + Java Ross
OT [Re: [Vision] Knowing When We are Done]
Ugo Cei wrote: Il giorno 07/dic/05, alle ore 11:43, Ross Gardler ha scritto: Most businesses are made up of common business processes. The odd one will be unique to that business, but most are common. In the case of the unique practices the software needs to be customised, but in the case of common practices an "off-the-shelf" solution is sufficient. Sorry but I don't believe this dream of high-level, off-the-shelf, customizable components will ever come to fruition, Cocoon or not. On this point, I agree with Dan Creswell [1]: "All attempts at creating high-level business components that can be re-used and re-configured have failed previously. This failure has not been for technical reasons - it happens because the requirements that yielded the original component interface were sufficiently different from the new requirements so as to require re-writing massive chunks of functionality." And David Heinemeier Hansson as well [2]: "On the surface, the dream of components sounds great and cursory overviews of new projects also appear to be "a perfect fit". But they never are. Reuse is hard. Parameterized reuse is even harder. And in the end, you're left with all the complexity of a swiss army knife that does everything for no one at great cost and pain." Off Topic now, but I can't resist... I agree with both of these quotes 100%. In fact, my academic blue sky work, in my "previous life", addressed *exactly* the problems identified within the above quotes. It's all to do with the size of the component base (not the ease of configurability), the ability to identify "good enough" components and the ease of building a custom component when there is no suitable off-the-shelf component. That's why Cocoon can be applied succesfully in this area, it has the potential to be a very powerful web platform. Therefore, for now, I agree that to be useful Cocoon has to be an easy to use web-development framework. Without that, there is no point in me carrying on - so I won't (yet) Ross [1]: http://jroller.com/page/dancres/20050218#soa_doomed [2]: http://www.loudthinking.com/arc/000407.html
Re: [Vision] Knowing When We are Done
Mats Norén wrote: Ross Gardler wrote: Bertrand Delacretaz wrote: Le 7 déc. 05, à 09:10, Ross Gardler a écrit : ...I envision being able to build a Cocoon application by saying "given these input types, I want this output type" and to have the resulting application automatically tested against my test inputs... Not sure if I understand what you mean, could you give an example? Most businesses are made up of common business processes. The odd one will be unique to that business, but most are common. In the case of the unique practices the software needs to be customised, but in the case of common practices an "off-the-shelf" solution is sufficient. Each common practice has a set of inputs, a set of intermediate states and a set of outputs. If the new Cocoon provides a series of components for transforming from an input to an ouput we can use these components to build complete applications. Here's a simple example: Inputs: - purchase order Intermediate Docs: - customer details - credit approval - stock level Required outputs: - Invoice - Packing slip It is possible to describe this process as a series of components, i.e. to get from a "purchase order" document to a "customer details" document use component ABC, to get from a "purchase order" to a "credit approcal" use component XYZ etc. It is possible to automate the discovery of these components and thus to automatically configure an application to move from document A to document B. This seem a lot like the concepts of an ESB, someone mentioned ServiceMix [www.servicemix.org] in a recent thread. It's an interesting vision but is Cocoon NG really going to compete in that arena? See Daniels recent mail about wanting Cocoon to be a set of components that can be used in any context, guided by patterns. That's *exactly* what I'm talking about. When I was first drawn to Cocoon it was a much simpler beast, it was still an XML processing framework. We all know what has happened since, it's been said many times in this and related threads. However, when Cocoon was nothing more than a sitemap defining XML processing pipelines it was a small step away from being eveything any "ESB" today claims to be. "ESB" is only a buzzword, this stuff has been around for many years. Now I'd better stop before I start convincing myself that people will find all 600 pages of my PhD interesting ;-) I'll return to this one day when the vision is settled and in place, and I have the time to express it in a reasonably concise RT. Ross
Re: ajax cform and forms_onsubmitHandlers issues
So the forms_onsubmit() method needs boolean indicator as to whether the form has already been submitted for server processing (distinct from an ajax forms submission) to know whether it should process the onsubmit handlers array. It should no longer simply use the forms_onsubmtHandlers stack for that indication. When ajax is submitting the form, maybe it can pass an object to the forms_onsubmit() indicating that this is an Ajax call. It would also be nice to have an object to hold all the global forms variables (so that we could scope them and eventually support mutliple forms on the same page). Regards, Eric
Re: [Poll] We need to align on one point (was Re: [Vision] Knowing When We are Done)
[ X] Mix and match (not as simple, but is status quo with today) Assuming we can move to a componentized Cocoon, the components will be usable from both javascript or java. (or from JRuby for that matter, which is supposed to support Rails [1] in a few months ;-) -Bertrand [1] http://jruby.sourceforge.net/docs/milestones.shtml smime.p7s Description: S/MIME cryptographic signature
Re: An entirely new beast
Ugo Cei wrote: Il giorno 07/dic/05, alle ore 15:28, Vadim Gritsenko ha scritto: Cocoon NG is nice, even too nice. Cocoon NT or Cocoon XP are much better. No chance that it could be released without renaming. Hmmm ... maybe Cocoon 360? ;-) Ugo MS Cocoon
Re: [Poll] We need to align on one point (was Re: [Vision] Knowing When We are Done)
Following the vision that Bertrand and Marc expressed, I'd like to see Cocoon becoming less of a xml webapp framework and more of a set of reuasble xml webapp components and a set of design patterns. With this I measn that you can use the parts of Cocoon that you like, in the way you like in your webapp, without having to buy a whole religion. So following this, the flowscript controller should be less tightly integrated than it is today. We have a flowscript servlet that can be used stand alone in other projects. When you use it in Cocoon, you just inject the Cocoon component model in it and it can call the sitemap controller or other controllers through the servlet context (or whatever reusable way we come up with). The Cocoon component model is written in Java and properly POJOfied, so it doesn't need to have any JavaScript awareness. And a JavaFlow controler can work in a similar way. If I understod Torsten right, there is allready a JavaFlow servlet. Given the need for backcompability and the fact that a flowscript controller is rather usefull in its own right, for people who happen to like JavaScript. It is reasonable that we maintain such a beast during the forseeable future. It doesn't have to be part of the core of Cocoon though. --- o0o --- So given that we factor out the flowscript controller from the core, the question is what your question bellow will mean. It will be up to the application writer what to use. And hopefully our blocks will take of more as more independent projects, that do whatever they find best. Except for in the CForms block, IIRC, I don't think that we have written that much flowscript code that is supposed to be reused. Despite that flowscripts have been around for quite a long time. For the actual core of Cocoon I envision that everything have clean and well designed Java interfaces, so that you can develop purely in a Java world. If we build reusable webapps, I would have nothing against focusing on Java. And also focusing on Java in the documentation would be Ok for me. --- o0o --- But above all I would prefer if we focused on providing a small, clean, stable and reusable set of core xml webapp components and leave it to the users to do whatever they want with them. /Daniel Berin Loritsch wrote: ... Now, my chief goal and my chief vision for Cocoon is to simplify the number of concepts a user has to learn before they are effective with Cocoon. That might mean that we provide JavaScript as the only way to interact with the core. All web applications would be written in JavaScript from control to helper functions. Or all web applications would be written in Java from control to helper functions. It is incredibly awkward to mix and match as the default way to do things. It is difficult to explain when and where to use which language. Now, for advanced users who don't mind the mix and match, I have no problem with having tutorials on how to do that properly. What's your preference for the vision? [ ] All web apps written in JavaScript [ ] All web apps written in pure Java [ X ] Mix and match (not as simple, but is status quo with today)
Re: An entirely new beast
Ugo Cei wrote: Il giorno 07/dic/05, alle ore 15:28, Vadim Gritsenko ha scritto: Cocoon NG is nice, even too nice. Cocoon NT or Cocoon XP are much better. No chance that it could be released without renaming. Hmmm ... maybe Cocoon 360? ;-) Nothing new, no innovation at all. Did we remember IBM 360[1] ;-) Best Regards, Antonio Gallardo. [1] http://www.beagle-ears.com/lars/engineer/comphist/ibm360.htm Ugo
Re: ajax cform and forms_onsubmitHandlers issues
Quoin Developers wrote:
I believe that the source of the problem is cforms.js
cocoon.forms.submitForm = function(element, name) {
...
forms_onsubmitHandlers = new Array();
Removing the above line seems to solve the problem. Any reason why
that line should be there? Can it be removed?
The "forms_onsubmitHandlers" JS variable is an event stack. It allows
form widgets to register one or more events that are triggered before
the form is submited.
The original implementation (before AJAX) resets the
"forms_onsubmitHandlers" variable every time the form need to be
submited back to the server. It helps to detect if the form was already
submited by the user. It avoids sending twice the request to the server.
The trick is: when the user press the 1st time te button it ran all the
events and reset the "forms_onsubmitHandlers" variable to clean up the
stack, hence when the user press the second time the button there are no
more events to call.
The above implementation works pretty well in non-AJAX mode, because
when the user response came, the page do a full reload and every widget
is allowed to register again the events it needs.
Unfortunately, this does not work in AJAX mode. This is due the AJAX
nature. AJAX does not make a full page reload. For this reason, the
widgets that registered an event and don't came back in a response loos
the onsubmit event. They don't have the opportunity to register again
his events on the forms_onsubmitHandlers stack. :-(
WDYT?
Best Regards,
Antonio Gallardo.
Re: Cocoon 2.2 - Build and deployment with Maven2
Marc Portier wrote:
Reinhard Poetz wrote:
Today, Jorg and I had a long chat about this. In short, we failed to
find a solution that works with Maven 2 as it is today. The problem is
that Cocoon block requirements have a different purpose than Maven 2
dependencies. Cocoon block requirements desribe what a block needs to
run while Maven 2 dependencies describe what a project needs to compile.
Additionally we want to describe our dependencies as contracts and not
as direct dependencies to a JAR.
how is that different?
well, in Cocoon we don't have "direct" dependencies between blocks. A Cocoon
block only requires other blocks that implement a certain contract. Have a look
at this example:
http://apache.org/cocoon/blocks/cob/1.0";
id="http://cocoon.apache.org/blocks/anyblock/1.0";>
http://cocoon.apache.org/contracts/portal/1.0";
name="portal"
default="http://cocoon.apache.org/blocks/portal/1.0.2";
/>
Here the block "http://cocoon.apache.org/blocks/anyblock/1.0"; requires a block
that implements the contract "http://cocoon.apache.org/contract/portal/1.0";.
One block that obiously implements this contract is
"http://cocoon.apache.org/blocks/portal/1.0.2";.
Compare this with a Maven project descriptor. There we say which *concrete"
dependencies (jars, blocks) one project has. In this special case this is a
block dependency.
> I would guess this just means your 'contract' is available in a separate
> jar/artifact from your implementation?
I'm not sure if I understand completly what you're asking/suggesting here. Do
you mean that we should make the contract a JAR dependency too?
> is that a constraint that is hard to keep up with?
I'm not sure. I have to think more about it. In any case, having the contracts
as JAR dependencies is an interesting thought!
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
Re: [Poll] We need to align on one point (was Re: [Vision] Knowing When We are Done)
On Dec 7, 2005, at 6:23 AM, Berin Loritsch wrote: [X] Mix and match (not as simple, but is status quo with today)
Re: An entirely new beast
Ugo Cei wrote: Il giorno 07/dic/05, alle ore 15:28, Vadim Gritsenko ha scritto: Cocoon NG is nice, even too nice. Cocoon NT or Cocoon XP are much better. No chance that it could be released without renaming. Hmmm ... maybe Cocoon 360? ;-) No, CS3 implemented on the cell processor ;P
Re: [Poll] We need to align on one point (was Re: [Vision] Knowing When We are Done)
So far it seems as if we are looking at two options: Pure Java or status quo. And so far we are something along the lines of 2 for Java and 2 (possibly 3) for status quo. Anyone else have input? Ugo Cei wrote: Il giorno 07/dic/05, alle ore 15:23, Berin Loritsch ha scritto: What's your preference for the vision? [ ] All web apps written in JavaScript [X ] All web apps written in pure Java [ ] Mix and match (not as simple, but is status quo with today) Ugo
Re: An entirely new beast
Il giorno 07/dic/05, alle ore 15:28, Vadim Gritsenko ha scritto: Cocoon NG is nice, even too nice. Cocoon NT or Cocoon XP are much better. No chance that it could be released without renaming. Hmmm ... maybe Cocoon 360? ;-) Ugo -- Ugo Cei Tech Blog: http://agylen.com/ Open Source Zone: http://oszone.org/ Wine & Food Blog: http://www.divinocibo.it/
Re: [Poll] We need to align on one point (was Re: [Vision] Knowing When We are Done)
Il giorno 07/dic/05, alle ore 15:23, Berin Loritsch ha scritto: What's your preference for the vision? [ ] All web apps written in JavaScript [X ] All web apps written in pure Java [ ] Mix and match (not as simple, but is status quo with today) Ugo -- Ugo Cei Tech Blog: http://agylen.com/ Open Source Zone: http://oszone.org/ Wine & Food Blog: http://www.divinocibo.it/
Re: [Vision] Knowing When We are Done
Il giorno 07/dic/05, alle ore 11:43, Ross Gardler ha scritto: Most businesses are made up of common business processes. The odd one will be unique to that business, but most are common. In the case of the unique practices the software needs to be customised, but in the case of common practices an "off-the-shelf" solution is sufficient. Sorry but I don't believe this dream of high-level, off-the-shelf, customizable components will ever come to fruition, Cocoon or not. On this point, I agree with Dan Creswell [1]: "All attempts at creating high-level business components that can be re-used and re-configured have failed previously. This failure has not been for technical reasons - it happens because the requirements that yielded the original component interface were sufficiently different from the new requirements so as to require re-writing massive chunks of functionality." And David Heinemeier Hansson as well [2]: "On the surface, the dream of components sounds great and cursory overviews of new projects also appear to be "a perfect fit". But they never are. Reuse is hard. Parameterized reuse is even harder. And in the end, you're left with all the complexity of a swiss army knife that does everything for no one at great cost and pain." I'd be content if Cocoon was simply a powerful and easy-to-use web application development framework. Ugo [1]: http://jroller.com/page/dancres/20050218#soa_doomed [2]: http://www.loudthinking.com/arc/000407.html -- Ugo Cei Tech Blog: http://agylen.com/ Open Source Zone: http://oszone.org/ Wine & Food Blog: http://www.divinocibo.it/
Re: An entirely new beast
Vadim Gritsenko wrote: Sylvain Wallez wrote: In the meantime, what about simply "CoNG", for "Cocoon New Generation". This name isn't that nice, which will make us want to find something else, but solves the immediate need of having a word to designate this new thing without fighting about version numbers, separate projects, my name is nicer than yours, etc. Cocoon NG is nice, even too nice. Cocoon NT or Cocoon XP are much better. No chance that it could be released without renaming. Hehe, that's exactly the idea, just use a dumb name to stop naming discussions. We'll see later if it's to be named Cocoon Vista :-P Sylvain -- Sylvain WallezAnyware Technologies http://bluxte.net http://www.anyware-tech.com Apache Software Foundation Member Research & Technology Director
Re: [Poll] We need to align on one point (was Re: [Vision] Knowing When We are Done)
Berin Loritsch wrote: In the exchange below I did some creative snipping to emphasize where we are not 100% aligned on vision. Below I will bring out my points, knowing that I'm not the guy who sets the tone for Cocoon. We are collectively setting the tone, and your inputs are very valuable! I can infer from Sylvain's vision that he sees value in using JavaScript on the server as well as on the cient. And why not? We have the solution already in place. Yep. Several reasons for this: - JS provides a more concise writing, which is great when you write the glue code of your application, - my experience is different than yours, as I've seen many people using Cocoon being unable to write a Java class but perfectly able to write a flowscript to drive page flow, display forms and glue components together. Now, the Pros of using JavaScript that I can see are as follows: * Common syntax on server and client * Easy to use Java objects in JavaScript code * Easy to add support for continuations The cons I see are as follows: * API depends on bound objects (not consistent between client and server) Yep. Now stuff like JSON [1] can allow for *very* easy client/server communications in Ajax scenarios. * No testing framework for JavaScript Code People writing Ajax libraries are getting serious about unit tests. Have a look at [2] and [3]. * Requires embedding a JavaScript runtime in the server Rhino will be embedded in JDK 1.6 (or whatever its name) * We can't use the same debugger in our IDE to step through server side JavaScript code Right. * No IDE support for JavaScript There's a JS plugin in Eclipse webtools and the amazing JSEclipse [4] that does autocompletion of function and argument names, plus tooltips and all that stuff. It even accepts additional completion description files that we could generate automatically from the API that we expose to the JS engine. * It's another language to have to learn Yeah, but a language that many people already now. The testing framework for JavaScript is easily overcome. We could create something to get that working. In Java 6 (still being worked out) JavaScript is supposed to be embedded into the core, so when the IDEs tool for Java 6, my objections involving IDE and debugger will go away--but that is a ways off still. Which leaves us with the API con and the learning con. I will stick to my guns for my belief that JavaScript will fail in its mission to bring "less technical" people to work on the server side. Less technical people need all the handholding they can get, so without IDE support and a well defined API they won't know what to do. That does not mean that JavaScript is evil, or that it doesn't have a place on the server or in Cocoon. I just think we are kidding ourselves if we think it will allow less technical people to do a programmer's job. Again, I have seen semi-technical people doing great things with JS. Not all the bells and whistles of the full J2EE stack, but some fairly advanced stuff they could never have done with only the Java API (nor PHP, btw). So the flow controller is really a place (and the *only* one actually) where I value having two implementations, one in Java and one in JS. However, these two implementations should really be a very thin layer on top of a common controller infrastructure, both to reduce the effort and ensure long-term consistency. What's your preference for the vision? [ ] All web apps written in JavaScript [ ] All web apps written in pure Java [X] Mix and match (not as simple, but is status quo with today) Sylvain [1] http://www.crockford.com/JSON/ [2] http://archive.dojotoolkit.org/nightly/testtools/ [3] http://www.edwardh.com/jsunit/ [4] http://www.interaktonline.com/Products/Eclipse/JSEclipse/Overview/ -- Sylvain WallezAnyware Technologies http://bluxte.net http://www.anyware-tech.com Apache Software Foundation Member Research & Technology Director
Re: [Poll] We need to align on one point (was Re: [Vision] Knowing When We are Done)
Ross Gardler wrote: Berin Loritsch wrote: I would argue that what you are talking about is a domain specific language in the guise of configuration (just like your hibernate descriptors and ant scripts). Sometimes, DSL's bring many benefits, just consider the sitemap. Do we want to know more or is this a step too far at this stage of discussion? I'm aware that t could go off on a horrible tangent and we'll never find the real vision, it may be better for me to bring this up again at a more appropriate time, after all its an implementation detail. I think that is enough for this part of the discussion. I'm just trying to help us get aligned at the basic, core level. Nothing would prevent what you want to do in Cocoon.
Re: [Poll] We need to align on one point (was Re: [Vision] Knowing When We are Done)
Berin Loritsch wrote: Ralph Goers wrote: None of these. I have a vision where the business services are implemented in Java, the web application is defined in a stateful flow controller (xml config) and the views are generated using pipelines with standard components. So my answer is - No programming language on the server, just configuration. This is what I was getting at with my wish to see apps defined in terms of "given this type of input I want this type of output". Shudder. That could be a nice add on to Cocoon. Perhaps a BPL (Business Process Language, an XML standard for what you are talking about) application. In my prototype of such a system I evaluated all the BPL's of the time (and have since updated this again). I rejected them all as being far too complex, verbose and too much like a full blown programming language. What I ended up using was XML Pipelines, a very simple language that covers far more of the required workflows than any of the specific BPL's Why is this relevant here? You would be amazed at how many similarities there are between the solution I developed and Cocoon (that's why I was drawn to Cocoon in the first place). I would argue that what you are talking about is a domain specific language in the guise of configuration (just like your hibernate descriptors and ant scripts). Sometimes, DSL's bring many benefits, just consider the sitemap. Do we want to know more or is this a step too far at this stage of discussion? I'm aware that t could go off on a horrible tangent and we'll never find the real vision, it may be better for me to bring this up again at a more appropriate time, after all its an implementation detail. Ross
Re: [Poll] We need to align on one point (was Re: [Vision] Knowing When We are Done)
Berin Loritsch wrote: Ralph Goers wrote: None of these. I have a vision where the business services are implemented in Java, the web application is defined in a stateful flow controller (xml config) and the views are generated using pipelines with standard components. So my answer is - No programming language on the server, just configuration. Shudder. That could be a nice add on to Cocoon. Perhaps a BPL (Business Process Language, an XML standard for what you are talking about) application. I would argue that what you are talking about is a domain specific language in the guise of configuration (just like your hibernate descriptors and ant scripts). I'm just talking about using Spring Webflow being called from a JavaFlow class. For my employer I have already written a generic (Cocoon) action that can call any business service that is configured, as long as the business service follows some simple rules about its input and output. Converting that to a Webflow action shouldn't be too much trouble. Ralph
Re: [Vision] Knowing When We are Done
Berin: I envision a Cocoon which takes its principle strengths in separation of concerns to make developing web applications easier. Modern web applications provide machine-to-machine communications via web services and email as well as various views into the data. I envision a Cocoon that makes Java look attractive again, proving that it is suited for the rapidly changing web environment. I envision a Cocoon which avoids configuration where it is unnecessary, and instead employs easy to understand conventions. I envision a Cocon that is able to be extended using standard Java mechanisms such as the JAR services approach. I envision a Cocoon where I only have to learn Java and XML to be affective. I see a Cocoon where testing is embraced, encouraged, and made easy. I see a Cocoon where any errors/exceptions tell me exactly where the problem lies, down to the source code line--even if that source is not Java code. I see a Cocoon where the Sitemap is not the preferred way to map URLs to generating content. I see a cocoon where convention dictates the pipeline. A note about blocks: while they *can* be helpful, they are not central to my vision. I am open to them, and if they are a part of Cocoon's future then the following applies: "I see a cocoon where communities can share solutions packaged up in blocks to be reused in other applications". I'm thinking solutions like user authentication, portal support, or other generic solutions. Sylvain: I envision a Cocoon where I can use the power of the pipeline engine in almost every environment where there is some XML data to be processed. I envision a Cocoon where people can use a single unified scripting language for both the client and the server. I envision a Cocoon where the expression used to access a given data is the same everywhere. I envision a Cocoon where any change to a source file, even Java, is instantly reflected in my application. Ross: I envision a transparent integration of remote resources. I envision a transparent integration of dynamic and static resources. I envision being able to build a Cocoon application by saying "given these input types, I want this output type" and to have the resulting application automatically tested against my test inputs. Torsten: Plus I envision to have good testcase coverage for the whole system. I envision to have a clean core that shines through simplicity. I envision a non-viral component handling (One word: AbstractLogEnabled). POJOs and factories where feasible. I envision being able to drop block jar into a folder and extend my cocoon's functionality without configuring or doing anything else. (Maybe even at runtime.) I envision a cocoon where flow is not a 2nd class citizen. I envision a cocoon where your components like caches might persist. I envision log messages that are also understandable when you are not a core developer. I envision a cocoon where you have to write less. Vadim: I envision Cocoon where components configurations are consistent (and easy to guess), with sensible defaults. I envision good set of test cases running nightly which flag any regressions early and those regressions are resolved. Solid core with clean interfaces between layers (pipeline engine - sitemap machinery - entry points/environments). Easy to read and maintain core implementation. Single expression language throughout with unified object model. Solidifying existing functionality is prioritized over expanding into new territories with quickly hacked-together code. Newly hacked code is prioritized to first get it consistent with overall architecture, then functioning right, and only then gets bells & whistles. Released CForms. Vadim PS Last one is a tease :)
Re: [Poll] We need to align on one point (was Re: [Vision] Knowing When We are Done)
Berin Loritsch wrote: What's your preference for the vision? [ ] All web apps written in JavaScript [ ] All web apps written in pure Java [X] Mix and match (not as simple, but is status quo with today) Vadim
Re: [Poll] We need to align on one point (was Re: [Vision] Knowing When We are Done)
Ralph Goers wrote: None of these. I have a vision where the business services are implemented in Java, the web application is defined in a stateful flow controller (xml config) and the views are generated using pipelines with standard components. So my answer is - No programming language on the server, just configuration. Shudder. That could be a nice add on to Cocoon. Perhaps a BPL (Business Process Language, an XML standard for what you are talking about) application. I would argue that what you are talking about is a domain specific language in the guise of configuration (just like your hibernate descriptors and ant scripts).
Re: [Poll] We need to align on one point (was Re: [Vision] Knowing When We are Done)
hepabolu wrote: Berin Loritsch wrote: What's your preference for the vision? [ ] All web apps written in JavaScript [ ] All web apps written in pure Java [X] Mix and match (not as simple, but is status quo with today) With Ajax and other bells and whistles on the client side, there will always be javascript. I'm focused on the server side. I'm not even contesting the client side use of javascript.
Re: [Poll] We need to align on one point (was Re: [Vision] Knowing When We are Done)
None of these. I have a vision where the business services are implemented in Java, the web application is defined in a stateful flow controller (xml config) and the views are generated using pipelines with standard components. So my answer is - No programming language on the server, just configuration. Berin Loritsch wrote: Berin Loritsch wrote: What's your preference for the vision? [ ] All web apps written in JavaScript [X] All web apps written in pure Java [ ] Mix and match (not as simple, but is status quo with today)
Re: [Poll] We need to align on one point (was Re: [Vision] Knowing When We are Done)
Berin Loritsch wrote: What's your preference for the vision? [ ] All web apps written in JavaScript [ ] All web apps written in pure Java [X] Mix and match (not as simple, but is status quo with today) With Ajax and other bells and whistles on the client side, there will always be javascript. Bye, Helma
Re: An entirely new beast
Sylvain Wallez wrote: In the meantime, what about simply "CoNG", for "Cocoon New Generation". This name isn't that nice, which will make us want to find something else, but solves the immediate need of having a word to designate this new thing without fighting about version numbers, separate projects, my name is nicer than yours, etc. Cocoon NG is nice, even too nice. Cocoon NT or Cocoon XP are much better. No chance that it could be released without renaming. Vadim (:-P for humor impaired)
Re: [Poll] We need to align on one point (was Re: [Vision] Knowing When We are Done)
Berin Loritsch wrote: What's your preference for the vision? [ ] All web apps written in JavaScript [X] All web apps written in pure Java [ ] Mix and match (not as simple, but is status quo with today)
[Poll] We need to align on one point (was Re: [Vision] Knowing When We are Done)
In the exchange below I did some creative snipping to emphasize where we are not 100% aligned on vision. Below I will bring out my points, knowing that I'm not the guy who sets the tone for Cocoon. Torsten Curdt wrote: Berin: ... I envision a Cocoon which takes its principle strengths in separation of concerns to make developing web applications easier. ... I envision a Cocoon where I only have to learn Java and XML to be affective. ... Sylvain: ... I envision a Cocoon where people can use a single unified scripting language for both the client and the server. ... Torsten: ... I envision a cocoon where flow is not a 2nd class citizen. The conflict in vision is actually between Sylvain and I. OK, conflict is a strong word, more like we are not on the same page. Both Sylvain and I are aligned with Torsten, but we most likely have different ideas on how to get there. Bottom line: I am in favor of Java Flow, and avoiding embedding any scripting languages in the core. If you want to add a scripting language front end, I would suggest it be an add-on. Why? Because it both simplifies the design, and it minimizes the number of things the user (in my experience it is always a Java developer) has to learn before they can be effective. I can infer from Sylvain's vision that he sees value in using JavaScript on the server as well as on the cient. And why not? We have the solution already in place. Now, the Pros of using JavaScript that I can see are as follows: * Common syntax on server and client * Easy to use Java objects in JavaScript code * Easy to add support for continuations The cons I see are as follows: * API depends on bound objects (not consistent between client and server) * No testing framework for JavaScript Code * Requires embedding a JavaScript runtime in the server * We can't use the same debugger in our IDE to step through server side JavaScript code * No IDE support for JavaScript * It's another language to have to learn The testing framework for JavaScript is easily overcome. We could create something to get that working. In Java 6 (still being worked out) JavaScript is supposed to be embedded into the core, so when the IDEs tool for Java 6, my objections involving IDE and debugger will go away--but that is a ways off still. Which leaves us with the API con and the learning con. I will stick to my guns for my belief that JavaScript will fail in its mission to bring "less technical" people to work on the server side. Less technical people need all the handholding they can get, so without IDE support and a well defined API they won't know what to do. That does not mean that JavaScript is evil, or that it doesn't have a place on the server or in Cocoon. I just think we are kidding ourselves if we think it will allow less technical people to do a programmer's job. Now, my chief goal and my chief vision for Cocoon is to simplify the number of concepts a user has to learn before they are effective with Cocoon. That might mean that we provide JavaScript as the only way to interact with the core. All web applications would be written in JavaScript from control to helper functions. Or all web applications would be written in Java from control to helper functions. It is incredibly awkward to mix and match as the default way to do things. It is difficult to explain when and where to use which language. Now, for advanced users who don't mind the mix and match, I have no problem with having tutorials on how to do that properly. What's your preference for the vision? [ ] All web apps written in JavaScript [ ] All web apps written in pure Java [ ] Mix and match (not as simple, but is status quo with today)
Re: [Vision] Knowing When We are Done
Il giorno 07/dic/05, alle ore 10:13, Sylvain Wallez ha scritto: I was expecting you to also add "I envision a Cocoon where all exceptions would be unckecked" :-) Ça va sans dire. Oh, by the way, how do you expect to be able to distribute Cocoon in France now that they are going to outlaw Open Source software? ;-) Ugo
Re: Cocoon 2.2 - Build and deployment with Maven2
Reinhard Poetz wrote: > Today, Jorg and I had a long chat about this. In short, we failed to > find a solution that works with Maven 2 as it is today. The problem is > that Cocoon block requirements have a different purpose than Maven 2 > dependencies. Cocoon block requirements desribe what a block needs to > run while Maven 2 dependencies describe what a project needs to compile. > Additionally we want to describe our dependencies as contracts and not > as direct dependencies to a JAR. > how is that different? I would guess this just means your 'contract' is available in a separate jar/artifact from your implementation? is that a constraint that is hard to keep up with? -marc= (only taking first steps in the maven/block work, so seeking no more then understanding) -- Marc Portierhttp://outerthought.org/ Outerthought - Open Source, Java & XML Competence Support Center Read my weblog athttp://blogs.cocoondev.org/mpo/ [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: An entirely new beast
Upayavira wrote: ... So, what I'd propose is we choose another name, and consider it to be a new subproject of Cocoon. A "new, exciting web development framework from the people that brought you Apache Cocoon". Right, let us stay above the boring tech talk and focus on finding a new name that symbolizes in an accurate and yet engaging way our common, deeply felt need for moving beyond the current frustration, towards a new, different, bright and sexy future. And, the existing Cocoon carries on as long as people want and need it. Maybe 3.0 could still be the OSGi version. It may well still bring huge benefits to those using the current generation of Cocoon. Great, why choose between focusing on 2.1.x, 2.2, our previous idea about 3.0 and the new vision. Lets just have it all. ... (P.S. If people do agree, I'd say please refrain from providing possible names at the moment. We can discuss that later. For now, let's see if people agree with what I am suggesting). I agree, still I can't refrain from suggesting Cocoon Raba Hiff, http://asplund.arch.kth.se/~a96_osa/bonk/ptoday.html, as a hommage to a great predecesor. Let us together strive for maximizing the dev-list/cvs-list volume ratio. /Daniel [I'm deeply sorry, the voices in my head took control over my writing for a short while]
Re: [Vision] Knowing When We are Done
Ross Gardler wrote: Bertrand Delacretaz wrote: Le 7 déc. 05, à 09:10, Ross Gardler a écrit : ...I envision being able to build a Cocoon application by saying "given these input types, I want this output type" and to have the resulting application automatically tested against my test inputs... Not sure if I understand what you mean, could you give an example? Most businesses are made up of common business processes. The odd one will be unique to that business, but most are common. In the case of the unique practices the software needs to be customised, but in the case of common practices an "off-the-shelf" solution is sufficient. Each common practice has a set of inputs, a set of intermediate states and a set of outputs. If the new Cocoon provides a series of components for transforming from an input to an ouput we can use these components to build complete applications. Here's a simple example: Inputs: - purchase order Intermediate Docs: - customer details - credit approval - stock level Required outputs: - Invoice - Packing slip It is possible to describe this process as a series of components, i.e. to get from a "purchase order" document to a "customer details" document use component ABC, to get from a "purchase order" to a "credit approcal" use component XYZ etc. It is possible to automate the discovery of these components and thus to automatically configure an application to move from document A to document B. This seem a lot like the concepts of an ESB, someone mentioned ServiceMix [www.servicemix.org] in a recent thread. It's an interesting vision but is Cocoon NG really going to compete in that arena? Mats
Re: [Vision] Knowing When We are Done
Bertrand Delacretaz wrote: Le 7 déc. 05, à 09:10, Ross Gardler a écrit : ...I envision being able to build a Cocoon application by saying "given these input types, I want this output type" and to have the resulting application automatically tested against my test inputs... Not sure if I understand what you mean, could you give an example? Most businesses are made up of common business processes. The odd one will be unique to that business, but most are common. In the case of the unique practices the software needs to be customised, but in the case of common practices an "off-the-shelf" solution is sufficient. Each common practice has a set of inputs, a set of intermediate states and a set of outputs. If the new Cocoon provides a series of components for transforming from an input to an ouput we can use these components to build complete applications. Here's a simple example: Inputs: - purchase order Intermediate Docs: - customer details - credit approval - stock level Required outputs: - Invoice - Packing slip It is possible to describe this process as a series of components, i.e. to get from a "purchase order" document to a "customer details" document use component ABC, to get from a "purchase order" to a "credit approcal" use component XYZ etc. It is possible to automate the discovery of these components and thus to automatically configure an application to move from document A to document B. This latter part is, of course very complex and hard to do. I have a prototype, written for my PhD about 4 years ago, it's not Cocoon based, but has many parallels with both Cocoon and recent discussions regarding making Cocoon much easier to use (some info at http://www.saafe.org) I'm not suggesting we tackle this latter part today. But as part of the long term vision it may be interesting. Ross
Re: An entirely new beast
Upayavira wrote: I've been thinking more about Sylvain's proposal and ideas. And would like to suggest a way to look at it and see how it fits into the context of what we already have. Sylvain is proposing something different, something that is likely to be almost entirely incompatible with the existing Cocoon. If it is almost entirely incompatible, how can we think of it as in some way being a _continuation_ of what we already have? This, it is _not_ Cocoon 3.0. It is something else. Thus, I agree with Sylvain that it should have a new name, but think that Raccoon is a bad one, as it is a play on Cocoon and could never really be the project's real name. Imagine it, "powered by Apache Cocoon Raccoon". Hmm. So, what I'd propose is we choose another name, and consider it to be a new subproject of Cocoon. A "new, exciting web development framework from the people that brought you Apache Cocoon". And, the existing Cocoon carries on as long as people want and need it. Maybe 3.0 could still be the OSGi version. It may well still bring huge benefits to those using the current generation of Cocoon. Thoughts? (Other than "oh no, not another naming discussion!") Regards, Upayavira (P.S. If people do agree, I'd say please refrain from providing possible names at the moment. We can discuss that later. For now, let's see if people agree with what I am suggesting). The initial RT was more about "enhancements", i.e. I did not write explicitely that the amount of changes required to implement them would lead to a large or even complete rewrite, even if I was personally convinced of it. I wanted to test the waters and see how people would react. Now it happened that many people agreed that some deep changes were needed, and that what I proposed was going in the right direction. While some people consider that a revolution is not the way to go, those that do agree on the stated goals of simplification, layering, improved consistency, etc, and a common vision is currently being built. So yes, this is something different. Just like Cocoon 2 was also different from Cocoon 1. And it will be incompatible with the current Cocoon, even if it uses many of its core principles. So do we need a new name or a major version number? As I already said, Cocoon suffers from its past as a publication framework, and most of the people that never used it still consider it so, when we all know that it's really much more than this. So a new name is a way to say to the masses that it's definitely no more "just" a publication framework. Now we should not denigrate the current Cocoon nor our history. That was the idea behind "Raccoon": used alone, it shows its filiation. But it's right that "Cocoon Racoon" really sounds awkward. So as we don't know yet if it will be "Apache Cocoon 3.0", "Apache Cocoon FooBar" or "Apache FooBar", let's give it a code name and see along the road how we want to name it. Doing a global search/replace to change a root package name is an easy thing. In the meantime, what about simply "CoNG", for "Cocoon New Generation". This name isn't that nice, which will make us want to find something else, but solves the immediate need of having a word to designate this new thing without fighting about version numbers, separate projects, my name is nicer than yours, etc. Sylvain -- Sylvain WallezAnyware Technologies http://bluxte.net http://www.anyware-tech.com Apache Software Foundation Member Research & Technology Director
Re: [Vision] Knowing When We are Done
Ugo Cei wrote: Il giorno 07/dic/05, alle ore 09:40, Torsten Curdt ha scritto: Plus I envision to have good testcase coverage for the whole system. I envision to have a clean core that shines through simplicity. I envision a non-viral component handling (One word: AbstractLogEnabled). POJOs and factories where feasible. I envision being A-ha! This is a longtime favorite of mine. AbstractLogEnabled must DIE, DIE, DIE! ;-) I was expecting you to also add "I envision a Cocoon where all exceptions would be unckecked" :-) Sylvain -- Sylvain WallezAnyware Technologies http://bluxte.net http://www.anyware-tech.com Apache Software Foundation Member Research & Technology Director
Re: [Vision] Knowing When We are Done
Il giorno 07/dic/05, alle ore 09:40, Torsten Curdt ha scritto: Plus I envision to have good testcase coverage for the whole system. I envision to have a clean core that shines through simplicity. I envision a non-viral component handling (One word: AbstractLogEnabled). POJOs and factories where feasible. I envision being A-ha! This is a longtime favorite of mine. AbstractLogEnabled must DIE, DIE, DIE! ;-) Ugo -- Ugo Cei Tech Blog: http://agylen.com/ Open Source Zone: http://oszone.org/ Wine & Food Blog: http://www.divinocibo.it/
Re: [Vision] Knowing When We are Done
Berin: I envision a Cocoon which takes its principle strengths in separation of concerns to make developing web applications easier. Modern web applications provide machine-to-machine communications via web services and email as well as various views into the data. I envision a Cocoon that makes Java look attractive again, proving that it is suited for the rapidly changing web environment. I envision a Cocoon which avoids configuration where it is unnecessary, and instead employs easy to understand conventions. I envision a Cocon that is able to be extended using standard Java mechanisms such as the JAR services approach. I envision a Cocoon where I only have to learn Java and XML to be affective. I see a Cocoon where testing is embraced, encouraged, and made easy. I see a Cocoon where any errors/exceptions tell me exactly where the problem lies, down to the source code line--even if that source is not Java code. I see a Cocoon where the Sitemap is not the preferred way to map URLs to generating content. I see a cocoon where convention dictates the pipeline. A note about blocks: while they *can* be helpful, they are not central to my vision. I am open to them, and if they are a part of Cocoon's future then the following applies: "I see a cocoon where communities can share solutions packaged up in blocks to be reused in other applications". I'm thinking solutions like user authentication, portal support, or other generic solutions. Sylvain: I envision a Cocoon where I can use the power of the pipeline engine in almost every environment where there is some XML data to be processed. I envision a Cocoon where people can use a single unified scripting language for both the client and the server. I envision a Cocoon where the expression used to access a given data is the same everywhere. I envision a Cocoon where any change to a source file, even Java, is instantly reflected in my application. Ross: I envision a transparent integration of remote resources. I envision a transparent integration of dynamic and static resources. I envision being able to build a Cocoon application by saying "given these input types, I want this output type" and to have the resulting application automatically tested against my test inputs. Torsten: Plus I envision to have good testcase coverage for the whole system. I envision to have a clean core that shines through simplicity. I envision a non-viral component handling (One word: AbstractLogEnabled). POJOs and factories where feasible. I envision being able to drop block jar into a folder and extend my cocoon's functionality without configuring or doing anything else. (Maybe even at runtime.) I envision a cocoon where flow is not a 2nd class citizen. I envision a cocoon where your components like caches might persist. I envision log messages that are also understandable when you are not a core developer. I envision a cocoon where you have to write less. cheers -- Torsten PGP.sig Description: This is a digitally signed message part
Re: [Vision] Knowing When We are Done
Le 7 déc. 05, à 09:10, Ross Gardler a écrit : ...I envision being able to build a Cocoon application by saying "given these input types, I want this output type" and to have the resulting application automatically tested against my test inputs... Not sure if I understand what you mean, could you give an example? -Bertrand smime.p7s Description: S/MIME cryptographic signature
Re: [Vision] Knowing When We are Done
Sylvain Wallez wrote: Berin Loritsch wrote: In all the talks of redesign or not, there has been a recurring question as to the vision. Sylvain has outlined some things that he would like to see, but they really don't constitute a vision. They are a nice list of improvements, but they aren't a vision. In my experience the best visions really don't have to do with features and improvements, but with what we expect to be able to do with Cocoon. We need to be able to put our vision statement in one or two paragraphs, and it needs to convey a little more than technology. Visions contain emotional content as well. There are two kinds of visions. One is the kind that you use to attract users, "Oh, that's what I need and they approach things the way I expect". That's the kind that ends up on the front page. Then there's the kind of vision that explains how you think something should be done. Kind of like a how-to that describes what _should_ be instead of what is the case. It has to be something exciting, something that people can get behind. Now, whether we are talking about evolutionary change or revolutionary change, we need to have a common vision. How else will we ensure the transition goes as smoothly as possible? Good foundational principles of modern software development are just side issues. Let's take a look at what we want Cocoon to be. Below is my vision, which I hope starts discussion. We can start consolditing the common points once people post their visions. Let's gather the information, and then see if we can look at some commonalities and think a little outside the box to make as many of us happy as is practical. Berin's Vision I envision a Cocoon which takes its principle strengths in separation of concerns to make developing web applications easier. Modern web applications provide machine-to-machine communications via web services and email as well as various views into the data. I envision a Cocoon that makes Java look attractive again, proving that it is suited for the rapidly changing web environment. I envision a Cocoon which avoids configuration where it is unnecessary, and instead employs easy to understand conventions. I envision a Cocon that is able to be extended using standard Java mechanisms such as the JAR services approach. I envision a Cocoon where I only have to learn Java and XML to be affective. I see a Cocoon where testing is embraced, encouraged, and made easy. I see a Cocoon where any errors/exceptions tell me exactly where the problem lies, down to the source code line--even if that source is not Java code. I see a Cocoon where the Sitemap is not the preferred way to map URLs to generating content. I see a cocoon where convention dictates the pipeline. A note about blocks: while they *can* be helpful, they are not central to my vision. I am open to them, and if they are a part of Cocoon's future then the following applies: "I see a cocoon where communities can share solutions packaged up in blocks to be reused in other applications". I'm thinking solutions like user authentication, portal support, or other generic solutions. - That's my vision. What's yours? How much overlap is there? Let's start this discussion, I think we will be pleasantly surprised how close many of us are with where we want Cocoon to go. Oh yes, we are close. To all the above, add the following: I envision a Cocoon where I can use the power of the pipeline engine in almost every environment where there is some XML data to be processed. I envision a Cocoon where people can use a single unified scripting language for both the client and the server. I envision a Cocoon where the expression used to access a given data is the same everywhere. I envision a Cocoon where any change to a source file, even Java, is instantly reflected in my application. Whilst I agree with everything above I feel they are too focused on the developer side of things. Here are a couple of additions from the perspective of the end user: I envision a transparent integration of remote resources. I envision a transparent integration of dynamic and static resources. I envision being able to build a Cocoon application by saying "given these input types, I want this output type" and to have the resulting application automatically tested against my test inputs. Ross
Re: dealing with log messages from ehcache
That certainly does help to explain the difference in log-levels. Thanks Carsten. Someone should document that :-) The original problem still remains. How does Cocoon manage to get logkit to handle the ehcache messages, whereas with Forrest they come to the console? IIRC the integration with JCL was broken and Sylvain fixed it in trunk. cheers -- Torsten PGP.sig Description: This is a digitally signed message part
