Why API? [was Re: Bernd Bohmann's 1.1 concerns with Commons [was: [VOTE] Commons API JSF 1.2 only]]

[Scott O'Bryan <da...@gmail.com>]

Forking this part of the discussion.

:)  I will say that the Configurator's aren't completely isolated from 
the classpath ordering issue.  But I'm hoping that the combination of 
universal processing for common tasks (like multi-part form handling) 
and the ordering system allowed by the service's framework I wrote, 
might help mitigate some of the issues.

One thing I didn't add, that I could later, is the ability to have true 
service "dependencies", but for now the ordinal-based ordering should 
help tremendously...

Scott

Bernd Bohmann wrote:
> +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 <be...@atanion.com> 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 <be...@atanion.com>
>>>>> 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
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>               
>>>>>>>>>                   
>>>   
>>>       
>>     
>
>