myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Blake Sullivan <blake.sulli...@oracle.com>
Subject Re: [Trinidad] Renaming an API that Is Used Only in Mobile Development
Date Tue, 29 Dec 2009 00:23:45 GMT
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
>>>>>>>>>> <mamallan.uthaman@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
>>>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>
>>


Mime
View raw message