Phil Can I ask... from a very naive point-of-view... if you could then outline your recommendations for the overall architecture (assuming it *excludes* additional frameworks such as Hibernate and OJB)?
I was the one who raised the issue of avoiding development in Java; having said that, I am sure that there must be "DAO templates" that are readily adaptable to a "stock" situations - we're not talking highly complex application logic here; more how to handle standard ACID transactions, taking into account the normal cascading parent-child relationships one has in a typical SQL database. Essentially, all that changes from one situation to the next is the table and field names... in this case, the learning requirements for complex Java are much lower (more akin to 'logic' statements in XSP... those I was able to figure out!) and developing all the data access code in a very consistent way would have its own advantages anyway. Now - if you could show concrete examples of these types of DAOs; and how they, in turn, fit into the cforms/flow framework provided by Cocoon (to handle the front-end side and overall application flow) - then surely this would be a better overall model to follow? Conversely, without this type of "starter pack", its very likely that most of us will stick with what we know (being under pressure to develop applications by yesterday) and create those "20% solutions" that you talk about. Thanks Derek >>> [EMAIL PROTECTED] 2005/06/15 02:58:23 AM >>> Askild Aaberg Olsen wrote: > > Why is tightly coupling my data access code to Hibernate so much better > then, isn't this yet another framework (like EJBs)? > What if I don't have the need to reuse this code? > What if I'm just a newbie trying to get some data into my webapp? I should clarify that I'm not necessarily advocating Hibernate or OJB, because those two particular solutions come with baggage. What I would recommend is wrapping all of those implementation details behind DAOs. This way, you're not coupling your application logic to anything but your own DAOs. How does one does this in a reusable way while using modular database actions or the SQL transformer? The answer is that you can't. And that makes it a bad idea. > I never argued Hibernate/OJB wrong or bad practive, I just outlined an > alternative method to get a simple db-driven app up and running using a > stock Cocoon, without the need to write a single line of Java-code (not > using modular db actions, by the way...). I'm not sure what the value of this is. This approach seems like it will get you 20% of the way to something useful really quickly. phil. --------------------------------------------------------------------- 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]
