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
