On Dec 17, 2004, at 8:34 AM, Steven Noels wrote:
As of currently, I think what worries me most is alienation of the user community. I must say I don't know many projects where the ratio of developers vs users is comparable to Cocoon's - which means (IMHO) that you almost need to be a Cocoon dev before you can actually use the product. That's asking too much patience from a user who isn't interested in framework, but wants to build business applications instead.
What do you see as a possible solution to this problem?
I think before we can even begin to solve this problem we have to understand who cocoon users currently are, what they want and wether they are really the target audience of the work being done.
Below is some personal opinion and speculation concerning Cocoon, its user community and shifting paradigms. I think a survey of actual users would be interesting and I am considering putting one together. On the other hand I think making the distinction between users and developers when it comes to putting together web applications is a little silly, since anyone who is putting together a unique business application is a developer. A user would be someone who configures an existing web application to meet their particular needs. If you read below this please realize that I have only observed this community for the past 9 months and what history I know is second hand.
In its simplest form Cocoon is indeed a server side application capable of producing simple sites where data and presentation can be completely separated. Such sites can be designed and implemented by your average webmaster. With a little bit of SQL and/or Java knowledge they can create dynamic sites. In the hands of a more advanced user, Cocoon is a framework/platform that allows a much more powerful business application to be built using a MVC pattern. The more complex your application is, the more advanced a user of the framework you must be. No doubt the webmaster who was able to cobble together his site with Cocoon a year ago using the Authentication Framework and ESQL would be hard pressed to implement it today using Java, Hibernate, CForms and Flowscript. However, nothing stops him from implementing it the exact same way today as he did a year ago. I, on the other hand, as an application designer/developer have a lot more flexibility then I had a year ago. I can achieve a true separation of concerns in a much simpler and obvious way.
Having said that, the hard part of a web facing business application is the business model and logic. Presentation has been simplified a great deal over the years. Mediating between the presentation and the model and controlling application workflow have been much more difficult then they should have been. Flow is about the simplest way I have run across to mediate between the model and the view. On the other hand I'm not real crazy about CForms (or any forms handling framework at the moment). I find it to be overly complex for my needs. If anything, I think on the whole, the advances made in cocoon have made things simpler from my perspective as a developer. So maybe I'm not a user, maybe I'm a developer who's only written sitemap components to see how its done and once in a misguided attempt to integrate a store directly into cocoon. (why did I ever try such a thing? buy me a beer. my embarrassment has a price ;-).)
There has been a small paradigm shift in the recommended way sites should be built with cocoon. The shift has come as a result of the desire to put more complex applications on our sites and to find better ways to manage that complexity. Unfortunately, complexity is hardly ever removed but is usually shifted somewhere else. The shift in Cocoon seems to have been towards the users. By that I mean that it is the users responsibility to code or program pieces of application functionality as opposed to relying on the Cocoon developer comunity. This has left some users feeling abandoned. To some extent thats true, the developers will not be spending time writing Actions, they are assuming that users will be able to achieve the same results in a much more direct manner through using flow. Unfortunately, flow requires programming, not simply making an entry in the sitemap. Imagine what a poor webmaster must do to authenticate a user using flow as opposed to the just using <map:act type="auth-login">. (this is just an example of switching from Actions to flow, I know the Action could still be used) Likewise, having to get data from the database directly using flow, rather then using ESQL and XSP requires a lot more of the user. This shift makes it much more likely that a developer will be needed to create a web app. The user community is shifting more towards the developer community. Cocoon is becoming more of a framework/platform then an application.
The mind share that needs to be gained is that of web developers, those that are building business applications. They need to view Cocoon as a viable platform that allows them to produce flexible, scalable and maintainable applications. If they are looking for a quick and dirty solution they should just use JSF with Sun Studio Creator or better yet VB.net. If you want to gain the mind share of web publishers then you will have a hard time unseating the combination of Dreamweaver and Contribute.
on a related note:
I do think that several good tutorials on putting together a business application using cocoon would go along way to alleviating some concerns. I am willing to start putting at least one substantial tutorial together, but I would like some input before I begin. To that end, I will submit another post soliciting some advice and your views on what would be most important to cover.
Glen Ezkovich HardBop Consulting glen at hard-bop.com http://www.hard-bop.com
A Proverb for Paranoids:
"If they can get you asking the wrong questions, they don't have to worry about answers."
- Thomas Pynchon Gravity's Rainbow
