+1 :-) i don't like filters and don't like depending on the class-path ordering
Scott O'Bryan schrieb: > 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 > port well over to Portal's. Both Tobago and Trinidad have come up with > 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. > > 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 >>>>>>>> >>>>>>>> >>>>>>>> >> >> > >
