Mark, As Glenn pointed out that there are different scales of applications, just like PHP hacking might be more suited, JSTL might be more suited. With some custom persistence tags to handle your business logic, you could easily write a whole application with JSTL. Though, I wouldn't recommend it in most cases.
I could also point out that putting ANY business logic in a PageController (like struts) is stupid. Jacob Hookom Senior Analyst/Programmer McKesson Medical-Surgical Golden Valley, Minnesota http://www.mckesson.com -----Original Message----- From: Mark Lowe [mailto:[EMAIL PROTECTED] Sent: Friday, July 11, 2003 2:40 PM To: Struts Users Mailing List Subject: Re: Using JSTL tags instead of Struts tags Couldn't agree with you more... an' sorry for the snide line, i think i've got a little irritated over yesterdays efforts on this thread.. I just cant see why the JSTL standard seems to be a product of pandering to PHP hackers (There are some nicely written PHP apps).. Worse still folks who are publishing books on the subject are encouraging this sort of thing.. I think that rancid festering camel's jism would perhaps be a more fitting term than dog-food, for the sort of thing you were describing :o) On Friday, July 11, 2003, at 08:11 PM, Davidson, Glenn wrote: > I recently saw the term "Dog Food" and found it amusing. I might not be > using it correctly in this context ( I just might be eating some dog > food > with my prior email :-) ) . What I was trying to get across is that > just > because there are other languages/technologies that allow programmers > to > build applications in a poor manner, that in itself should not be used > to > justify the addition of features that would allow Struts based > applications > to be built in the same manner. I chose struts as the framework for > our web > development specifically because it didn't allow the type of mixing of > logic > and presentation that was mentioned earlier in this thread. If I > wanted to > mix logic and presentation I would use PHP, it makes it very easy to do > that. If struts is going to be MVC, then let's keep it MVC. > > > > -----Original Message----- > From: Mark Lowe [mailto:[EMAIL PROTECTED] > Sent: Friday, July 11, 2003 11:30 AM > To: Struts Users Mailing List > Subject: Re: Using JSTL tags instead of Struts tags > > > I'm familiar with the tech idiom "dog-food" .. but I have no idea what > it is you're talking about please can you explain what you understand > by dog-food coding? > > If your saying what I think you are are you sure you're not choking on > some? > > > On Friday, July 11, 2003, at 02:36 PM, Davidson, Glenn wrote: > >> Please tell me that this is the start of a new urban legend and a >> joke. >> There are people who like "Dog food" coding (see PHP, Perl) but this >> should >> not be used as an excuse to pollute what Struts stands for. I >> understand >> that you want to increase the acceptance of Struts but history has >> shown >> that as soon as you start down the slippery slope of including "Dog >> Food" >> features you become the technology providers that you currently make >> fun of. >> I humbly request that you reconsider SQL tags and other "Dog Food" >> features. >> Struts has made a great start and up till now the direction has been >> solid. >> No "Dog Food" please! >> >> Glenn >> >> -----Original Message----- >> From: Mark Galbreath [mailto:[EMAIL PROTECTED] >> Sent: Thursday, July 10, 2003 7:20 PM >> To: 'Struts Users Mailing List' >> Subject: RE: Using JSTL tags instead of Struts tags >> >> >> I think this approach is bullshit. Why would you develop "SQL" tags >> to get >> access to the db from the view? You are contradicting yourself...this >> is >> exactly what PERL and PHP do. This is not good programming practice! >> >> Mark >> >> -----Original Message----- >> From: Craig R. McClanahan [mailto:[EMAIL PROTECTED] >> Sent: Thursday, July 10, 2003 6:38 PM >> >> On Thu, 10 Jul 2003, David Geary wrote: >> >>> Date: Thu, 10 Jul 2003 15:22:17 -0600 >>> From: David Geary <[EMAIL PROTECTED]> >>> Reply-To: Struts Users Mailing List <[EMAIL PROTECTED]> >>> To: Struts Users Mailing List <[EMAIL PROTECTED]> >>> Subject: Re: Using JSTL tags instead of Struts tags >>> >>> On Thursday, Jul 10, 2003, at 15:18 America/Denver, Mark Galbreath >>> wrote: >>> >>>> Is this the same David Geary that wrote, among others, "Advanced >>>> JavaServer Pages?" >>> >>> Yes. >> >> David was also a member of the JSR-52 expert group (JSTL), and he's on >> the >> JSR-127 expert group (JavaServer Faces) as well. >> >> I've never been a fan of having SQL tags (especially the updating >> ones) in >> JSTL, for all the obvious reasons. However, there are a whole bunch >> of >> developers in the world who are used to model 1 style development (VB, >> PHP, >> PERL, Cold Fusion, ...), and it would not be fair for expert groups to >> ignore the needs of those developers, simply because we might not like >> what >> people will do with the result. This was a case where the group >> creating >> the standard was actually listening to what users wanted. >> >> Beyond that, it *is* feasible to separate business logic and >> presentation >> logic into separate JSP pages, and enjoy the fact that the page is >> automatically recompiled without needing the app to be restarted. >> Couple >> that with the fact that Struts lets you say that a particular <action> >> really does a RequestDispatcher.include(), and you've suddenly got the >> ability to program Actions as JSP pages ... sort of a mind twisting >> approach, but it seems like it would be feasible in scenarios where >> the >> business logic is simple enough to be scripted in JSP tags that are >> only >> used for their side effects, not for their output (which would get >> thrown >> away anyway when Struts ultimately forwards to the presentation JSP). >> In >> such a scenario, having SQL access tags would make a lot of sense. >> >>> >>> >>> david >> >> Craig >> >> --------------------------------------------------------------------- >> 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] > > > --------------------------------------------------------------------- > 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
