Leon I agree that if what works for you is OK, then you are doing fine. My concern is that there are better ways evolving and, if they are "easy and clean", I am prepared to learn them but, and this is my case in a number of threads (and you have effectively said the same thing here), if this approach is a limited to a "few in the know" and there is not sufficient info for others to "get in the know", how can we evolve as a community of developers with a *potentially* really good product?
See Point 6 of: http://www.hibernate.org/38.html Derek >>> [EMAIL PROTECTED] 2004/05/03 06:50:10 PM >>> Hi Christopher, the better combination seems to be flowscript + woody + O/R with O/R to be either Hibernate or OJB. There are some examples in the Wiki. Unfortunately, I find the combination neither very clean nor easy to learn, though experienced users vouch it is both easy and clean. I think you could look at the JXT or XSP thread, or to the flowscript thread on the devel group. There was a discussion on this subject not too long ago (http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=108236425519235&w=2) On the other hand, I fully agree with you that you do not need to change a winning team; being aware (and knowing what it does) of the winning team to be is I think sufficient. Leon Christopher Painter-Wakefield wrote: > > >FWIW, that conversation did not include everyone using Cocoon and/or >reading the list. It may be that the folks joining in the conversation >were those with similar approaches. > >My attitude is the best tool for the job is the one that meets your needs. >Since many of the tools recently mentioned were not available 1-2 years >ago, we developed a lot of our own designs to tackle the same sorts of >problems in our environment. We make heavy use of XSP, logicsheets, and >ESQL. At this point our designs are pretty mature and, of course, are a >custom fit for our needs. > >If you have established software that is working, you probably have a good >idea where the most "pain" is - where the code is difficult to modify and >extend, where you spend the most time, etc. Or you may be adding new >features with very different requirements than before. In these cases, it >is probably worth examining the new tools to see if they offer a solution >to your particular problems. Otherwise, if it ain't broke.... In our >case, I am interested in some of the tools that help with forms and form >validation, which is an area we are very weak on, so I may examine these in >the future. However, on site navigation, layouting, etc., I feel our >designs are working very well, so I probably won't look for something else. > >Here's my vote for XSP: it is general-purpose, powerful, flexible, and >extensible (with all of Java available to you). It doesn't solve a >specific problem, but it can be used to solve almost any problem. > >-Christopher > > > >|---------+----------------------------> >| | "Derek Hohls" | >| | <[EMAIL PROTECTED]| >| | a> | >| | | >| | 05/03/2004 07:28 | >| | AM | >| | Please respond to| >| | users | >| | | >|---------+----------------------------> > >--------------------------------------------------------------------------------------------------------------| > | | > | To: <[EMAIL PROTECTED]> | > | cc: | > | Subject: Better alternative to ESQL? | > >--------------------------------------------------------------------------------------------------------------| > > > > >There seems to be a very a strong "current of opinion" on the list at >present (April 2004) saying that XSP is not really a suitable component >of a "well archictectured" Cocoon application. My major use of it has >been in the development of complex database reporting systems; using >ESQL for the bulk of the work and adding in Java code to do any >necessary non-SQL calculations. > >If the use of XSP (and, therefore, I assume, ESQL) is not espoused any >longer, what is the "equivalent but better" methodology for tackling >this type of work, and where is/are the corresponding examples/docs on >the Cocoon sites? > >Thanks >Derek > >PS Yes, I have looked at XReporter... > > > > >--------------------------------------------------------------------- >To unsubscribe, e-mail: [EMAIL PROTECTED] >For additional commands, e-mail: [EMAIL PROTECTED] > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- 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]
