struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Graham <grahamdavid1...@yahoo.com>
Subject RE: PATCH: html:cancel tag. Made a javascript version for submitt ing
Date Wed, 23 Jun 2004 15:53:15 GMT
--- Edgar P Dollin <edgar@blue-moose.net> wrote:
> I know I will get ignored or flamed on this, but here I go.  My
> apologies in
> advance if I offend anyone.
> 
> Before I start, I have made more than a couple of attempts at
> contributing
> code, all of which have been ignored or pushed off to irrelevant
> projects.
> 
> I do wish this philosophy would get rethought.  I do agree we don't need
> more code than necessary, however.
> 
> 1) Tag libs are equal in importance to the controller.  Clean tag libs
> give
> clean an maintainable view code and limit view re-factoring. 
> 2) JSTL is a waste of time.  The reason I say this, not counting the
> non-java people, is if you can write x number of lines of useful code
> per
> hour, with jstl that is reduced by a factor greater than 1 due to type
> checking, refactoring support, testing difficulties, etc.

This contradicts point 1.  If using JSTL tags is a waste of time, so is
using Struts tags.

> 3) While javascript may be inconsistent between browsers, it is
> certainly
> possible to write cross browser javascript w/o a huge amount of effort. 
> I
> understand that in the original ideas of struts, javascript was
> 'optional',
> in real web sites that is just not the case.  Try turning off javascript
> and
> ordering on-line, it will be the rare site which functions cleanly with
> many
> MAJOR sites becoming non-functional.
> 4) I am still wondering why struts became the standardized html nazis. 
> This
> makes absolutely NO sense.

If you want your site to only work in IE, that's fine with me.  Expecting
a widely used library like Struts to support that behavior is rediculous. 
I have absolutely no interest in writing/maintaining code that only
supports one OS and browser.

David

> 
> A replacement philosophy for the tags might be:
> 
> Any tag that has a clean interaction with a struts object or bean should
> be
> considered for tag libs assuming either very general usage or real
> benefit
> in specialized situations.
> 
> Edgar
> 
> 
> > -----Original Message-----
> > From: Marcus Breese [mailto:mbreese@gmail.com]
> > Sent: Wednesday, June 23, 2004 9:24 AM
> > To: Struts Developers List
> > Subject: Re: PATCH: html:cancel tag. Made a javascript version for
> > submitting
> > 
> > 
> > I actually agree with everything that you've said.  I just have one
> > issue.  The struts tag libs are still heavily used, and haven't been
> > deprecated.  If they aren't part of the core struts package, then they
> > should be deprecated and moved to a different project.
> > 
> > On Tue, 22 Jun 2004 15:21:25 -0700 (PDT), David Graham
> > <grahamdavid1980@yahoo.com> wrote:
> > > 
> > > Well said Niall.  IMO, tags with any of the following 
> > properties don't
> > > belong in Struts:
> > > 1.  They don't interact with core Struts resources/framework.
> > > 2.  They use javascript that may not work in all browsers.
> > > 3.  They generate non-standard HTML.
> > > 4.  They duplicate functionality already available in the JSTL.
> > > 
> > > Many times Jakarta Taglibs is a more suitable home for these tags.
> > > 
> > > David
> > > 
> 
> ---
> Outgoing mail is certified Virus Free.
> Checked by AVG anti-virus system (http://www.grisoft.com).
> Version: 6.0.707 / Virus Database: 463 - Release Date: 6/15/2004
>  
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
> 
> 



		
__________________________________
Do you Yahoo!?
Yahoo! Mail Address AutoComplete - You start. We finish.
http://promotions.yahoo.com/new_mail 

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


Mime
View raw message