You are viewing a plain text version of this content. The canonical link for it is here.
Posted to adffaces-issues@incubator.apache.org by "Joseph Rozier (JIRA)" <ad...@incubator.apache.org> on 2006/08/15 15:29:45 UTC

[jira] Created: (ADFFACES-130) Avoid Hardcoding Height and Width Capabilities

Avoid Hardcoding Height and Width Capabilities
----------------------------------------------

                 Key: ADFFACES-130
                 URL: http://issues.apache.org/jira/browse/ADFFACES-130
             Project: MyFaces ADF-Faces
          Issue Type: Improvement
            Reporter: Joseph Rozier
            Priority: Minor


The height and width capabilities of some agents are hard-coded in the agents' capabilities xml files (located in trinidad-impl\src\main\resources\META-INF\agent).

In general, we should not hard code the height and width in this manner, particularly for agents that may have different heights/widths.  For example, currently Pocket IE 2003 is listed as having a height of 255 and a width of 229.  This is very specific to a device with a screen resolution of 320x240 with Pocket IE running with the default toolbars and in portrait orientation.  Because all of these are now variable (e.g. the device could be 240x240, the user could be running in landscape mode or fullscreen, etc), these numbers are fairly meaningless.

Instead, we should either rely on information provided in the request or not set these capabilities at all.  How these values are obtained will be agent specific.

For Pocket IE and IE Mobile, this information is available in the UA-pixels header.  Note that (a) the header shows the available pixels, not necessarily the current size of the window and (b) the agent may update this value as orientation changes (e.g. on a device in which the user can switch from portrait to landscape).

For reference, see:
http://blogs.msdn.com/iemobile/archive/2006/08/03/Detecting_IE_Mobile.aspx
http://www.watersprings.org/pub/id/draft-mutz-http-attributes-00.txt

App Developers should not rely on the height/width being present and, if it is present, should treat it as a hint.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

[jira] Updated: (ADFFACES-130) Avoid Hardcoding Height and Width Capabilities

Posted by "Joseph Rozier (JIRA)" <ad...@incubator.apache.org>.
     [ http://issues.apache.org/jira/browse/ADFFACES-130?page=all ]

Joseph Rozier updated ADFFACES-130:
-----------------------------------

    Status: Patch Available  (was: Open)

> Avoid Hardcoding Height and Width Capabilities
> ----------------------------------------------
>
>                 Key: ADFFACES-130
>                 URL: http://issues.apache.org/jira/browse/ADFFACES-130
>             Project: MyFaces ADF-Faces
>          Issue Type: Improvement
>            Reporter: Joseph Rozier
>            Priority: Minor
>
> The height and width capabilities of some agents are hard-coded in the agents' capabilities xml files (located in trinidad-impl\src\main\resources\META-INF\agent).
> In general, we should not hard code the height and width in this manner, particularly for agents that may have different heights/widths.  For example, currently Pocket IE 2003 is listed as having a height of 255 and a width of 229.  This is very specific to a device with a screen resolution of 320x240 with Pocket IE running with the default toolbars and in portrait orientation.  Because all of these are now variable (e.g. the device could be 240x240, the user could be running in landscape mode or fullscreen, etc), these numbers are fairly meaningless.
> Instead, we should either rely on information provided in the request or not set these capabilities at all.  How these values are obtained will be agent specific.
> For Pocket IE and IE Mobile, this information is available in the UA-pixels header.  Note that (a) the header shows the available pixels, not necessarily the current size of the window and (b) the agent may update this value as orientation changes (e.g. on a device in which the user can switch from portrait to landscape).
> For reference, see:
> http://blogs.msdn.com/iemobile/archive/2006/08/03/Detecting_IE_Mobile.aspx
> http://www.watersprings.org/pub/id/draft-mutz-http-attributes-00.txt
> App Developers should not rely on the height/width being present and, if it is present, should treat it as a hint.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

[jira] Updated: (ADFFACES-130) Avoid Hardcoding Height and Width Capabilities

Posted by "Adam Winer (JIRA)" <ad...@incubator.apache.org>.
     [ http://issues.apache.org/jira/browse/ADFFACES-130?page=all ]

Adam Winer updated ADFFACES-130:
--------------------------------

        Status: Resolved  (was: Patch Available)
    Resolution: Fixed

Checked in;  thanks Joseph!

> Avoid Hardcoding Height and Width Capabilities
> ----------------------------------------------
>
>                 Key: ADFFACES-130
>                 URL: http://issues.apache.org/jira/browse/ADFFACES-130
>             Project: MyFaces ADF-Faces
>          Issue Type: Improvement
>            Reporter: Joseph Rozier
>            Priority: Minor
>         Attachments: adffaces130.patch
>
>
> The height and width capabilities of some agents are hard-coded in the agents' capabilities xml files (located in trinidad-impl\src\main\resources\META-INF\agent).
> In general, we should not hard code the height and width in this manner, particularly for agents that may have different heights/widths.  For example, currently Pocket IE 2003 is listed as having a height of 255 and a width of 229.  This is very specific to a device with a screen resolution of 320x240 with Pocket IE running with the default toolbars and in portrait orientation.  Because all of these are now variable (e.g. the device could be 240x240, the user could be running in landscape mode or fullscreen, etc), these numbers are fairly meaningless.
> Instead, we should either rely on information provided in the request or not set these capabilities at all.  How these values are obtained will be agent specific.
> For Pocket IE and IE Mobile, this information is available in the UA-pixels header.  Note that (a) the header shows the available pixels, not necessarily the current size of the window and (b) the agent may update this value as orientation changes (e.g. on a device in which the user can switch from portrait to landscape).
> For reference, see:
> http://blogs.msdn.com/iemobile/archive/2006/08/03/Detecting_IE_Mobile.aspx
> http://www.watersprings.org/pub/id/draft-mutz-http-attributes-00.txt
> App Developers should not rely on the height/width being present and, if it is present, should treat it as a hint.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

[jira] Updated: (ADFFACES-130) Avoid Hardcoding Height and Width Capabilities

Posted by "Joseph Rozier (JIRA)" <ad...@incubator.apache.org>.
     [ http://issues.apache.org/jira/browse/ADFFACES-130?page=all ]

Joseph Rozier updated ADFFACES-130:
-----------------------------------

    Attachment: adffaces130.patch

I'm attaching a patch for this issue.

I modified AgentFactoryImpl to allow the main _populateAgentImpl to always have access to the request header map so that individual agents can grab what they need from it (e.g. for Pocket IE/IE Mobile we grab UA-pixels out of it).

I also modified the createAgent(String userAgent,String accept) public method to take a Map<String,String> instead.  This method was only used by the RenderKitBootstrap for testing.  I modified RenderKitBootstrap to use the new mechanism (including UA-pixels for the test Pocket IE agent).

I also went ahead and updated the User-Agent string that was being used in RenderKitBootstrap for Pocket IE 2003 to be more generic.

> Avoid Hardcoding Height and Width Capabilities
> ----------------------------------------------
>
>                 Key: ADFFACES-130
>                 URL: http://issues.apache.org/jira/browse/ADFFACES-130
>             Project: MyFaces ADF-Faces
>          Issue Type: Improvement
>            Reporter: Joseph Rozier
>            Priority: Minor
>         Attachments: adffaces130.patch
>
>
> The height and width capabilities of some agents are hard-coded in the agents' capabilities xml files (located in trinidad-impl\src\main\resources\META-INF\agent).
> In general, we should not hard code the height and width in this manner, particularly for agents that may have different heights/widths.  For example, currently Pocket IE 2003 is listed as having a height of 255 and a width of 229.  This is very specific to a device with a screen resolution of 320x240 with Pocket IE running with the default toolbars and in portrait orientation.  Because all of these are now variable (e.g. the device could be 240x240, the user could be running in landscape mode or fullscreen, etc), these numbers are fairly meaningless.
> Instead, we should either rely on information provided in the request or not set these capabilities at all.  How these values are obtained will be agent specific.
> For Pocket IE and IE Mobile, this information is available in the UA-pixels header.  Note that (a) the header shows the available pixels, not necessarily the current size of the window and (b) the agent may update this value as orientation changes (e.g. on a device in which the user can switch from portrait to landscape).
> For reference, see:
> http://blogs.msdn.com/iemobile/archive/2006/08/03/Detecting_IE_Mobile.aspx
> http://www.watersprings.org/pub/id/draft-mutz-http-attributes-00.txt
> App Developers should not rely on the height/width being present and, if it is present, should treat it as a hint.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira