cocoon usability

[Stefano Mazzocchi <st...@apache.org>]

Christopher Oliver wrote:
> Just wondering, why isn't the "average cocoon user" reluctant to write 
> complex xpath or xslt code as well as Java?

This is a damn good question.

I think Cocoon is starting to suffer from 'over-RAD-ness', meaning that 
people love the fact that they can have something to show their bosses 
real quick (RAD stands for Rapid Application Development, if you don't 
know the acronim), then they continue to work on those hacky-shaped RAD 
mock-ups and create the whole web application from them.

Cocoon users tend to think lego-ish so much that they'd rather spend 
time finding strange and creative ways of mixing the current existing 
components gluing the pieces with hard-core XSLT, rather then spending a 
few lines of code to write their own.

The reason, IMO, is the fast try/fail cycle of sitemap+XSLT compared to 
custom java code.

XSP improves the speed of the try/fail cycle, but since some major 
cocoon developers/evangelists dislike XSPs, users get the same 
impression and run away from them and jump into those pre-build 
half-baked components we ship.

I expect flowscript to bring some balance back on this.

Also, one of the compliments I receive from cocoon users is that cocoon 
forces you to think at what you're doing.

Unfortunately, this thinking stops at how to compose the existing 
components, rather than thinking at how to componentize your web 
application and *then* look for prebuilt components that do what you need.

I expect blocks to build some balance back on this.

There is a lot of work to do and I'm not happy about the overall 
usability of what we have right now.

But I think that better build system + flow + block + refactored 
documentation will do it.

Let's get back working.

-- 
Stefano Mazzocchi                               <st...@apache.org>
    Pluralitas non est ponenda sine necessitate [William of Ockham]
--------------------------------------------------------------------



---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org

Re: cocoon usability

[Sylvain Wallez <sy...@anyware-tech.com>]

Stefano Mazzocchi wrote:

> Christopher Oliver wrote:
>
>> Just wondering, why isn't the "average cocoon user" reluctant to 
>> write complex xpath or xslt code as well as Java?
>
>
> This is a damn good question.
>
> I think Cocoon is starting to suffer from 'over-RAD-ness', meaning 
> that people love the fact that they can have something to show their 
> bosses real quick (RAD stands for Rapid Application Development, if 
> you don't know the acronim), then they continue to work on those 
> hacky-shaped RAD mock-ups and create the whole web application from them. 


Showing to the boss is not the main point, because the boss knows it can 
take time to build an application correctly. The main point is when 
Cocoon allows you to show to a potential customer _something working_ 
when competitors show only paper.

I know you love (as I do) clean architectures and clean separation of 
concerns, but there are some users, that come from the scripted web 
world (php, asp, etc.) that have very, very bad engineering habits. I've 
met such people not later than this week, and conviced them to use 
Cocoon by showing its abilities to cleanly separate content, 
presentation et al. They were astounded by the power of the sitemap and 
Cocoon's builtin components. But these people don't know well Java, to 
say the least ("I know C++, so I can write some Java").

Now there was a question : "I use xxx (don't remember the name) in PHP 
to populate my database. I just give it my database URL and it produces 
some web pages to edit its content. How can I do that with Cocoon ?"

Errm, you have to write forms, validation rules, store a JavaBean in SQL 
using an O/R tool, or use ESQL in XSP... Well, not that easy !

Cocoon has the power to be an efficient RAD tool while enforcing good 
structuration of the application. I'd like it to provide the few missing 
pieces that will allow it to attract those very numerous people that 
assemble applications like Lego blocks. If we don't provide the good 
blocks, they will continue with Megablocks (a bad Lego clone, FYI). If 
we provide them, they will stay here and will slowly discover what 
Cocoon provides to write well-structured large applications.

> Cocoon users tend to think lego-ish so much that they'd rather spend 
> time finding strange and creative ways of mixing the current existing 
> components gluing the pieces with hard-core XSLT, rather then spending 
> a few lines of code to write their own.


Lego is the current trend of software engineering, as it has been for 
years in the electronics world : on one side there are component 
writers, and on the other side, there are components assemblers. And the 
time is not far where assemblers will no more be able to write 
components, as existing components offer so high-level abstractions and 
so much power than going back to the elementary transitor or Java class 
is very difficult and provides so low-level functionnality that people 
don't think it's worth it.

The Cocoon documentation (or lack thereof) is a good example of this 
comparison with electronics : component documentation is no more in the 
Javadoc, but in separate files that are classified by component type. 
Isn't this close to a component catalog from Texas Instruments or Intel 
? The difficulties we have to write it also show that we, component 
writers, have not yet fully understood what the expectations of 
component assemblers are.

> The reason, IMO, is the fast try/fail cycle of sitemap+XSLT compared 
> to custom java code. 


Yep. This is one of the main reasons. Having to compile and deploy a 
sitemap or an XSLT before using it would certainly have ruined Cocoon's 
abilities for success.

> XSP improves the speed of the try/fail cycle, but since some major 
> cocoon developers/evangelists dislike XSPs, users get the same 
> impression and run away from them and jump into those pre-build 
> half-baked components we ship.


Who dislikes XSP ? And why ? Transition from Cocoon 1 to Cocoon 2 has 
reduced XSP's importance both because it's now a generator (and cannot 
drive the pipeline construction) and because we have much more 
components than in C1, but it's still useful.

> I expect flowscript to bring some balance back on this.


Certainly. But we also have to link it with other Cocoon components such 
as validation engines (e.g. XMLForm) to make it more accessible.

> Also, one of the compliments I receive from cocoon users is that 
> cocoon forces you to think at what you're doing.
>
> Unfortunately, this thinking stops at how to compose the existing 
> components, rather than thinking at how to componentize your web 
> application and *then* look for prebuilt components that do what you 
> need.
>
> I expect blocks to build some balance back on this. 


Can you elaborate on this, as I don't see what blocks will change in 
this area ?

> There is a lot of work to do and I'm not happy about the overall 
> usability of what we have right now.
>
> But I think that better build system + flow + block + refactored 
> documentation will do it.
>
> Let's get back working.


And there's a lot to do !

Sylvain

-- 
Sylvain Wallez                                  Anyware Technologies
http://www.apache.org/~sylvain           http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }



---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org