Don't be so defensive. You cant infer anything that I didn't say. I have no clue what you personally do. I merely commented on what I have seen others do in some 7 years of professional consulting.
I don't advocate BMP because it doesn't take advantage of lazy loading. Its an all or nothing approach. You either load the entire object or none of it. If this object is a purchase order then it probably isn't a big deal. If its a genetic research mouse that has over 300 properties including 90 sets, lazy loading becomes IMPERATIVE. 99% of the time I just need 4 or 5 of those attributes. Loading them all would be a waste of resources and slow things down dramatically. JDO caching paradigm is heavily based on lazy loading. --Robert ----- Original Message ----- From: "Todd Pierce" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Wednesday, February 05, 2003 2:39 AM Subject: RE: [OT] RE: cocoon & struts together > Interesting set of inferences ; P > > "Many people whip up some struts-JSP based applications, which basically > become servlets, and then pretend that the problems are solved. I could list > a thousand ways this paradigm is garbage..." - So that's what I do? > > "Struts is a horrible basis for business logic for a thousand reasons." - > Where did I say I use Struts for business logic? > "My advice to you is to use EJB and J2EE on the back end" - Right on, baby > "Cocoon on the web" - Hmm > "JDO for persistence" - BMP > > We use Struts for controlling requests, on web-tier, application layer. We > use templated JSPs for presentation, web-tier, presentation layer. You can > use Cocoon for this if you like, but I think cocoon's strength is publishing > data. > > -----Original Message----- > From: Robert Simmons [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, 5 February 2003 11:49 AM > To: [EMAIL PROTECTED] > Subject: Re: [OT] RE: cocoon & struts together > > > Struts is a horrible basis for business logic for a thousand reasons. > Business logic best lives within an enterprise container and an application > server. The basis of concurrency, fault tolerance, transaction management, > clustering and the rest of the EJB contract make it pretty psycho to NOT use > it. I would NEVER EVER do anything important in any web framework, be it > cocoon or struts. No thanks the J2EE environment is the god of business > logic > as cocoon is, IMHO, the god of web presentation. Cocoon should be a CONSUMER > of the J2EE functionality and not make any decisions whatsoever. > > Many people whip up some struts-JSP based applications, which basically > become servlets, and then pretend that the problems are solved. I could list > a thousand ways this paradigm is garbage, but I really don't have to because > other books do it quite well for me. > > My advice to you is to use EJB and J2EE on the back end, cocoon on the web > end, JDO for persistence and Swing for complex clients. > > -- Robert > > ----- Original Message ----- > From: "Todd Pierce" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Wednesday, February 05, 2003 1:36 AM > Subject: [OT] RE: cocoon & struts together > > > > Re the comment "Frameworks like struts mix functionality with > > presentation...". > > > > The presumption that functionality and presentation are mixed in Struts > > needs qualification. Struts is an application framework. It's most > valuable > > component is the application layer. The presentation layer don't have to > be > > JSP/taglib. You can serve out xml for presentation if you wish, or > (shudder) > > even Flash. > > > > Reasonable separation of functionality and presentation can be achieved > > using any framework, if you follow 2 simple rules: Rule 1 - ensure that > the > > application layer does not generate any presentation. Rule 2 - ensure that > > the presentation layer does not make any decisions. I use a tiles-based > > template system, with screens defined in an XML doc, but y'know, > what-ever. > > > > I'm not trying to sell Struts to hardened Cocoon users. I use both Cocoon > > and Struts, but not together. Cocoon for data delivery systems, because of > > its fantastic separation of content and presentation, and Struts for > > business applications simply because it's such a good application > framework. > > I don't believe either of these technologies should be considered to be a > > panacaea for the ills of the web world. > > > > -----Original Message----- > > From: Robert Simmons [mailto:[EMAIL PROTECTED]] > > Sent: Wednesday, 5 February 2003 10:43 AM > > To: [EMAIL PROTECTED] > > Subject: Re: cocoon & struts together > > > > > > Actually I'm an EJB specialist and I don't generally work on projects > > conducive to web interfaces. The complexity level of the stuff I do is too > > high. (Pharmaceutical industry and genetic research). My customers > generally > > require a higher range of functionality than a web interface can provide. > > > > That being said, I do, however, do some web work which is why I took up > the > > idea of cocoon. I use the same technique that I use for GUI programming. > > Basically a command centric architecture. I hate to say "struts is for > > amateurs" but it kind of is. It has low complexity and thus low > > functionality. It also has high cost in terms of content delivery and > > maintenance costs. I personally chose to avoid all that and let Java > objects > > do all the work and let the framework just concentrate on presentation. > > Enter > > cocoon. > > > > My programs consist of allot of specially designed generators that > generate > > pure data. Then I use XSLT to translate that into the appropriate media. I > > also use XSLT to output the forms though I am experimenting with reflexive > > techniques that I have used in GUI applications to make generation of > forms > > be based on reflexive command analysis. > > > > Frameworks like struts mix functionality with presentation, which IMHO is > a > > very bad thing. Its a high maintenance cost solution with a low > development > > cost. That is the wrong way around. To be professional you want high > > development cost and low maintenance cost. This causes your feature turn > > around, post release, to be much faster. Since you are able to react > quickly > > to the demands of your users, your company or customers win. The guy that > > slapped it together with low development costs may make some sales coming > > out > > the door, but will bleed customers as they seek more stable solutions with > > faster turn-around time for new features and fault correction. > > > > I guess that is a long way of saying, "put all your work into the back > end." > > Cocoon is perfect for this because you can develop custom generators to > > deliver data and let a web designer with a couple weeks of training worry > > about the XSLT translation. In the meantime your valuable programmer > > resources are implementing new features and stabilizing the product. > > > > Well that's my opinion on the matter. > > > > -- Robert > > > > > > ----- Original Message ----- > > From: "Antonio Gallardo" <[EMAIL PROTECTED]> > > To: <[EMAIL PROTECTED]> > > Sent: Tuesday, February 04, 2003 11:48 PM > > Subject: Re: cocoon & struts together > > > > > > > Robert Simmons dijo: > > > > I dont think that using struts would be useful within an efficient > > > > cocoon site. Cocoon takes another approach to web development that is, > > > > in my opinion, superior to the jsp/struts approach. > > > > > > Thanks for the comment. I was trying to start learning about this stuff. > > > > > > As a bean specialist (a book writer) what tools you recommend to manage > > > all the beans stuff (creation, changes, etc.) > > > > > > Thanks for the comments. > > > > > > Antonio Gallardo > > > > > > > > > > > > --------------------------------------------------------------------- > > > Please check that your question has not already been answered in the > > > FAQ before posting. <http://xml.apache.org/cocoon/faq/index.html> > > > > > > To unsubscribe, e-mail: <[EMAIL PROTECTED]> > > > For additional commands, e-mail: <[EMAIL PROTECTED]> > > > > > > > > > --------------------------------------------------------------------- > > Please check that your question has not already been answered in the > > FAQ before posting. <http://xml.apache.org/cocoon/faq/index.html> > > > > To unsubscribe, e-mail: <[EMAIL PROTECTED]> > > For additional commands, e-mail: <[EMAIL PROTECTED]> > > > > --------------------------------------------------------------------- > > Please check that your question has not already been answered in the > > FAQ before posting. <http://xml.apache.org/cocoon/faq/index.html> > > > > To unsubscribe, e-mail: <[EMAIL PROTECTED]> > > For additional commands, e-mail: <[EMAIL PROTECTED]> > > > > > --------------------------------------------------------------------- > Please check that your question has not already been answered in the > FAQ before posting. <http://xml.apache.org/cocoon/faq/index.html> > > To unsubscribe, e-mail: <[EMAIL PROTECTED]> > For additional commands, e-mail: <[EMAIL PROTECTED]> > > --------------------------------------------------------------------- > Please check that your question has not already been answered in the > FAQ before posting. <http://xml.apache.org/cocoon/faq/index.html> > > To unsubscribe, e-mail: <[EMAIL PROTECTED]> > For additional commands, e-mail: <[EMAIL PROTECTED]> > --------------------------------------------------------------------- Please check that your question has not already been answered in the FAQ before posting. <http://xml.apache.org/cocoon/faq/index.html> To unsubscribe, e-mail: <[EMAIL PROTECTED]> For additional commands, e-mail: <[EMAIL PROTECTED]>
