You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@myfaces.apache.org by Andrew Robinson <an...@gmail.com> on 2009/12/22 19:42:23 UTC

Re: [Trinidad] Renaming an API that Is Used Only in Mobile Development

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
<ma...@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

Re: [Trinidad] Renaming an API that Is Used Only in Mobile Development

Posted by Mamallan Uthaman <ma...@oracle.com>.
Thanks Blake.

Blake Sullivan wrote:
> OK, the HTML to plaint text converter added the asterixes.  This 
> should be:
>
> @agent ie and (version:6)
>
> -- Blake
>
> Blake Sullivan said the following On 12/28/2009 4:23 PM PT:
>> You're missing the "and".  The skinning.xml documentation is wrong.  
>> I'm fixing it right now at part of JIRA-1547
>>
>> @agent ie *and *(version: 6)
>>
>> -- Blake Sullivan
>>
>>
>> Mamallan Uthaman said the following On 12/28/2009 4:16 PM PT:
>>> I just checked the skinning based on an agent name and its version, 
>>> Trinidad ignores the version. Example, I created a skin-family with 
>>> the following in its CSS file.
>>>
>>> @agent ie (version: 6)
>>> {
>>>   .class5
>>>   {
>>>     color: red;
>>>     font-size: 13px;
>>>   }
>>> }
>>>
>>> @agent ie  (version: 7)
>>> {
>>>   .class6
>>>  {
>>>     color: green;
>>>     font-size: 20px;
>>>   }
>>> }
>>>
>>> The CSS file sent to the ie 6.0 browser contains both .class5 and 
>>> .class6. I tested it against the branch 1.2.12.1 and 1.2.12.2. Did I 
>>> miss anything or is it a bug?
>>>
>>> Thanks
>>> Mamallan
>>>
>>> P.S: Used a web-debugger tool called fiddler to examine the CSS file 
>>> downloaded to the browser
>>>
>>> Blake Sullivan wrote:
>>>> Mamallan Uthaman said the following On 12/28/2009 12:24 PM PT:
>>>>> Hi Jeanne,
>>>>>
>>>>> Please find my response inline.
>>>>>
>>>>> Thanks
>>>>> Mamallan
>>>>>
>>>>> Jeanne Waldman wrote:
>>>>>> Blake is working on this feature.
>>>>>>
>>>>>> Also, can you explain the kinds of things you need to skin 
>>>>>> differently for your different agents? I'm curious.
>>>>> These agent-based customizations are very much depended on 
>>>>> applications. To name a few, Blackberry browsers don't support 
>>>>> :active pseudo element unlike iPhone. So in an iPhone on clicking 
>>>>> a link, we can have a loading-image as background using 
>>>>> .Oralink:active. Also, I usually override default background color 
>>>>> of buttons in Windows Mobile.
>>>>>> Do you need to add extra @agent rules, or do you have what you need.
>>>>> No, we have added enough agents and platforms. Currently, we only 
>>>>> need the feature TRINIDAD-1547 to handle different agents based on 
>>>>> versions and @import support for better usability.
>>>> Mammallan, it's gross, but you can support multiple agents using 
>>>> the OR feature of the queries:
>>>>
>>>> @agent blackberry and (version:4.5), blackberry and (version:4.4), 
>>>> blackberry and (version:4.3), blackberry and (version:4.2), 
>>>> blackberry and (version:4.1), blackberry and (version:4.0)
>>>>
>>>> -- Blake Sullivan
>>>>
>>>>>>
>>>>>> Jeanne
>>>>>>
>>>>>> Mamallan Uthaman wrote, On 12/23/2009 9:15 PM PT:
>>>>>>> Hi Jeanne,
>>>>>>>
>>>>>>> I tried to implement a single CSS file to handle all mobile 
>>>>>>> browsers, but couldn't as @agent rule doesn't support range of 
>>>>>>> version. Example, I need to add some skinning only for 
>>>>>>> blackberry browsers of versions < 4.6. I noticed that you have 
>>>>>>> been tracking @agent  range-of -version  feature in 
>>>>>>> TRINIDAD-1547. I am looking forward to using this feature.
>>>>>>> As this feature is needed for skinning mobile-agents, we can 
>>>>>>> consider deprecating skinFamilyType API after this feature's 
>>>>>>> release.
>>>>>>>
>>>>>>> Thanks
>>>>>>> Mamallan
>>>>>>>
>>>>>>> Jeanne Waldman wrote:
>>>>>>>> If you deprecate it, you can't then rename it. You'd have to 
>>>>>>>> deprecate skinFamilyType, create a new method with a better 
>>>>>>>> name, and then deprecate that when we have @import. So we'd end 
>>>>>>>> up with two deprecated apis in the end, which is not very clean.
>>>>>>>>
>>>>>>>> I think for now you should:
>>>>>>>> 1. deprecate skinFamilyType and stop using it yourself
>>>>>>>> 2. add @agent or @platform support to handle all the agents or 
>>>>>>>> platforms you need for mobile.
>>>>>>>> 3. use one skin-family and one css file until we have @import 
>>>>>>>> support or multiple <style-sheet-name>s per skin.
>>>>>>>>
>>>>>>>> The con of having so many skin-families is that the app 
>>>>>>>> developer needs to figure out which skin-family to use for each 
>>>>>>>> agent and render-kit-id.
>>>>>>>> Another con is the app developer needs to modify all the .css 
>>>>>>>> files if he wants to make one change that affects them all, 
>>>>>>>> like color: black to color:blue. If we use one skin-family, 
>>>>>>>> then the app developer can make one change in one file that 
>>>>>>>> affects all devices if he wants.
>>>>>>>>
>>>>>>>> Jeanne
>>>>>>>>
>>>>>>>> Mamallan Uthaman wrote, On 12/22/2009 12:35 PM PT:
>>>>>>>>> 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
>>>>>>>>>>>> <ma...@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
>>>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>
>>
>>
>

Re: [Trinidad] Renaming an API that Is Used Only in Mobile Development

Posted by Blake Sullivan <bl...@oracle.com>.
OK, the HTML to plaint text converter added the asterixes.  This should be:

@agent ie and (version:6)

-- Blake

Blake Sullivan said the following On 12/28/2009 4:23 PM PT:
> You're missing the "and".  The skinning.xml documentation is wrong.  
> I'm fixing it right now at part of JIRA-1547
>
> @agent ie *and *(version: 6)
>
> -- Blake Sullivan
>
>
> Mamallan Uthaman said the following On 12/28/2009 4:16 PM PT:
>> I just checked the skinning based on an agent name and its version, 
>> Trinidad ignores the version. Example, I created a skin-family with 
>> the following in its CSS file.
>>
>> @agent ie (version: 6)
>> {
>>   .class5
>>   {
>>     color: red;
>>     font-size: 13px;
>>   }
>> }
>>
>> @agent ie  (version: 7)
>> {
>>   .class6
>>  {
>>     color: green;
>>     font-size: 20px;
>>   }
>> }
>>
>> The CSS file sent to the ie 6.0 browser contains both .class5 and 
>> .class6. I tested it against the branch 1.2.12.1 and 1.2.12.2. Did I 
>> miss anything or is it a bug?
>>
>> Thanks
>> Mamallan
>>
>> P.S: Used a web-debugger tool called fiddler to examine the CSS file 
>> downloaded to the browser
>>
>> Blake Sullivan wrote:
>>> Mamallan Uthaman said the following On 12/28/2009 12:24 PM PT:
>>>> Hi Jeanne,
>>>>
>>>> Please find my response inline.
>>>>
>>>> Thanks
>>>> Mamallan
>>>>
>>>> Jeanne Waldman wrote:
>>>>> Blake is working on this feature.
>>>>>
>>>>> Also, can you explain the kinds of things you need to skin 
>>>>> differently for your different agents? I'm curious.
>>>> These agent-based customizations are very much depended on 
>>>> applications. To name a few, Blackberry browsers don't support 
>>>> :active pseudo element unlike iPhone. So in an iPhone on clicking a 
>>>> link, we can have a loading-image as background using 
>>>> .Oralink:active. Also, I usually override default background color 
>>>> of buttons in Windows Mobile.
>>>>> Do you need to add extra @agent rules, or do you have what you need.
>>>> No, we have added enough agents and platforms. Currently, we only 
>>>> need the feature TRINIDAD-1547 to handle different agents based on 
>>>> versions and @import support for better usability.
>>> Mammallan, it's gross, but you can support multiple agents using the 
>>> OR feature of the queries:
>>>
>>> @agent blackberry and (version:4.5), blackberry and (version:4.4), 
>>> blackberry and (version:4.3), blackberry and (version:4.2), 
>>> blackberry and (version:4.1), blackberry and (version:4.0)
>>>
>>> -- Blake Sullivan
>>>
>>>>>
>>>>> Jeanne
>>>>>
>>>>> Mamallan Uthaman wrote, On 12/23/2009 9:15 PM PT:
>>>>>> Hi Jeanne,
>>>>>>
>>>>>> I tried to implement a single CSS file to handle all mobile 
>>>>>> browsers, but couldn't as @agent rule doesn't support range of 
>>>>>> version. Example, I need to add some skinning only for blackberry 
>>>>>> browsers of versions < 4.6. I noticed that you have been tracking 
>>>>>> @agent  range-of -version  feature in TRINIDAD-1547. I am looking 
>>>>>> forward to using this feature.
>>>>>> As this feature is needed for skinning mobile-agents, we can 
>>>>>> consider deprecating skinFamilyType API after this feature's 
>>>>>> release.
>>>>>>
>>>>>> Thanks
>>>>>> Mamallan
>>>>>>
>>>>>> Jeanne Waldman wrote:
>>>>>>> If you deprecate it, you can't then rename it. You'd have to 
>>>>>>> deprecate skinFamilyType, create a new method with a better 
>>>>>>> name, and then deprecate that when we have @import. So we'd end 
>>>>>>> up with two deprecated apis in the end, which is not very clean.
>>>>>>>
>>>>>>> I think for now you should:
>>>>>>> 1. deprecate skinFamilyType and stop using it yourself
>>>>>>> 2. add @agent or @platform support to handle all the agents or 
>>>>>>> platforms you need for mobile.
>>>>>>> 3. use one skin-family and one css file until we have @import 
>>>>>>> support or multiple <style-sheet-name>s per skin.
>>>>>>>
>>>>>>> The con of having so many skin-families is that the app 
>>>>>>> developer needs to figure out which skin-family to use for each 
>>>>>>> agent and render-kit-id.
>>>>>>> Another con is the app developer needs to modify all the .css 
>>>>>>> files if he wants to make one change that affects them all, like 
>>>>>>> color: black to color:blue. If we use one skin-family, then the 
>>>>>>> app developer can make one change in one file that affects all 
>>>>>>> devices if he wants.
>>>>>>>
>>>>>>> Jeanne
>>>>>>>
>>>>>>> Mamallan Uthaman wrote, On 12/22/2009 12:35 PM PT:
>>>>>>>> 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
>>>>>>>>>>> <ma...@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
>>>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>
>>>
>
>


Re: [Trinidad] Renaming an API that Is Used Only in Mobile Development

Posted by Blake Sullivan <bl...@oracle.com>.
You're missing the "and".  The skinning.xml documentation is wrong.  I'm 
fixing it right now at part of JIRA-1547

@agent ie *and *(version: 6)

-- Blake Sullivan


Mamallan Uthaman said the following On 12/28/2009 4:16 PM PT:
> I just checked the skinning based on an agent name and its version, 
> Trinidad ignores the version. Example, I created a skin-family with 
> the following in its CSS file.
>
> @agent ie (version: 6)
> {
>   .class5
>   {
>     color: red;
>     font-size: 13px;
>   }
> }
>
> @agent ie  (version: 7)
> {
>   .class6
>  {
>     color: green;
>     font-size: 20px;
>   }
> }
>
> The CSS file sent to the ie 6.0 browser contains both .class5 and 
> .class6. I tested it against the branch 1.2.12.1 and 1.2.12.2. Did I 
> miss anything or is it a bug?
>
> Thanks
> Mamallan
>
> P.S: Used a web-debugger tool called fiddler to examine the CSS file 
> downloaded to the browser
>
> Blake Sullivan wrote:
>> Mamallan Uthaman said the following On 12/28/2009 12:24 PM PT:
>>> Hi Jeanne,
>>>
>>> Please find my response inline.
>>>
>>> Thanks
>>> Mamallan
>>>
>>> Jeanne Waldman wrote:
>>>> Blake is working on this feature.
>>>>
>>>> Also, can you explain the kinds of things you need to skin 
>>>> differently for your different agents? I'm curious.
>>> These agent-based customizations are very much depended on 
>>> applications. To name a few, Blackberry browsers don't support 
>>> :active pseudo element unlike iPhone. So in an iPhone on clicking a 
>>> link, we can have a loading-image as background using 
>>> .Oralink:active. Also, I usually override default background color 
>>> of buttons in Windows Mobile.
>>>> Do you need to add extra @agent rules, or do you have what you need.
>>> No, we have added enough agents and platforms. Currently, we only 
>>> need the feature TRINIDAD-1547 to handle different agents based on 
>>> versions and @import support for better usability.
>> Mammallan, it's gross, but you can support multiple agents using the 
>> OR feature of the queries:
>>
>> @agent blackberry and (version:4.5), blackberry and (version:4.4), 
>> blackberry and (version:4.3), blackberry and (version:4.2), 
>> blackberry and (version:4.1), blackberry and (version:4.0)
>>
>> -- Blake Sullivan
>>
>>>>
>>>> Jeanne
>>>>
>>>> Mamallan Uthaman wrote, On 12/23/2009 9:15 PM PT:
>>>>> Hi Jeanne,
>>>>>
>>>>> I tried to implement a single CSS file to handle all mobile 
>>>>> browsers, but couldn't as @agent rule doesn't support range of 
>>>>> version. Example, I need to add some skinning only for blackberry 
>>>>> browsers of versions < 4.6. I noticed that you have been tracking 
>>>>> @agent  range-of -version  feature in TRINIDAD-1547. I am looking 
>>>>> forward to using this feature.
>>>>> As this feature is needed for skinning mobile-agents, we can 
>>>>> consider deprecating skinFamilyType API after this feature's release.
>>>>>
>>>>> Thanks
>>>>> Mamallan
>>>>>
>>>>> Jeanne Waldman wrote:
>>>>>> If you deprecate it, you can't then rename it. You'd have to 
>>>>>> deprecate skinFamilyType, create a new method with a better name, 
>>>>>> and then deprecate that when we have @import. So we'd end up with 
>>>>>> two deprecated apis in the end, which is not very clean.
>>>>>>
>>>>>> I think for now you should:
>>>>>> 1. deprecate skinFamilyType and stop using it yourself
>>>>>> 2. add @agent or @platform support to handle all the agents or 
>>>>>> platforms you need for mobile.
>>>>>> 3. use one skin-family and one css file until we have @import 
>>>>>> support or multiple <style-sheet-name>s per skin.
>>>>>>
>>>>>> The con of having so many skin-families is that the app developer 
>>>>>> needs to figure out which skin-family to use for each agent and 
>>>>>> render-kit-id.
>>>>>> Another con is the app developer needs to modify all the .css 
>>>>>> files if he wants to make one change that affects them all, like 
>>>>>> color: black to color:blue. If we use one skin-family, then the 
>>>>>> app developer can make one change in one file that affects all 
>>>>>> devices if he wants.
>>>>>>
>>>>>> Jeanne
>>>>>>
>>>>>> Mamallan Uthaman wrote, On 12/22/2009 12:35 PM PT:
>>>>>>> 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
>>>>>>>>>> <ma...@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
>>>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>
>>


Re: [Trinidad] Renaming an API that Is Used Only in Mobile Development

Posted by Mamallan Uthaman <ma...@oracle.com>.
I just checked the skinning based on an agent name and its version, 
Trinidad ignores the version. Example, I created a skin-family with the 
following in its CSS file.

@agent ie (version: 6)
{
   .class5
   {
     color: red;
     font-size: 13px;
   }
}

@agent ie  (version: 7)
{
   .class6
  {
     color: green;
     font-size: 20px;
   }
}

The CSS file sent to the ie 6.0 browser contains both .class5 and 
.class6. I tested it against the branch 1.2.12.1 and 1.2.12.2. Did I 
miss anything or is it a bug?

Thanks
Mamallan

P.S: Used a web-debugger tool called fiddler to examine the CSS file 
downloaded to the browser

Blake Sullivan wrote:
> Mamallan Uthaman said the following On 12/28/2009 12:24 PM PT:
>> Hi Jeanne,
>>
>> Please find my response inline.
>>
>> Thanks
>> Mamallan
>>
>> Jeanne Waldman wrote:
>>> Blake is working on this feature.
>>>
>>> Also, can you explain the kinds of things you need to skin 
>>> differently for your different agents? I'm curious.
>> These agent-based customizations are very much depended on 
>> applications. To name a few, Blackberry browsers don't support 
>> :active pseudo element unlike iPhone. So in an iPhone on clicking a 
>> link, we can have a loading-image as background using 
>> .Oralink:active. Also, I usually override default background color of 
>> buttons in Windows Mobile.
>>> Do you need to add extra @agent rules, or do you have what you need.
>> No, we have added enough agents and platforms. Currently, we only 
>> need the feature TRINIDAD-1547 to handle different agents based on 
>> versions and @import support for better usability.
> Mammallan, it's gross, but you can support multiple agents using the 
> OR feature of the queries:
>
> @agent blackberry and (version:4.5), blackberry and (version:4.4), 
> blackberry and (version:4.3), blackberry and (version:4.2), blackberry 
> and (version:4.1), blackberry and (version:4.0)
>
> -- Blake Sullivan
>
>>>
>>> Jeanne
>>>
>>> Mamallan Uthaman wrote, On 12/23/2009 9:15 PM PT:
>>>> Hi Jeanne,
>>>>
>>>> I tried to implement a single CSS file to handle all mobile 
>>>> browsers, but couldn't as @agent rule doesn't support range of 
>>>> version. Example, I need to add some skinning only for blackberry 
>>>> browsers of versions < 4.6. I noticed that you have been tracking 
>>>> @agent  range-of -version  feature in TRINIDAD-1547. I am looking 
>>>> forward to using this feature.
>>>> As this feature is needed for skinning mobile-agents, we can 
>>>> consider deprecating skinFamilyType API after this feature's release.
>>>>
>>>> Thanks
>>>> Mamallan
>>>>
>>>> Jeanne Waldman wrote:
>>>>> If you deprecate it, you can't then rename it. You'd have to 
>>>>> deprecate skinFamilyType, create a new method with a better name, 
>>>>> and then deprecate that when we have @import. So we'd end up with 
>>>>> two deprecated apis in the end, which is not very clean.
>>>>>
>>>>> I think for now you should:
>>>>> 1. deprecate skinFamilyType and stop using it yourself
>>>>> 2. add @agent or @platform support to handle all the agents or 
>>>>> platforms you need for mobile.
>>>>> 3. use one skin-family and one css file until we have @import 
>>>>> support or multiple <style-sheet-name>s per skin.
>>>>>
>>>>> The con of having so many skin-families is that the app developer 
>>>>> needs to figure out which skin-family to use for each agent and 
>>>>> render-kit-id.
>>>>> Another con is the app developer needs to modify all the .css 
>>>>> files if he wants to make one change that affects them all, like 
>>>>> color: black to color:blue. If we use one skin-family, then the 
>>>>> app developer can make one change in one file that affects all 
>>>>> devices if he wants.
>>>>>
>>>>> Jeanne
>>>>>
>>>>> Mamallan Uthaman wrote, On 12/22/2009 12:35 PM PT:
>>>>>> 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
>>>>>>>>> <ma...@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
>>>>>>>>>>
>>>>>>>
>>>>>>
>>>>
>

Re: [Trinidad] Renaming an API that Is Used Only in Mobile Development

Posted by Blake Sullivan <bl...@oracle.com>.
Mamallan Uthaman said the following On 12/28/2009 12:24 PM PT:
> Hi Jeanne,
>
> Please find my response inline.
>
> Thanks
> Mamallan
>
> Jeanne Waldman wrote:
>> Blake is working on this feature.
>>
>> Also, can you explain the kinds of things you need to skin 
>> differently for your different agents? I'm curious.
> These agent-based customizations are very much depended on 
> applications. To name a few, Blackberry browsers don't support :active 
> pseudo element unlike iPhone. So in an iPhone on clicking a link, we 
> can have a loading-image as background using .Oralink:active. Also, I 
> usually override default background color of buttons in Windows Mobile.
>> Do you need to add extra @agent rules, or do you have what you need.
> No, we have added enough agents and platforms. Currently, we only need 
> the feature TRINIDAD-1547 to handle different agents based on versions 
> and @import support for better usability.
Mammallan, it's gross, but you can support multiple agents using the OR 
feature of the queries:

@agent blackberry and (version:4.5), blackberry and (version:4.4), 
blackberry and (version:4.3), blackberry and (version:4.2), blackberry 
and (version:4.1), blackberry and (version:4.0)

-- Blake Sullivan

>>
>> Jeanne
>>
>> Mamallan Uthaman wrote, On 12/23/2009 9:15 PM PT:
>>> Hi Jeanne,
>>>
>>> I tried to implement a single CSS file to handle all mobile 
>>> browsers, but couldn't as @agent rule doesn't support range of 
>>> version. Example, I need to add some skinning only for blackberry 
>>> browsers of versions < 4.6. I noticed that you have been tracking 
>>> @agent  range-of -version  feature in TRINIDAD-1547. I am looking 
>>> forward to using this feature.
>>> As this feature is needed for skinning mobile-agents, we can 
>>> consider deprecating skinFamilyType API after this feature's release.
>>>
>>> Thanks
>>> Mamallan
>>>
>>> Jeanne Waldman wrote:
>>>> If you deprecate it, you can't then rename it. You'd have to 
>>>> deprecate skinFamilyType, create a new method with a better name, 
>>>> and then deprecate that when we have @import. So we'd end up with 
>>>> two deprecated apis in the end, which is not very clean.
>>>>
>>>> I think for now you should:
>>>> 1. deprecate skinFamilyType and stop using it yourself
>>>> 2. add @agent or @platform support to handle all the agents or 
>>>> platforms you need for mobile.
>>>> 3. use one skin-family and one css file until we have @import 
>>>> support or multiple <style-sheet-name>s per skin.
>>>>
>>>> The con of having so many skin-families is that the app developer 
>>>> needs to figure out which skin-family to use for each agent and 
>>>> render-kit-id.
>>>> Another con is the app developer needs to modify all the .css files 
>>>> if he wants to make one change that affects them all, like color: 
>>>> black to color:blue. If we use one skin-family, then the app 
>>>> developer can make one change in one file that affects all devices 
>>>> if he wants.
>>>>
>>>> Jeanne
>>>>
>>>> Mamallan Uthaman wrote, On 12/22/2009 12:35 PM PT:
>>>>> 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
>>>>>>>> <ma...@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
>>>>>>>>>
>>>>>>
>>>>>
>>>


Re: [Trinidad] Renaming an API that Is Used Only in Mobile Development

Posted by Mamallan Uthaman <ma...@oracle.com>.
Hi Jeanne,

Please find my response inline.

Thanks
Mamallan

Jeanne Waldman wrote:
> Blake is working on this feature.
>
> Also, can you explain the kinds of things you need to skin differently 
> for your different agents? I'm curious.
These agent-based customizations are very much depended on applications. 
To name a few, Blackberry browsers don't support :active pseudo element 
unlike iPhone. So in an iPhone on clicking a link, we can have a 
loading-image as background using .Oralink:active. Also, I usually 
override default background color of buttons in Windows Mobile. 
> Do you need to add extra @agent rules, or do you have what you need.
No, we have added enough agents and platforms. Currently, we only need 
the feature TRINIDAD-1547 to handle different agents based on versions 
and @import support for better usability.
>
> Jeanne
>
> Mamallan Uthaman wrote, On 12/23/2009 9:15 PM PT:
>> Hi Jeanne,
>>
>> I tried to implement a single CSS file to handle all mobile browsers, 
>> but couldn't as @agent rule doesn't support range of version. 
>> Example, I need to add some skinning only for blackberry browsers of 
>> versions < 4.6. I noticed that you have been tracking @agent  
>> range-of -version  feature in TRINIDAD-1547. I am looking forward to 
>> using this feature.
>> As this feature is needed for skinning mobile-agents, we can consider 
>> deprecating skinFamilyType API after this feature's release.
>>
>> Thanks
>> Mamallan
>>
>> Jeanne Waldman wrote:
>>> If you deprecate it, you can't then rename it. You'd have to 
>>> deprecate skinFamilyType, create a new method with a better name, 
>>> and then deprecate that when we have @import. So we'd end up with 
>>> two deprecated apis in the end, which is not very clean.
>>>
>>> I think for now you should:
>>> 1. deprecate skinFamilyType and stop using it yourself
>>> 2. add @agent or @platform support to handle all the agents or 
>>> platforms you need for mobile.
>>> 3. use one skin-family and one css file until we have @import 
>>> support or multiple <style-sheet-name>s per skin.
>>>
>>> The con of having so many skin-families is that the app developer 
>>> needs to figure out which skin-family to use for each agent and 
>>> render-kit-id.
>>> Another con is the app developer needs to modify all the .css files 
>>> if he wants to make one change that affects them all, like color: 
>>> black to color:blue. If we use one skin-family, then the app 
>>> developer can make one change in one file that affects all devices 
>>> if he wants.
>>>
>>> Jeanne
>>>
>>> Mamallan Uthaman wrote, On 12/22/2009 12:35 PM PT:
>>>> 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
>>>>>>> <ma...@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
>>>>>>>>
>>>>>
>>>>
>>

Re: [Trinidad] Renaming an API that Is Used Only in Mobile Development

Posted by Jeanne Waldman <je...@oracle.com>.
Blake is working on this feature.

Also, can you explain the kinds of things you need to skin differently 
for your different agents? I'm curious.
Do you need to add extra @agent rules, or do you have what you need.

Jeanne

Mamallan Uthaman wrote, On 12/23/2009 9:15 PM PT:
> Hi Jeanne,
>
> I tried to implement a single CSS file to handle all mobile browsers, 
> but couldn't as @agent rule doesn't support range of version. Example, 
> I need to add some skinning only for blackberry browsers of versions < 
> 4.6. I noticed that you have been tracking @agent  range-of -version  
> feature in TRINIDAD-1547. I am looking forward to using this feature.
> As this feature is needed for skinning mobile-agents, we can consider 
> deprecating skinFamilyType API after this feature's release.
>
> Thanks
> Mamallan
>
> Jeanne Waldman wrote:
>> If you deprecate it, you can't then rename it. You'd have to 
>> deprecate skinFamilyType, create a new method with a better name, and 
>> then deprecate that when we have @import. So we'd end up with two 
>> deprecated apis in the end, which is not very clean.
>>
>> I think for now you should:
>> 1. deprecate skinFamilyType and stop using it yourself
>> 2. add @agent or @platform support to handle all the agents or 
>> platforms you need for mobile.
>> 3. use one skin-family and one css file until we have @import support 
>> or multiple <style-sheet-name>s per skin.
>>
>> The con of having so many skin-families is that the app developer 
>> needs to figure out which skin-family to use for each agent and 
>> render-kit-id.
>> Another con is the app developer needs to modify all the .css files 
>> if he wants to make one change that affects them all, like color: 
>> black to color:blue. If we use one skin-family, then the app 
>> developer can make one change in one file that affects all devices if 
>> he wants.
>>
>> Jeanne
>>
>> Mamallan Uthaman wrote, On 12/22/2009 12:35 PM PT:
>>> 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
>>>>>> <ma...@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
>>>>>>>
>>>>
>>>
>

Re: [Trinidad] Renaming an API that Is Used Only in Mobile Development

Posted by Mamallan Uthaman <ma...@oracle.com>.
Hi Jeanne,

I tried to implement a single CSS file to handle all mobile browsers, 
but couldn't as @agent rule doesn't support range of version. Example, I 
need to add some skinning only for blackberry browsers of versions < 
4.6. I noticed that you have been tracking @agent  range-of -version  
feature in TRINIDAD-1547. I am looking forward to using this feature.
As this feature is needed for skinning mobile-agents, we can consider 
deprecating skinFamilyType API after this feature's release.

Thanks
Mamallan

Jeanne Waldman wrote:
> If you deprecate it, you can't then rename it. You'd have to deprecate 
> skinFamilyType, create a new method with a better name, and then 
> deprecate that when we have @import. So we'd end up with two 
> deprecated apis in the end, which is not very clean.
>
> I think for now you should:
> 1. deprecate skinFamilyType and stop using it yourself
> 2. add @agent or @platform support to handle all the agents or 
> platforms you need for mobile.
> 3. use one skin-family and one css file until we have @import support 
> or multiple <style-sheet-name>s per skin.
>
> The con of having so many skin-families is that the app developer 
> needs to figure out which skin-family to use for each agent and 
> render-kit-id.
> Another con is the app developer needs to modify all the .css files if 
> he wants to make one change that affects them all, like color: black 
> to color:blue. If we use one skin-family, then the app developer can 
> make one change in one file that affects all devices if he wants.
>
> Jeanne
>
> Mamallan Uthaman wrote, On 12/22/2009 12:35 PM PT:
>> 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
>>>>> <ma...@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
>>>>>>
>>>
>>

Re: [Trinidad] Renaming an API that Is Used Only in Mobile Development

Posted by Jeanne Waldman <je...@oracle.com>.
If you deprecate it, you can't then rename it. You'd have to deprecate 
skinFamilyType, create a new method with a better name, and then 
deprecate that when we have @import. So we'd end up with two deprecated 
apis in the end, which is not very clean.

I think for now you should:
1. deprecate skinFamilyType and stop using it yourself
2. add @agent or @platform support to handle all the agents or platforms 
you need for mobile.
3. use one skin-family and one css file until we have @import support or 
multiple <style-sheet-name>s per skin.

The con of having so many skin-families is that the app developer needs 
to figure out which skin-family to use for each agent and render-kit-id.
Another con is the app developer needs to modify all the .css files if 
he wants to make one change that affects them all, like color: black to 
color:blue. If we use one skin-family, then the app developer can make 
one change in one file that affects all devices if he wants.

Jeanne

Mamallan Uthaman wrote, On 12/22/2009 12:35 PM PT:
> 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
>>>> <ma...@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
>>>>>
>>
>

Re: [Trinidad] Renaming an API that Is Used Only in Mobile Development

Posted by Matthias Wessendorf <ma...@apache.org>.
On Tue, Dec 22, 2009 at 10:49 PM, Scott O'Bryan <so...@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
>>>>> <ma...@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

Re: [Trinidad] Renaming an API that Is Used Only in Mobile Development

Posted by Scott O'Bryan <so...@apache.org>.
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.

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
>>>> <ma...@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
>>>>>
>>


Re: [Trinidad] Renaming an API that Is Used Only in Mobile Development

Posted by Mamallan Uthaman <ma...@oracle.com>.
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
>>> <ma...@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
>>>>
>

Re: [Trinidad] Renaming an API that Is Used Only in Mobile Development

Posted by Blake Sullivan <bl...@oracle.com>.
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
>> <ma...@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
>>>


Re: [Trinidad] Renaming an API that Is Used Only in Mobile Development

Posted by Mamallan Uthaman <ma...@oracle.com>.
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
> <ma...@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
>>