On Tue, Dec 22, 2009 at 10:49 PM, Scott O'Bryan <sobr...@apache.org> wrote:
> If Blake is right and the property only exists in impl, I'm not sure why it
> would have to be deprecated even as nobody should be using it.. ;) EL
> allows us to be a bit sloppy, unfortunately, but it has long been the
> paradigm that stuff in the impl is use-at-your-own-risk.
>
> +1 to Blake and Andrew's suggestion if it's doable.
+1
>
> Mamallan Uthaman wrote:
>>
>> Hi Blake,
>>
>> Yes, this API should be eventually removed. I am thinking as a first step
>> to deprecate and rename it. After implementing @import on platform basis, we
>> can remove this API. Please share your thoughts?
>>
>> Thanks
>> Mamallan
>>
>>
>> Blake Sullivan wrote:
>>>
>>> Mamallan,
>>>
>>> Related to what Andrew is saying, I think that the real issue is that
>>> this is the wrong api. Agents don't have skins--skins are specialized for
>>> agents. It seems that there were two issues that lead to the addition of
>>> this api:
>>> 1) The desire to specialize the skin based on the platform
>>> 2) You didn't want to lump all of the skins into a single css file
>>>
>>> Of these, the first was critical, the second a cleanliness issue.
>>> Include support would fix the first of these, while extending the @agent
>>> selection syntax to support per-platform selection would solve the more
>>> critical problem.
>>>
>>> In addition, my understanding is that this api was only added to the
>>> RequestContextImpl, rather than the RequestContext itself and so is only
>>> accidentally available to page authors through EL.
>>>
>>> -- Blake Sullivan
>>>
>>> On Dec 22, 2009, at 11:07 AM, Mamallan Uthaman wrote:
>>>
>>>> Hi Andrew,
>>>>
>>>> Thanks for your suggestion. Yes, we may not need this API if we could
>>>> implement @import in the skin parser. For the time being, I am planning to
>>>> rename this API.
>>>>
>>>> Thanks
>>>> Mamallan
>>>>
>>>> Andrew Robinson wrote:
>>>>>
>>>>> Would this be needed if we could just implement an @import in the skin
>>>>> parser?
>>>>>
>>>>> Then you could have something like this:
>>>>> @agent ie {
>>>>> �...@import url("ie.skin.css");
>>>>> }
>>>>>
>>>>> Now we could have CSS for each browser as desired, including mobile
>>>>> browsers. It would be more flexible this way than changing the API
>>>>> IMO.
>>>>>
>>>>> -Andrew
>>>>>
>>>>> On Sun, Dec 20, 2009 at 11:25 PM, Mamallan Uthaman
>>>>> <mamallan.utha...@oracle.com> wrote:
>>>>>
>>>>>> Hi all,
>>>>>>
>>>>>> I need your valuable suggestions in renaming the following Trinidad
>>>>>> API that
>>>>>> is used only in mobile development.
>>>>>>
>>>>>> API Name:
>>>>>> skinFamilyType. It can be accessed using EL #
>>>>>> {requestContext.agent.skinFamilyType}
>>>>>>
>>>>>> What is skinFamilyType API?
>>>>>> CSS-support of mobile browsers varies drastically as most of the
>>>>>> mobile-browsers don’t strictly follow W3C standards. After analyzing
>>>>>> various
>>>>>> mobile-browsers, we have categorized mobile-browsers based on their
>>>>>> CSS-support and exposed the category thru this API. Example, this API
>>>>>> returns 'nokiawebkit' for NokiaS60 and 'iPhonewebkit' for iPhone.
>>>>>>
>>>>>> Why Renaming?
>>>>>> This API doesn't return any skin-family; it simply returns the
>>>>>> category to
>>>>>> which a mobile-browser belongs based on the mobile-browser's
>>>>>> CSS-support. So
>>>>>> the new name should reflect what it returns.
>>>>>>
>>>>>> Alternate Name:
>>>>>> styleCategory
>>>>>>
>>>>>> Typical Usage:
>>>>>> As CSS-support of mobile browsers varies drastically, developers
>>>>>> usually
>>>>>> create their own skinning with different versions of style-classes
>>>>>> based on
>>>>>> a mobile-browser's CSS-support. To handle all mobile-browsers in a
>>>>>> single
>>>>>> CSS-file, developers have to include lots of style-classes and
>>>>>> tweaking such
>>>>>> as @agent/@platform rules. The resulting CSS-file will be very huge,
>>>>>> and it
>>>>>> is not manageable. So developers prefer to maintain separate CSS files
>>>>>> based
>>>>>> on mobile-browsers’ CSS-support. By creating different skin-families
>>>>>> with
>>>>>> names same as values returned by this API, developers can easily
>>>>>> switch to a
>>>>>> CSS file based on a requesting mobile-browser's CSS-support.
>>>>>> To illustrate with an example:
>>>>>>
>>>>>> trinidad-config.xml contains #{requestContext.agent.skinFamilyType}
>>>>>> (Remember, skinFamilyType returns 'nokiawebkit' for NokiaS60 and
>>>>>> 'iPhonewebkit' for iPhone)
>>>>>>
>>>>>> trinidad-skin.xml contains
>>>>>> <skin>
>>>>>> <id>iPhonewebkit</id>
>>>>>> <family>iPhonewebkit</family>
>>>>>>
>>>>>> <render-kit-id>org.apache.myfaces.trinidad.desktop</render-kit-id>
>>>>>> <style-sheet-name>styles/iPhone.css</style-sheet-name>
>>>>>> <! -- iPhone.css is a CSS file created by a developer to handle
>>>>>> iPhone -->
>>>>>> </skin>
>>>>>> <skin>
>>>>>> <id>nokiawebkit</id>
>>>>>> <family>nokiawebkit</family>
>>>>>>
>>>>>> <render-kit-id>org.apache.myfaces.trinidad.desktop</render-kit-id>
>>>>>> <style-sheet-name>styles/symbian.css</style-sheet-name>
>>>>>> <! -- symbian.css is a CSS file created by a developer to handle
>>>>>> NokiaS60-->
>>>>>> </skin>
>>>>>>
>>>>>> Thanks
>>>>>> Mamallan
>>>>>>
>>>
>
>
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
