On Dec 5, 2007 11:32 PM, Scott O'Bryan <[EMAIL PROTECTED]> wrote: > Mike, the reason for the API's I'm proposing is to solve a usecase we > can't currently support. Largely because of file uploads (but also some > other things as well), it is impossible for two renderkits to somtimes > even exist in the same webapplication as each other. > > For instance, let's say you use Tobago for one page and Trinidad for > another. If Tobago exists first in your classpath and Trinidad exists > second in your classpath, you will only ever be able to us the Tobago > multi-part form handling. By unifying these, it would still be up to > the renderkit to have their own file-upload component, it's just the > multi-part form handling could be done by the commons. > > Furthermore, all of the Renderkits today have a filter implementation. > Renderkits like Trinidad and Tobago are getting away from these as much > as possible. Other then being difficult to configure, Filters do not
oh boy, it's top question, every month; > port well over to Portal's. Both Tobago and Trinidad have come up with same for portlet; > their own methods for doing some of this filter logic inside of custom > FacesContextFactories, but this work is error prone, non-trivial, and is > subject to the class-path ordering issues I explained earlier. By > unifying the mechanism whereby this wrapping happens, we can concentrate > on replacing as much of this legacy "filter" functionality as possible. I think we discussed (at least in the past) a more unified version of handling the multi-part-form, w/o filters; -M > > Scott > > > Mike Kienenberger wrote: > > At least in terms of the validators/converters/etc (non-api) parts of > > commons, it is not intended that Tobago or any other project depend on > > these. These are additional components made available to the end > > users. So it's true that some small subset of Tobago users won't be > > able to use it. The same is true for Trinidad and Tomahawk users. > > > > I don't think that's reason enough to require that these projects > > support JSF 1.1. > > > > I still think the conglomeration of developer-targeted utilities/apis > > and end-user-targeted components is a mistake, and I was under the > > impression that each of these pieces was independent of each other. > > If that's the case, there's no reason why the api/utils > > developer-targeted projects can't maintain JSF 1.1 support while > > leaving the component end-user-targeted projects at JSF 1.2. > > > > On Dec 5, 2007 5:08 PM, Bernd Bohmann <[EMAIL PROTECTED]> wrote: > > > >> The tobago codebase will be 1.1 or 1.2 compatible as much as possible. > >> If commons only supports 1.2 we are not able to use it in tobago until > >> the 1.1 version is only in maintenance mode. > >> > >> I think it's ok if some parts of commons are 1.2 only. > >> I think jdk 1.4 compatibility is not a requirement.(We can provide a > >> retrotranslated version) > >> > >> As far I know some of the tobago users still using 1.1 jsf and not able > >> to switch to 1.2 until end of 2008. > >> > >> Andrew Robinson schrieb: > >> > >> > >>> As the vote states, if -1, please provide a reason why 1.1 has to be > >>> supported. An argument of why not is not enough. > >>> > >>> On Dec 5, 2007 2:14 PM, Bernd Bohmann <[EMAIL PROTECTED]> wrote: > >>> > >>>> -1 > >>>> > >>>> I don't see any reason why a commons fileupload should not support 1.1 > >>>> > >>>> Can someone define what commons API means? > >>>> > >>>> Is this just a subproject of commons like commons validator or commons > >>>> converter? > >>>> > >>>> Scott O'Bryan schrieb: > >>>> > >>>> > >>>>> +1 > >>>>> > >>>>> Mario Ivankovits wrote: > >>>>> > >>>>>> +1 > >>>>>> > >>>>>>> Lets make the myfaces commons JSF API an official vote so we can have > >>>>>>> a fixed time frame on this decision > >>>>>>> > >>>>>>> +1 [ ] -- make JSF 1.2 the minimum requirement for the new myfaces > >>>>>>> commons project > >>>>>>> +0 [ ] -- you don't mind supporting a 1.1 trunk in addition to a 1.2 > >>>>>>> trunk > >>>>>>> -1 [ ] -- you feel that 1.1 should be required and why you feel that > >>>>>>> it is needed > >>>>>>> > >>>>>>> My vote: +1 > >>>>>>> > >>>>>>> -Andrew > >>>>>>> > >>>>>>> > >>>>>>> > > > > > > -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf mail: matzew-at-apache-dot-org
