Complaining about features in an open source program written by volunteers isn't really very nice, and I apologize for it. All programs have sub-optimal features, mine included, of course, and no one likes having their work sniped at by outsiders. The fundamental architecture of S2 is really sound, which allows me to use most of it in ways which suit me, even if they aren't part of the envisioned use when the app was written. This speaks well of its flexibility and modularity.
The latest thing we've done is to use JSF components for all the display pages from S2 actions, and we found that we couldn't use the JSF plugin because it was too buggy. So we just declare that the action types are "redirect", and the JSF processor seems to handle everything. I was surprised that this worked, since now there is no tie between the S2 process and the JSF process. The app has had some pure JSF pages for some time, but now to use JSF with S2 but not have to rely on the JSF plugin is really great. Probably there are JSF-things we couldn't do with this method, but the things we want it to do, it does very nicely. We have a 'builder' architecture for all the actions, which 'export' the data to the view. Of course, in a pure exporter, the exporter actually creates the view, but that would require giving up the JSP-idiom, which would be unthinkable at this juncture. Having the JSF components render the exported data items is an ideal compromise for me. We just treat the components as a super-powerful tag set. Again, I apologize for the earlier rant. - Ray Clough [EMAIL PROTECTED] > ----- Original Message ----- > From: "Ted Husted" <[EMAIL PROTECTED]> > To: "Struts Users Mailing List" <user@struts.apache.org> > Subject: Re: [s2] Is it possible to replace/supplement i18n resolution logic? > Date: Sun, 5 Aug 2007 06:32:17 -0400 > > > On 8/4/07, Ray Clough <[EMAIL PROTECTED]> wrote: > > Sorry for the rant, but I do like many of the S2 features well > > enough that I continue to use > > it > > Feel free to start a Struts 3 roadmap on the wiki that identifies some > of the "features" we might subtract, as well as those that we might > add. > > -Ted. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > - Ray Clough [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]