cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vadim Gritsenko <va...@reverycodes.com>
Subject Re: [Vision] Knowing When We are Done
Date Wed, 07 Dec 2005 15:41:11 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.

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 :)

Mime
View raw message