You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by Edgar P Dollin <ed...@blue-moose.net> on 2004/06/23 16:24:48 UTC

RE: PATCH: html:cancel tag. Made a javascript version for submitt ing

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.
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.

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
> <gr...@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


Re: Re: PATCH: html:cancel tag. Made a javascript version for submitt ing

Posted by Marcus Breese <mb...@gmail.com>.
But what about when the V directly communicates with the C?  This all
started with the cancel tag.  It is very much a struts specific tag
that tells the controller that the action should be cancelled.  So, in
this case, the taglib is required by the controller.  Otherwise, a
different mechanism will have to be arranged to tell actions that they
should be cancelled.  (perhaps eliminating the isCancelled() all
together...)

On Thu, 24 Jun 2004 07:54:01 -0500, Vic Cekvenich
<ce...@portalvu.com> wrote:
> 
> Don Brown wrote:
> > Please, someone fork the taglibs! :)
> 
> 
> By forking taglibs to a separate jar after some release, seems like a
> win win.
> 
> Chains is the direction, that works for it becuase it tells comunity the
> focus is on C of MVC.
> 
> Taglibs you can get from display tag, struts memnu, etc.
> 
> 
> .V
> 
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
> 
>

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


Re: PATCH: html:cancel tag. Made a javascript version for submitt ing

Posted by Vic Cekvenich <ce...@portalvu.com>.
Don Brown wrote:
> Please, someone fork the taglibs! :) 


By forking taglibs to a separate jar after some release, seems like a 
win win.

Chains is the direction, that works for it becuase it tells comunity the 
focus is on C of MVC.

Taglibs you can get from display tag, struts memnu, etc.


.V


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


Re: PATCH: html:cancel tag. Made a javascript version for submitt ing

Posted by Don Brown <mr...@twdata.org>.
Please, someone fork the taglibs! :)  I don't understand with all the 
strong feelings on taglibs why someone doesn't step up and fork them.  
I'd have to ask the other struts.sf.net admins, but I'd be willing to 
bet the fork could be hosted by sourceforge at the struts.sf.net site.  
I know "fork" is usually a dirty word, but in this case, I think it 
would be a good thing :)

Don

Edgar P Dollin 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.
>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.
>
>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
>><gr...@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
>
>  
>


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


RE: PATCH: html:cancel tag. Made a javascript version for submitt ing

Posted by David Graham <gr...@yahoo.com>.
--- Edgar P Dollin <ed...@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
> > <gr...@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