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

[Blake Sullivan]

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
<mamallan.utha...@oracle.com> wrote:

Hi all,

I need your valuable suggestions in renaming the following Trinidad API that

is used only in mobile development.

API Name:
skinFamilyType. It can be accessed using EL #
{requestContext.agent.skinFamilyType}

What is skinFamilyType API?

CSS-support of mobile browsers varies drastically as most of the mobile-browsers don’t strictly follow W3C standards. After analyzing various mobile-browsers, we have categorized mobile-browsers based on their CSS-support and exposed the category thru this API. Example, this API returns 'nokiawebkit' for NokiaS60 and 'iPhonewebkit' for iPhone.

Why Renaming?

This API doesn't return any skin-family; it simply returns the category to which a mobile-browser belongs based on the mobile-browser's CSS-support. So

the new name should reflect what it returns.

Alternate Name:
styleCategory

Typical Usage:

As CSS-support of mobile browsers varies drastically, developers usually create their own skinning with different versions of style-classes based on a mobile-browser's CSS-support. To handle all mobile-browsers in a single CSS-file, developers have to include lots of style-classes and tweaking such as @agent/@platform rules. The resulting CSS-file will be very huge, and it is not manageable. So developers prefer to maintain separate CSS files based on mobile-browsers’ CSS-support. By creating different skin-families with names same as values returned by this API, developers can easily switch to a

CSS file based on a requesting mobile-browser's CSS-support.
To illustrate with an example:

trinidad-config.xml contains #{requestContext.agent.skinFamilyType} (Remember, skinFamilyType returns 'nokiawebkit' for NokiaS60 and

'iPhonewebkit' for iPhone)

trinidad-skin.xml contains
  <skin>
       <id>iPhonewebkit</id>
       <family>iPhonewebkit</family>

<render-kit-id>org.apache.myfaces.trinidad.desktop</render-kit-id>

       <style-sheet-name>styles/iPhone.css</style-sheet-name>

<! -- iPhone.css is a CSS file created by a developer to handle

iPhone -->
   </skin>
   <skin>
       <id>nokiawebkit</id>
       <family>nokiawebkit</family>

<render-kit-id>org.apache.myfaces.trinidad.desktop</render-kit-id>

       <style-sheet-name>styles/symbian.css</style-sheet-name>

<! -- symbian.css is a CSS file created by a developer to handle

NokiaS60-->
   </skin>

Thanks
Mamallan