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" <[EMAIL PROTECTED]> >Reply-To: "Struts Developers List" <[EMAIL PROTECTED]> >To: "'Struts Developers List'" <[EMAIL PROTECTED]> >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:[EMAIL PROTECTED]] >Sent: Friday, October 11, 2002 8:38 AM >To: [EMAIL PROTECTED] >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" <[EMAIL PROTECTED]> > >Reply-To: "Struts Developers List" <[EMAIL PROTECTED]> > >To: "'Struts Developers List'" <[EMAIL PROTECTED]> > >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:[EMAIL PROTECTED]] > >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:[EMAIL PROTECTED]> > > > For additional commands, e-mail: > ><mailto:[EMAIL PROTECTED]> > > > > > > > > > > > >-- > >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:[EMAIL PROTECTED]> > >For additional commands, e-mail: > ><mailto:[EMAIL PROTECTED]> > > > > >_________________________________________________________________ >Chat with friends online, try MSN Messenger: http://messenger.msn.com > > >-- >To unsubscribe, e-mail: ><mailto:[EMAIL PROTECTED]> >For additional commands, e-mail: ><mailto:[EMAIL PROTECTED]> _________________________________________________________________ Join the world’s largest e-mail service with MSN Hotmail. http://www.hotmail.com -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
