The thread on this topic refers (http://marc.theaimsgroup.com/?t=108315683000003&r=1&w=2), where I highlighted some concerns about understanding the supposed "best path" for developing complex, interactive (2-way) database applications, using some of the newer Cocoon technologies PLUS various add-ons, such as Hibernate.
Comments/suggestions were as follows (with some 'direct quotes'): * 'Maybe Cocoon is just perfect for [a "real" web application]. I would like to think so, but I certainly haven't seen examples, and the existing documentation feels pretty thin..new components with little documentation take a while to get going. And without good documentation, it's hard for most potential users to determine a tool's viability. It might be that everything I need is out there, but it all feels scattered.' * It was suggested that an "out-of-the-box Hibernate/CForms binding" (or some other O/R framework) should be a requirement. The response was that an intermediate collection should be created, so that *additional* logic, like extra validations, could be done before passing the data back to the persistence layer. * Other comments were made to the effect that tools such flowscript are 'revolutionary but too complex and too young'; CForms 'are too complex and not Production-Ready' and that complex apps are hard to debug because of verbose logging and lack of an IDE. I get the sense that Cocoon is poised on the edge of big "paradigm shift", perhaps similar to that in the jump from 1.x to 2.x (the thread on JXT vs XSP also bears this out). Could it be that we are "almost there" and that is why there is a sense of frustration in knowing that things could/should be possible but without the crucial "missing pieces". The perception of complexity is, of course, related to the degree to which these things can be understood, which in turn relates to how well concepts/application are communicated... * Ugo jokes that he will write a book on "Developing Web Applications with Apache Cocoon and Hibernate". Of course, very few of us have time to write a whole book - but even a short chapter/outline of approach/recipe will be of huge help to those who are starting from scratch! It was commented that 'A better repository of user-oriented tutorials would be wonderful... [to] pull together several concepts, highlight new features, and spark new ideas.' In general, I think that the comment : 'Cocoon has a really good, quirky, "think different" attitude that other frameworks like struts or turbine lack. But very little of the documentation reflects this attitude. The official cocoon site doesn't reflect this feeling either. The attention of the Cocoon user community is decentralized, spread among the official site, the Wiki, and the user list. So the documentation feels spread apart too, and there is a lot of emphasis on nuts and bolts, but not so many "bigger picture" tutorials that teach and encourage Cocoon design methodology.' is very true. For me, moving Cocoon up to centre stage will require that those already in the know (such as Ugo?) reach down to help up those wanting to do bigger and better things. The more Cocoon can be seen to do (not just have a *potential* to do), the more it will draw the attenntion of the OS community; this will be a self-reinforcing process as more people will then be available to develop better apps and share their ideas etc. Otherwise, we are at the risk of having a brimful cup of strong tools and very few who understand how to use that power correctly. And that would be very sad. Derek -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. MailScanner thanks transtec Computers for their support. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
