struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Graham" <dgraham1...@hotmail.com>
Subject RE: Basic Issues
Date Fri, 11 Oct 2002 16:23:15 GMT
I was serious about turning off JS.  Many people do this to avoid the popup 
adds.  JS validation should be viewed as an extra feature, not a required 
one.  Of course, if your site is highly specialized with dhtml you would js 
required but most apps don't fit this description.

Dave


>From: "Taylor, Jason" <jtaylor@cobaltgroup.com>
>Reply-To: "Struts Developers List" <struts-dev@jakarta.apache.org>
>To: "'Struts Developers List'" <struts-dev@jakarta.apache.org>
>Subject: RE: Basic Issues
>Date: Fri, 11 Oct 2002 09:05:24 -0700
>
>Thanks for pointing out that the JSTL has a similar feature-- I've been
>trying to get the front-end guys around here interested in JSTL, maybe this
>will help.  Turn off JS?  LOL ;)
>
>My point was that the back-end developer should be in the business of
>providing a stable framework of data that the front-end developer can
>utilize in his scripting language when he can't find what he needs in the
>taglibs (which will happen sometime, no matter how good the JSTL is).
>Keeping apprised of the tools available in the taglibs is the front-end
>developer's job-- I just make sure he's got all the data he needs.
>
>It's worked out well for me and the front-end guys I work with, and what I
>know sometimes doesn't work well is the strategy of classifying just about
>everything as "business logic" which must be provided by the back-end
>developer.  That's all...
>
>-JT
>
>-----Original Message-----
>From: David Graham [mailto:dgraham1980@hotmail.com]
>Sent: Friday, October 11, 2002 8:38 AM
>To: struts-dev@jakarta.apache.org
>Subject: RE: Basic Issues
>
>
>Struts does not need a date formatting tag because the JSTL already has 
>one.
>
>   It's called (surprise) formatDate.
>
>What happens to your js date formatting when I turn off javascript?
>
>Dave
>
>
> >From: "Taylor, Jason" <jtaylor@cobaltgroup.com>
> >Reply-To: "Struts Developers List" <struts-dev@jakarta.apache.org>
> >To: "'Struts Developers List'" <struts-dev@jakarta.apache.org>
> >Subject: RE: Basic Issues
> >Date: Fri, 11 Oct 2002 08:32:27 -0700
> >
> >I disagree with the idea that JavaBeans should handle date formats, and I
> >think it is a good example of mixing view and model components-- of
> >confusing the roles of front- and back-end developers.
> >
> >Date formats and the like are better left to the front-end developer 
>since
> >they are UI elements and are subject to change anytime the UI changes.  
>The
> >back-end developer should supply all the data required to manipulate the
> >format in a convenient and comprehensive way, but the actual format is a
> >stylistic setting that should be controlled by the front-end developer.
> >
> >If you don't believe me, think of what happens every day: a client looks 
>at
> >a table of data, says "hey we need to know (or don't need to know) what
> >time
> >the thing happened", and that along with a list of other nits goes back 
>to
> >the back-end developer who complains that they should've gotten "solid
> >requirements" before starting the project and then makes a code change to
> >add "HH:MI pm" with the leading zero removed before 10:00 because it 
>"looks
> >funny".  Maybe others like coding ad hoc date routines, but in that
> >situation I tell my front-end guys to pick up a JS book and figure out 
>what
> >to do with the date beans I pass them.
> >
> >The whole idea of Struts is to create logical separations between the 
>front
> >end, which is UI-centric, and the back end, which is data-centric.  The
> >role
> >of the back-end developer is to insulate the front-end developer from the
> >complexities of managing data, and the front-end developer insulates the
> >back-end developer from the complexities of managing the UI.  Just as a
> >front-end developer shouldn't have to worry about miscellaneous changes 
>the
> >DB admin/architect makes, the back-end developer shouldn't be pulled in
> >every time the UI changes, or every time the same application is 
>reskinned.
> >
> >Date formatting should *definitely* be handled in a front-end script or
> >transformation, unless there is some solid requirement (like legal 
>syntax)
> >that it *always* has to be the same-- in which case it's not really a 
>date,
> >but more like a code.  The Javascript Date object is pretty robust I 
>hear,
> >and there are people out there who are JS artists that can help you if
> >you're having trouble.  Struts tags have some deficiencies that it would 
>be
> >good for front-end developers to identify, but by and large there are 
>lots
> >of times where you need to have a front-end scripting language handle
> >things.  JavaBeans can't do everything, neither can taglibs, nor
> >Javascript-- just use the right tool for the right job.
> >
> >-JT
> >
> >-----Original Message-----
> >From: Ted Husted [mailto:husted@apache.org]
> >Sent: Friday, October 11, 2002 6:30 AM
> >To: Struts Developers List
> >Subject: Re: Basic Issues
> >
> >
> >I would suggest that this type of functionality be placed in a JavaBean
> >rather than a tag.
> >
> >I idea is that it is really not up to the page to decide in what format
> >a date is displayed. That's really a business requirement that you would
> >want to enforce on the Web presentation tier, or a PDF presentation
> >tier, or in some type of Word Processing report.
> >
> >The page needs to decide whether the date property is displayed between
> ><TD> elements or <LI> elements, and so forth. But there's no reason for
> >the page to worry about formatting the date. Only how to markup the date
> >property for a HTML page.
> >
> >The tags provide the basic funcationality you need to expose JavaBean
> >properties to the page but are not intended to be used as part of a
> >Model 1 design where business logic and presentation markup are handled
> >as a single task.
> >
> >So, I would take whatever code you might otherwise put in Javascript or
> >a custom tag and make it part of the getDate() (or getDateDisplay())
> >method on the JavaBean. Ideally, all the actual formatting should take
> >place in a business tier bean, and then the formatted string passed to
> >the ActionForm, ready to go.
> >
> >-T.
> >
> >edgar wrote:
> >
> > > I have found that the basic functionality of the tag library classes 
>to
> > > be limited (I assume by design) , and I have found myself writing
> > > replacement tags for quite a number of things.  I.E. In order to have 
>a
> > > relatively simple date interface (avoid very complex javascript in 
>every
> > > jsp) the logical place to put such code is in the tag libraries.
> > >
> > > Question 1: Am I missing something and is this code is actually being
> > > produced somewhere else?
> > >
> > > Question 2: Is there a desire for such code to be included in Struts 
>or
> > > does this bring the user interface too much into the picture?
> > >
> > > Question 3: How complex will life be when moving from version to 
>version
> > > of Struts if I continue to 'roll my own'?
> > >
> > > Thanks
> > >
> > > Edgar Dollin
> > >
> > >
> > > --
> > > To unsubscribe, e-mail:
> ><mailto:struts-dev-unsubscribe@jakarta.apache.org>
> > > For additional commands, e-mail:
> ><mailto:struts-dev-help@jakarta.apache.org>
> > >
> > >
> >
> >
> >--
> >Ted Husted, Husted dot Com, Fairport NY US
> >co-author, Java Web Development with Struts
> >Order it today:
> ><http://husted.com/struts/book.html>
> >
> >
> >--
> >To unsubscribe, e-mail:
> ><mailto:struts-dev-unsubscribe@jakarta.apache.org>
> >For additional commands, e-mail:
> ><mailto:struts-dev-help@jakarta.apache.org>
>
>
>
>
>_________________________________________________________________
>Chat with friends online, try MSN Messenger: http://messenger.msn.com
>
>
>--
>To unsubscribe, e-mail:   
><mailto:struts-dev-unsubscribe@jakarta.apache.org>
>For additional commands, e-mail: 
><mailto:struts-dev-help@jakarta.apache.org>




_________________________________________________________________
Join the world’s largest e-mail service with MSN Hotmail. 
http://www.hotmail.com


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


Mime
View raw message