cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Torsten Curdt <tcu...@apache.org>
Subject Re: [Vision] Knowing When We are Done
Date Wed, 07 Dec 2005 08:40:31 GMT
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

Mime
View raw message