Jacob, perhaps you remember, we mailed on JSF-EL...
however, some minutes ago, i mailed your mail to myfaces-develop-list. since it was deep in my incoming-mail-folder... :-) have you checked out MyFaces-CVS-Head yet? so perhaps you can do some performance-issue there too. btw. does yours support portlet? myfaces doesn't - for now - btw. since some days there is tiles-support and so on, with a special, optional TilesViewHandlerImpl.clazz see more on http://sourceforge.net/projects/myfaces regards, Matthias > -----Original Message----- > From: James Holmes [mailto:[EMAIL PROTECTED] > Sent: Wednesday, July 21, 2004 5:28 PM > To: 'Struts Developers List' > Subject: RE: JSF vs Struts > > > The MyFaces open source project is currently becoming an > official Apache project through the Apache Incubator. > MyFaces has some custom components along with its full > implementation of the JSF spec. Perhaps you could contribute > to that project?? > > -James > http://www.jamesholmes.com/JavaServerFaces/ > > -----Original Message----- > From: Hookom, Jacob [mailto:[EMAIL PROTECTED] > Sent: Wednesday, July 21, 2004 10:27 AM > To: 'Struts Developers List' > Subject: RE: JSF vs Struts > > Would there be any interest in starting an Apache JSF > implementation with a component repository for the open > source community? I have about 80% of an implementation written... > > Regards, > Jacob > > -----Original Message----- > From: Craig McClanahan [mailto:[EMAIL PROTECTED] > Sent: Monday, July 19, 2004 12:13 PM > To: Struts Users Mailing List > Subject: Re: JSF vs Struts > > On Mon, 19 Jul 2004 10:25:13 -0400, Rick Reumann > <[EMAIL PROTECTED]> > wrote: > > > > We're thinking about using Flash forms for some things. Will they > > plugin nicely to JSF? > > > > Hooking up the output side of that should be a piece of cake > ... write some components that render the necessary markup to > embed the Flash stuff in the generated page. I'm not > familiar with the input side of using Flash for this, but in > principle it should still just be a matter of having your > component (or renderer) decode() method parse the appropriate > request parameters and store the values, just as the standard > HTML components do. > > Craig > > --------------------------------------------------------------------- > 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]