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: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
