I tried to change one piece of my functionality to struts faces. Here's my take.
My smallest complaint was that most of what's out there as far as learning JSF still talks about EA4, and JSF has had some significant changes made to it since 1.0 came out. Enough that pretty much any JSP written for EA4 won't work at all with 1.0. This is just an early adopter issue. This will fix itself. What kinda bothered me though was what what JSF does do the JSP files. When I was looking for a front end person to help me out, I didn't care that they didn't know the struts tag libs. I showed them some pages, and they saw <html:link>, <html:img>, <html:form> and they universally said, "Oh! I can do this...". They even smiled when I told them there was a commercially available Dreamweaver extension for the Struts tags. But in looking at my jsf JSP page, I didn't think that would work. To test my concern, I showed my one JSF enabled JSP page to someone of a similar background. Their reaction? "f? h? <datatable> ?". In some ways this struck me as almost worse than embedded scriptlets in JSP. The tags the HTML person *should* have understood weren't obvious to them. This won't be nearly as big of a deal I think once some good IDE tools come out for JSF, but for right now it's an issue. Basically I came away feeling that JSF is going to be fine once it gets used more, but right now the paint is still pretty wet. But in thinking about this, I came away with a few thoughts. JSF provides these rich UI widgets to do things. In some cases, as I understand it, you should use them instead of doing your own iteration on "ordinary" tags. The problem is, I don't really need rich UI widgets. I don't want a Swiss Army JackHammer. It just struck me as overkill. I just want something in Struts to deal with the things I need to do everyday when I use Struts. Yes, the JSP's are going to need to send me String data or need some UI logic tacked onto them. I accept that. I'll need Action Forms. No problem. FormDef's reason for existence is to create the forms you'll need on the fly and convert the data you'll get back into business objects when you have a correspondence between a business object and a form. This is the bread and butter of Struts actions. FormDef does an admirable job of trying to make the chore easier. In fact, it makes it easier to think of your struts app in terms of the business objects, which is what the goal should be. -Joe > -----Original Message----- > From: Takhar, Sandeep [mailto:[EMAIL PROTECTED] > Sent: Wednesday, April 14, 2004 1:41 PM > To: Struts Users Mailing List > Subject: RE: Date validator and I18N > > > Having the locale stuff is vital for some projects > (especially in canada). > > JSF is on the horizon as well, but I don't know if it impacts > formdef or not. I plan on playing with this one a bit. > > sandeep > > -----Original Message----- > From: Joe Hertz [mailto:[EMAIL PROTECTED] > Sent: Wednesday, April 14, 2004 1:14 PM > To: 'Struts Users Mailing List' > Subject: RE: Date validator and I18N > > > Sandeep, > > That's more or less what I found as well. I gave up eons > before you did though. Glad it wasn't just me. > > My "previous solution" was an utter kludge to > BeanUtils.copyProperties and copyProperty. I created > something called DateBeanUtils that had had both of these > methods, with a DateFormat parameter added to them. It's > utterly hideous but it works. > > Date->Anything first formats the Date into a String and proceeds as if > it was a String all along. > > String->Date is handled directly and the only ->Date conversion that's > handled at all, since Anything->Date gets is typically > ignored by BeanUtils. > > Like I said, hideous. > > But it's interesting you should mention FormDef, because > THAT's what I am using now, and I'm incredibly happy with it. > Nevermind I don't need to to define many of the DynaBeans I > otherwise would have, but it's current handling of Dates is > loads better than anything else for my needs (I no longer > have to deal with the date handling at all in my actions!!). > > It looks to be *almost* there for i18n (currently you can > specify date formats to use as a default, and for various > properties, but there's no way to specify a DateFormat to use > per Locale. Curiously though the infrastructure in the code > looks to be all in place to support this, so...Hubert Rabago > and I have been talking, and to make a long story short, it > looks like I'll be helping him out on this plugin. (This is > very very early in the going here) > > I've already made some changes locally that will make it more > usable for those using Hibernate and nested form beans (Me! > Me! Me!). If I have my druthers, this issue will be getting > soooo put to bed, I can tell you that. > > -Joe > > > -----Original Message----- > > From: Takhar, Sandeep [mailto:[EMAIL PROTECTED] > > Sent: Wednesday, April 14, 2004 7:39 AM > > To: Struts Users Mailing List > > Subject: RE: Date validator and I18N > > > > > > I have coded LocaleBeanUtils, but had to subclass the whole > > thing since it seems like it is a version behind. In the > > subclass I changed a couple of lines in some methods to make > > it work with some converters I created. > > > > Someone else has a solution that I haven't had time to look > > at yet: http://www.rabago.net/struts/formdef that talks about > > formatting. > > > > I had to have custom converters so the populate that struts > > uses from BeanUtils removes some formatting as well so we > > don't have to deal with this in the action. > > > > sandeep > > > > -----Original Message----- > > From: Joe Hertz [mailto:[EMAIL PROTECTED] > > Sent: Tuesday, April 13, 2004 10:51 PM > > To: 'Struts Users Mailing List' > > Subject: RE: Date validator and I18N > > > > > > Yes, you can get the dates validated this way, but isn't > > actually the tough hurdle. > > > > You've got Date objects being stored some place. > > > > You'll need them displayed as Strings in your Action Form. > > You'll need them formatted by Locale. > > > > You'll want want the Strings converted back to Dates in the > > processing Action. You'll need them parsed by Locale. > > > > Unless someone can offer a better explanation of the usage of > > LocaleBeanUtils than I can, this may prove to be quite the > > annoying little repeated task. > > > > -Joe > > > > > -----Original Message----- > > > From: Jeff Caesar [mailto:[EMAIL PROTECTED] > > > Sent: Tuesday, April 13, 2004 7:04 PM > > > To: Struts Users Mailing List > > > Subject: RE: Date validator and I18N > > > > > > > > > I haven't personally tried doing this, but according to > the doc you > > > can specify language/country/variant on the formset when defining > > > your validation so that the validator will choose the best one > > > available for the given user's locale. > > > > > > From the validator DTD: > > > <!-- > > > The "formset" element defines a set of forms for a locale. > > > Formsets for > > > specific locales can override only those fields that > > change. The > > > localization is properly scoped, so that a formset can > > > override just the > > > language, or just the country, or both. > > > --> > > > <!ELEMENT formset (constant*, form+)> > > > <!ATTLIST formset language CDATA #IMPLIED> > > > <!ATTLIST formset country CDATA #IMPLIED> > > > <!ATTLIST formset variant CDATA #IMPLIED> > > > > > > So you would want to create four different <formset> defs > (one for > > > each of your languages plus a default) for the form. > > > > > > Jeff > > > > > > -----Original Message----- > > > From: Stjepan Brbot [mailto:[EMAIL PROTECTED] > > > Sent: Tuesday, April 13, 2004 3:07 PM > > > To: [EMAIL PROTECTED] > > > Subject: Date validator and I18N > > > > > > > > > In my web application I deal with three languages > (Croatian, German > > > and English). Application does have forms allowing user > to input a > > > date value. When english locale is active user must have > the ability > > > to insert date in english date format (mm/dd/yyyy), also croatian > > > and german users must have the ability to insert dates in > their own > > > date format (dd.mm.yyyy). How to define a validation for such a > > > situation? In mask for date validation (in validation.xml) I > > > can define only one date format pattern! > > > > > > Stjepan Brbot > > > > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
