struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Davidson, Glenn" <Glenn.David...@tiaa-cref.org>
Subject RE: Using JSTL tags instead of Struts tags
Date Fri, 11 Jul 2003 19:59:31 GMT
Thanks guys. The bottom line is that we do have the ability not to use the
features that we find objectionable. I am just surprised that the very fine
folks who conceived and built the struts framework would (appear to) favor
such features. Perhaps they could build one struts framework for people who
know what they are doing and a second framework for people who want to mix
presentation and logic. I could make an argument for separate frameworks
that would be equal to the arguments I saw for these "features". Frankly,
given the arguments I have seen to support the SQL tags it wouldn't be very
difficult. 

As an aside, "Dog Food" has a specific tech meaning? If it is not to much
trouble what exactly does it mean in "techie"

Thanks

Glenn

-----Original Message-----
From: Hookom, Jacob [mailto:Jacob.Hookom@redline.mckhboc.com]
Sent: Friday, July 11, 2003 3:39 PM
To: 'Struts Users Mailing List'
Subject: RE: Using JSTL tags instead of Struts tags


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:mark.lowe@talk21.com]
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:mark.lowe@talk21.com]
> 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:mark_galbreath@qat.com]
>> 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:craigmcc@apache.org]
>> 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 <sabreware@earthlink.net>
>>> Reply-To: Struts Users Mailing List <struts-user@jakarta.apache.org>
>>> To: Struts Users Mailing List <struts-user@jakarta.apache.org>
>>> 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: struts-user-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: struts-user-help@jakarta.apache.org
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: struts-user-help@jakarta.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: struts-user-help@jakarta.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org

---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message