Re: [Poll] We need to align on one point (was Re: [Vision] Knowing When We are Done)
Hi, On 7 Dec 2005, at 23:26, Thomas Lutz wrote: 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... To provide a counterpoint to this - we spoke with one large organisation that was really excited by being able to use JavaScript rather than Java, since it lowered the barrier to entry for some of their less-skilled developers and meant more people were able to work on the project. On 7 Dec 2005, at 14:23, 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) Andrew. -- Andrew Savory, Managing Director, Luminas Limited Tel: +44 (0)870 741 6658 Fax: +44 (0)700 598 1135 Web: http://www.luminas.co.uk/ Orixo alliance: http://www.orixo.com/
Re: [Poll] We need to align on one point (was Re: [Vision] Knowing When We are Done)
On Thursday 08 December 2005 02:10, Daniel Fagerstrom wrote: 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. Being a devout atheist, I must +1000 this one. Niclas
Re: [Poll] We need to align on one point (was Re: [Vision] Knowing When We are Done)
On Wednesday 07 December 2005 23:56, Sylvain Wallez wrote: * 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. Really?? How can it do code completion since the type is not known until runtime? In IDEA the completion only handles the DOM binding and some rare cases when the type can be derived. As for JS being easier for non-Java peeps, my take is; 1. To make JS useful the developers exposes useful object bindings. 2. There is no development environment to contend with. Align those and the JS vs Java argumentation becomes a different experience altogether. Adding to that is, the times when I have seen non-Java peeps making anything useful on JS-serverside is when they already know JS well from client development. So, the take is a lot about profiling the target before making hard-core decisions that JS is better for flow than Java. I, for one, can't stand JS, due to runtime hell. I very much agree with everything Berin have said in this thread. Cheers Niclas
Re: [Poll] We need to align on one point (was Re: [Vision] Knowing When We are Done)
On Wednesday December 07, 2005 6:26 pm, Thomas Lutz wrote: 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 snip type=everything I was feeling, and I'm not alone in my view/ 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. In my vision we can keep our pipelines, but remove most (if not all) of the XML configuration crap. Just some good solid conventions like rails. 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. Oh yes, spring flow... So, please :-), only one language, and as cocoon (or whatever it's name will be :-) ) is a J2EE framework: _Java_ I hear you, and hopefully even more. Sorry for the interference :-), regards, tom Please interfere. Users lurking on dev are more than welcome to contribute their oppinions.
Re: [Vision] Knowing When We are Done
Ross Gardler wrote: Now I'd better stop before I start convincing myself that people will find all 600 pages of my PhD interesting ;-) Any pointer for those that might be interested? 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 schrieb: So, please :-), only one language, and as cocoon (or whatever it's name will be :-) ) is a J2EE framework: _Java_ I hear you, and hopefully even more. Sorry for the interference :-), regards, tom Please interfere. Users lurking on dev are more than welcome to contribute their oppinions. I'm just a user of Cocoon too for some years now, lurking on this list for the same time and I'm eagerly following the recent discussions. What I can contribute to this discussion from our experience is, that FlowScript provided new ways for us to describe page flows. But development hasn't been that easy all the time. We had problems understanding why certain things behaved differently (e.g. JavaScript String vs. Java String) thus ending up in wrapping many strings with new java.lang.String(...) just in case it might not be a Java String. We had also problems debugging FlowScripts and so our code was full of debugging statements which we had to keep in production to be able to track down runtime problems. Please don't ask how huge our logfiles got :-). So for us it was just the concept of continuations which brought us some improvement but not the language itself. And we have just Java developers writing FlowScript code, since it is not possible (in our case) to write FlowScript without Java knowledge. I don't want to say, that it is not possible at all. But I think you have to provide a very strict layer to FlowScript (no direct access to Java at all) to give a JavaScript developer the possibility to be productive without being surprised. It would have been much easier for us, if JavaFlow with all the benefits of Java (JUnit, JavaDoc, Debugging, strong IDE support, ...) would have been ready for production the time we began to develop our applications ... Just my € 0.02 ... Cheers, Andreas
Re: [Vision] Knowing When We are Done
Sylvain Wallez wrote: Ross Gardler wrote: Now I'd better stop before I start convincing myself that people will find all 600 pages of my PhD interesting ;-) Any pointer for those that might be interested? This research is fairly old now (6 years), and things have moved on a little, although mostly in the wrong direction, as observed by others here (i.e. lets make highly configurable components and we'll never have to write code again). I have a couple of papers that might serve as a useful introduction: One covers the use of the XML Pipeline languages to define application templates [1], the other [2] introduces the design methodology that guides the selection of and development of components. This is probably way off topic from the perspective of Cocoon design discussion, but may be interesting nevertheless. I have much more detail in my thesis if anyone is interested in the really detailed stuff. Ross [1] http://citeseer.ist.psu.edu/cache/papers/cs/26837/http:zSzzSzwww.netobjectdays.orgzSznode02zSzdezSzConfzSzpublishzSz..zSz..zSz..zSz..zSzpdfzSz02zSzpaperszSznodezSz0110.pdf/supporting-component-based-software.pdf [2] I can't reproduce this one, but I will send you a copy of the presentation slides and notes offlist (others should ask if they want it)
Re: [Vision] Knowing When We are Done
Ross Gardler wrote: Sylvain Wallez wrote: Ross Gardler wrote: Now I'd better stop before I start convincing myself that people will find all 600 pages of my PhD interesting ;-) Any pointer for those that might be interested? This research is fairly old now (6 years), and things have moved on a little, although mostly in the wrong direction, as observed by others here (i.e. lets make highly configurable components and we'll never have to write code again). I have a couple of papers that might serve as a useful introduction: One covers the use of the XML Pipeline languages to define application templates [1], the other [2] introduces the design methodology that guides the selection of and development of components. This is probably way off topic from the perspective of Cocoon design discussion, but may be interesting nevertheless. I have much more detail in my thesis if anyone is interested in the really detailed stuff. Ross [1] http://citeseer.ist.psu.edu/cache/papers/cs/26837/http:zSzzSzwww.netobjectdays.orgzSznode02zSzdezSzConfzSzpublishzSz..zSz..zSz..zSz..zSzpdfzSz02zSzpaperszSznodezSz0110.pdf/supporting-component-based-software.pdf [2] I can't reproduce this one, but I will send you a copy of the presentation slides and notes offlist (others should ask if they want it) Sorry the [1] and [2] is the wrong way around here, but it is the right link (i.e. the link marked as [1] is actually [2]) Ross
Re: [Vision] Knowing When We are Done
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. As a first vision, I would like to see cocoon accessible to less technical people. This could be done with elegant simplicity and a graphical interface. Here is a good web 2.0 example http://www.activegrid.com/what/applicationbuilder.php. As a second vision, artifacts created by the graphical interface along with any written code could become the model from which alternative implementation systems might be generated. For example, a model POJO could be implementationally persisted in various ways. dave-
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: [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
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
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
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
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: [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
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
[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: [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)
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: [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)
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)
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)
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: [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: 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: [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)
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: 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! snip/ 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: [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: [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: [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: [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: [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: [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: [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
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: [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
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)
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: [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)
[Vision] Knowing When We are Done
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.
Re: [Vision] Knowing When We are Done
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. Sylvain -- Sylvain WallezAnyware Technologies http://bluxte.net http://www.anyware-tech.com Apache Software Foundation Member Research Technology Director
