myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sochor Zdeněk <zdenek.soc...@ataco.cz>
Subject Re: [result][vote] start up the MyFaces Commons project
Date Thu, 29 Nov 2007 14:04:43 GMT
Hi,
  just my few ideas about this ;)

  What about reversing the flow by answering the 'simple question':
 
  What code is specific to render kit?
 
  By answering this question we can really begin discussion about the 
way of putting remaining classes to so called 'commons'.

  -----
  My current view of 'commons' contents:
 
  From start we should agree only that we have only 1 starting base 
dependancy - JSF API (not impl!) and even that with restriction - not 
components in .html package.
   
  As of today, almost all components from libraries by their tight 
coupling with tags are disqualified for getting into 'commons'.
  The main reason for my thinking is not using any generic means of 
manipulating arbitrary attributes.
  IMO whole path of JSF components implementation (either RI of MF) 
diverted from 1st vision of using Map of attributes (see 
_ComponentAttributesMap class) WITHOUT using getter/setter specific to 
the attribute in the component's code.
  If implementation was based solely on using Map, some components WOULD 
make it to 'commons' if:
    1. they had NO dependency on anything beside JSF API (base 
components, NOT html ones) and classes in 'commons'
    2. they declared crucial attributes from Map they work with to be 
functional (in the simpliest form)
  Not to mention that adding new attributes would be almost painless - 
just matter of adding them to tags (which would NOT be in 'commons') and 
tweaking renderrers (also NOT in 'commons').
 
  Tag related stuff should be seen as outlaws for 'commons', because 
they depend on render kits - when i hear (or read :D ) word TAG i'm 
immediatly thinking of CONCRETE language.

  Convertors and validators are quite different matter - they should get 
into 'commons' BUT if and only if they use only crucial attributes from 
components (see above) and NOT specific tag attributes from ANY language.

  Utility classes - only small potion of them are really without any 
references to render kit (either direct or indirect through components).
 
  Having convenient classes for working in either backing beans and/or 
developing new components in 'commons' would be ...convenient. :D

With regards,
  Zdenek

Matthias Wessendorf napsal(a):
>> The stuff we have (or plan to have) and we need places for are:
>>  1. "renderkit independent stuff" - converters, validators, ... (BTW,
>> are they really renderkit independent? What about client-side
>> validation?!)
>>     
>
> let me write a wiki page for that + discussion in a separate thread.
> -M
>
>   
>>  2. convenient utils, helpers and base classes for component developers
>>  3. convenient backing(!) bean utils and helpers for jsf application
>> developers (ie "users")
>>  4. some things in "myfaces-shared" that should not be there (BTW, I
>> have concrete plans on refactoring shared, but first I need a place
>> where I can move some stuff to)
>>  5. ???
>>
>> Let's try to agree on these different categories. After that we try to
>> find the proper place and name(!) for each item? Okay?
>>
>> See inline as well -->
>>
>> -- Manfred
>>
>>
>> On 11/29/07, Matthias Wessendorf <matzew@apache.org> wrote:
>>     
>>>>> Do we really want component like stuff like converters and validators
there?
>>>>> Didn't we discuss this already?
>>>>>           
>>>> Yes we had discuss this, but it seems we did not reach agreement.
>>>>
>>>> I think we need a own project for converters/validators/other stuff
>>>> for application-development
>>>> which should not include renderkid/jsf-impl dependend stuff.
>>>>         
>>> +1
>>> that was my real motivation for creating a "commons".
>>> I really don't care on a "coolBackingBean". Utils might be
>>> the better wording for that.
>>>       
>> Aren't commons modules as we know it all "utilities" in some sense?  ;-)
>>
>>
>>     
>>>> An i think this one was meant by Matthias and Bernd.
>>>>         
>>> I think so :-)
>>>
>>>       
>>>> If we need jar supporting component-developer we should stop the
>>>> repackaging of shared, create a shared.jar and add the dependency
>>>> instead to impl and tomahwak.
>>>>         
>> Yes, that's what I want to try. But "shared" is no proper name for
>> stuff that could be used by "independent" component developers. The
>> name "shared" means: this is internal code *shared* by some MyFaces
>> subprojects. Therefore we need a better place: "jsfcommons-???"
>>
>>
>>     
>>> that would easy the debugging as well.
>>>       
>> why? If you have both sources for api and impl jar in your IDE there
>> is no difference.
>>
>>
>>
>>     
>>> Perhaps we need "stricter" rules for API stability for that.
>>>
>>> One major pain was that upgrade from tom1.1.2 to 1.1.3 wasn't possible, because
>>> the whole shared messed up the migration.
>>>
>>>       
>>>> (Just my thoughts)
>>>> Regards,
>>>>     Volker
>>>>
>>>>
>>>>         
>>>>> I thought we agreed on not starting yet another jsf component lib.
>>>>> What is wrong with having convenient converters and validators in
>>>>> tomahawk? Where they are right now!
>>>>> Is it because tomahawk has some flaws and maybe have sideeffects on
>>>>> other component libs? If yes, we have to FIX tomahawk and not turn
>>>>> around and start a new (better?) project.
>>>>>
>>>>> My original idea of a jsfcommons project is/was:
>>>>>  - convenient utils, helpers and base classes for component developers
>>>>>  - convenient backing(!) bean utils and helpers for jsf application
>>>>> developers (ie "users")
>>>>>
>>>>> What jsfcommons should NOT be:
>>>>>  - a convenient haven for simple components or component like stuff,
>>>>> that is put there for "strategic" reasons
>>>>>
>>>>> A need for a "jsfcommons-faces-config.xml" is a definite sign, that we
>>>>> would start off in the wrong direction. We would start yet another jsf
>>>>> component lib. That is the main reason I warned of having a
>>>>> faces-config.xml in jsfcommons in former discussed. It was not only
>>>>> for technical reasons.
>>>>>
>>>>> --Manfred
>>>>>
>>>>>
>>>>>
>>>>> On 11/29/07, Mario Ivankovits <mario@ops.co.at> wrote:
>>>>>           
>>>>>> Hi!
>>>>>>             
>>>>>>> I don't think a separation between api and impl jars is useful.
>>>>>>>
>>>>>>>               
>>>>>> I second that. For the same reasons. It makes things unnecessary
>>>>>> complicated ....
>>>>>> To ensure api stability community review should be enough - and then
>>>>>> there is a maven plugin for that, no?
>>>>>>
>>>>>> BTW: I thought we agreed on a structure like
>>>>>> myfaces-jsfcommons-converters
>>>>>> myfaces-jsfcommons-validators
>>>>>> ...
>>>>>>
>>>>>> Also overly complex, but something I can learn to understand ....
>>>>>>
>>>>>> Lets reiterate: I prefer to start with a simple jsfcommons project
where
>>>>>> we have no faces-config.xml (at least not in a place where JSF loads
it
>>>>>> automatically).
>>>>>> Providing a jsfcommons-faces-config.xml which the user has to add
to the
>>>>>> configuration will avoid any side-effect when dropping in our jsfcommons
>>>>>> jar. It also allows to selectively active things as the users can
change
>>>>>> their own configuration as required.
>>>>>>
>>>>>> Regarding the sandbox: I'd like to suggest to use the tomahawk sandbox
>>>>>> for myfaces land at all. Lets promote the tomahawk-sandbox one level
>>>>>> higher - thats it.
>>>>>>
>>>>>> Ciao,
>>>>>> Mario
>>>>>>
>>>>>>             
>
>
>
>   

Mime
View raw message