from:"Matt Cooper \(JIRA\)"

[jira] [Updated] (TRINIDAD-2457) Servlet external context wrapper missing JSF 2 API

2014-03-03 Thread Matt Cooper (JIRA)


 [ 
https://issues.apache.org/jira/browse/TRINIDAD-2457?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Matt Cooper updated TRINIDAD-2457:
--

   Resolution: Fixed
Fix Version/s: 2.1.1-core
 Assignee: Matt Cooper
   Status: Resolved  (was: Patch Available)

Thanks to Gary van Matre for the patch.

 Servlet external context wrapper missing JSF 2 API
 --

 Key: TRINIDAD-2457
 URL: https://issues.apache.org/jira/browse/TRINIDAD-2457
 Project: MyFaces Trinidad
  Issue Type: Bug
  Components: Components
Affects Versions: 2.1.1-core
 Environment: generic
Reporter: Gary VanMatre
Assignee: Matt Cooper
 Fix For: 2.1.1-core

 Attachments: ServletExternalContext.java.patch


 The  ServletExternalContext is created prior to the JSF lifecycle.  JSF 2 
 added the setResponseHeader API to the external context.  New code was 
 introduced that calls on this API prior to being dispatched to the faces 
 servlet resulting in an exception.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (TRINIDAD-2306) Use the trident version to detect the IE browser if available in the user agent string

2012-11-29 Thread Matt Cooper (JIRA)


 [ 
https://issues.apache.org/jira/browse/TRINIDAD-2306?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Matt Cooper updated TRINIDAD-2306:
--

   Resolution: Fixed
Fix Version/s: 2.1.0-core
   Status: Resolved  (was: Patch Available)

Patches applied to:
trunk - r1378677
2.0.0.x-branch - r1415345

 Use the trident version to detect the IE browser if available in the user 
 agent string
 --

 Key: TRINIDAD-2306
 URL: https://issues.apache.org/jira/browse/TRINIDAD-2306
 Project: MyFaces Trinidad
  Issue Type: Improvement
  Components: Components
Affects Versions: 2.1.0-core
Reporter: Gary VanMatre
 Fix For: 2.1.0-core

 Attachments: trinidad-IE-compat-override-2.x.patch, 
 trinidad-IE-compat-override.patch


 Starting with IE8, the trident version in the user agent string is a more 
 reliable way of detecting the maximum capabilities of the browser.  The 
 browser version string often defaults to IE7 when in compatibility mode or 
 using the IE WebBrowser component.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (TRINIDAD-2337) Typo in ListView component meta-data

2012-11-05 Thread Matt Cooper (JIRA)


 [ 
https://issues.apache.org/jira/browse/TRINIDAD-2337?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Matt Cooper updated TRINIDAD-2337:
--

   Resolution: Fixed
Fix Version/s: 2.1.0-core
   Status: Resolved  (was: Patch Available)

 Typo in ListView component meta-data
 

 Key: TRINIDAD-2337
 URL: https://issues.apache.org/jira/browse/TRINIDAD-2337
 Project: MyFaces Trinidad
  Issue Type: Bug
  Components: Components
Affects Versions: 2.0.2-core
Reporter: Venkata Guddanti
 Fix For: 2.1.0-core

 Attachments: lv-metadata.patch

   Original Estimate: 2h
  Remaining Estimate: 2h

 The meta-data for the new ListView component had typo in the event parameters 
 for the method expression. The event parameter for selectionListener and the 
 groupDisclosureListener has this type. Because of this ListView component 
 implementations will fail during jsp compilation for selectionListener and 
 groupDisclosureListener.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (TRINIDAD-2082) hidden labels don't always render in screen reader mode

2011-04-06 Thread Matt Cooper (JIRA)


 [ 
https://issues.apache.org/jira/browse/TRINIDAD-2082?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Matt Cooper updated TRINIDAD-2082:
--

   Resolution: Fixed
Fix Version/s: 2.0.0-beta-3
   Status: Resolved  (was: Patch Available)

 hidden labels don't always render in screen reader mode
 ---

 Key: TRINIDAD-2082
 URL: https://issues.apache.org/jira/browse/TRINIDAD-2082
 Project: MyFaces Trinidad
  Issue Type: Bug
  Components: Components
Reporter: Dave Robinson
Assignee: Matt Cooper
 Fix For: 2.0.0-beta-3

 Attachments: JIRA-TRINIDAD-2082.patch, JIRA-TRINIDAD-2082v2.patch


 When in screen reader mode, we always expect hidden labels to be rendered, as 
 these hidden labels often contain information (like labels for input fields) 
 necessary for 508 and WCAG 2.0 compliance.
 The HiddenLabelUtils has a method supportsHiddenLabels() that returns false 
 if the current agent does not support hidden (off page) labels on the page. 
 When in screen reader mode, this method should always return true, as we 
 always want labels to be present in screen reader mode - regardless if they 
 correctly appear hidden or not.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Created] (TRINIDAD-2075) The trinidad-maven maven-jdev-plugin hard-codes the context root of the jpr, should be a customizable property

2011-03-31 Thread Matt Cooper (JIRA)

The trinidad-maven maven-jdev-plugin hard-codes the context root of the jpr, 
should be a customizable property


 Key: TRINIDAD-2075
 URL: https://issues.apache.org/jira/browse/TRINIDAD-2075
 Project: MyFaces Trinidad
  Issue Type: Wish
Reporter: Matt Cooper


The 
https://svn.apache.org/repos/asf/myfaces/trinidad-maven/trunk/maven-jdev-plugin/src/main/java/org/apache/myfaces/trinidadbuild/plugin/jdeveloper/JDeveloperMojo.java
 file hard-codes the web application context root to be the name of the project 
plus -context-root:

// update the webapp context root
webappContextDOM.setAttribute(v, projectName + -context-root);

This results in very long URLs and worse is not customizable; you can't just 
specify that you want demo as your context root name.

It would be nice if this could be customized by specifying a property in the 
pom.xml file of your project.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (TRINIDAD-2070) log a warning message to warn the developers if rowkey is set but not unset at the end of the request

2011-03-25 Thread Matt Cooper (JIRA)


 [ 
https://issues.apache.org/jira/browse/TRINIDAD-2070?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Matt Cooper updated TRINIDAD-2070:
--

   Resolution: Fixed
Fix Version/s: 2.0.0-beta-3
 Assignee: Jeanne Waldman
   Status: Resolved  (was: Patch Available)

 log a warning message to warn the developers if rowkey is set but not unset 
 at the end of the request
 -

 Key: TRINIDAD-2070
 URL: https://issues.apache.org/jira/browse/TRINIDAD-2070
 Project: MyFaces Trinidad
  Issue Type: Bug
Reporter: Yuan Gao
Assignee: Jeanne Waldman
 Fix For: 2.0.0-beta-3

 Attachments: rowkey-warning.patch


 For uixcollections, we need to set the row key to operate on a specific row, 
 after that we need to unset the row key. If we leave the row key there, it 
 could cause all sorts of issues. 
 This is to log a warning message if at the end of the request, the row key is 
 not unset. 

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Created: (TRINIDAD-2033) trh:tableLayout tag doc should call out table-layout:fixed as desirable for programmatically-resizable cell contents

2011-02-11 Thread Matt Cooper (JIRA)

trh:tableLayout tag doc should call out table-layout:fixed as desirable for 
programmatically-resizable cell contents


 Key: TRINIDAD-2033
 URL: https://issues.apache.org/jira/browse/TRINIDAD-2033
 Project: MyFaces Trinidad
  Issue Type: Bug
Reporter: Matt Cooper
Assignee: Matt Cooper


The trh:tableLayout tag doc should call out table-layout:fixed as desirable for 
programmatically-resizable cell contents.

If you have a tableLayout and have percentage-based widths assigned to a 
cellFormat that contains a programmatically-resizable child component whose 
width is dependent on the cellFormat's percentage width, the child won't resize 
when the tableLayout resizes unless the tableLayout has an 
inlineStyle=table-layout:fixed.  This may not be obvious for people 
unfamiliar with how tables work so it needs to be mentioned in the tag 
documentation.

-- 
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Resolved: (TRINIDAD-2033) trh:tableLayout tag doc should call out table-layout:fixed as desirable for programmatically-resizable cell contents

2011-02-11 Thread Matt Cooper (JIRA)


 [ 
https://issues.apache.org/jira/browse/TRINIDAD-2033?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Matt Cooper resolved TRINIDAD-2033.
---

Resolution: Fixed

 trh:tableLayout tag doc should call out table-layout:fixed as desirable for 
 programmatically-resizable cell contents
 

 Key: TRINIDAD-2033
 URL: https://issues.apache.org/jira/browse/TRINIDAD-2033
 Project: MyFaces Trinidad
  Issue Type: Bug
Reporter: Matt Cooper
Assignee: Matt Cooper
 Fix For: 1.2.15-core , 2.0.0-beta-2


 The trh:tableLayout tag doc should call out table-layout:fixed as desirable 
 for programmatically-resizable cell contents.
 If you have a tableLayout and have percentage-based widths assigned to a 
 cellFormat that contains a programmatically-resizable child component whose 
 width is dependent on the cellFormat's percentage width, the child won't 
 resize when the tableLayout resizes unless the tableLayout has an 
 inlineStyle=table-layout:fixed.  This may not be obvious for people 
 unfamiliar with how tables work so it needs to be mentioned in the tag 
 documentation.

-- 
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (TRINIDAD-1970) tr:panelPopup does not work inside tr:accordionPanel

2010-12-06 Thread Matt Cooper (JIRA)


[ 
https://issues.apache.org/jira/browse/TRINIDAD-1970?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12967250#action_12967250
 ] 

Matt Cooper commented on TRINIDAD-1970:
---

If your showDetailItem is not disclosed, this is expected because undisclosed 
content is not going to be encoded (for performance reasons).

 tr:panelPopup does not work inside tr:accordionPanel
 

 Key: TRINIDAD-1970
 URL: https://issues.apache.org/jira/browse/TRINIDAD-1970
 Project: MyFaces Trinidad
  Issue Type: Test
  Components: Components
Affects Versions: 1.2.13-core 
 Environment: NWDS - JSF Project with Facelets,xml
Reporter: Sayan Mandal

 In my project, I have a tr:panelPopup embedded inside a tr:panelAccordion and 
 the panelPopup(even the link for opening the popup) does not appear. But if I 
 place the panelPopup outside the panelAccordion, it works. Please comment.
 tr:panelPopup text=Click Here!
   tr:panelGroupLayout layout=vertical
 tr:goLink text=point 1 destination=http://myfaces.apache.org/
   /tr:panelGroupLayout
 /tr:panelPopup

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Resolved: (TRINIDAD-744) Update translated message files

2010-11-30 Thread Matt Cooper (JIRA)


 [ 
https://issues.apache.org/jira/browse/TRINIDAD-744?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Matt Cooper resolved TRINIDAD-744.
--

Resolution: Fixed

 Update translated message files
 ---

 Key: TRINIDAD-744
 URL: https://issues.apache.org/jira/browse/TRINIDAD-744
 Project: MyFaces Trinidad
  Issue Type: Bug
Reporter: Bud Osterberg
Assignee: Matthias Weßendorf
 Fix For: 1.2.14-core , 2.0.0.3-core,  1.2.15-core , 2.0.0.4-core 

 Attachments: trinidad-translations.xml, trinslations-090917.tar.gz, 
 trinslations-1.2.12.3-101004.tar.gz, trinslations-trunk-101004.tar.gz, 
 trinslations080326.zip, trinslations080326.zip.md5, 
 trinslations080326.zip.sha1, trinslations080702.zip, 
 trinslations090825.tar.gz, trinslations100414_1.2.12.3.tar.gz, 
 trinslations_090112.jar, trinslations_090421.tar.gz, trinslations_090701.jar, 
 trinslations_1.2.12.1_091009.tar.gz, trinslations_1.2.12.1_091207.tar.gz, 
 trinslations_1.2.12.2_091009.tar.gz, trinslations_1.2.12.2_091022.tar.gz, 
 trinslations_1.2.12.2_100329.zip, trinslations_1.2.12.3_100823.tar.gz, 
 trinslations_101115-1.2.12.3.tar.gz, trinslations_101130_1.2.12.3.tar.gz, 
 trinslations_trunk_100524.tar.gz, trinslations_trunk_100804.tar.gz


 Latest versions of the message files (LoggerBundle, MessageBundle, and 
 CoreBundle) need translations.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (TRINIDAD-1930) Ability to easily create a meta tag

2010-09-30 Thread Matt Cooper (JIRA)

[
https://issues.apache.org/jira/browse/TRINIDAD-1930?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12916634#action_12916634
]

Matt Cooper commented on TRINIDAD-1930:
---

+1; type instead of nameType works for me.

Ability to easily create a meta tag
---

Key: TRINIDAD-1930
URL: https://issues.apache.org/jira/browse/TRINIDAD-1930
Project: MyFaces Trinidad
Issue Type: Improvement
Components: Components
Affects Versions: 1.2.14-core , 2.0.0.2-core
Reporter: Matt Cooper
Assignee: Matt Cooper

Ability to easily create a meta tag (e.g.
http://developer.apple.com/library/safari/#documentation/appleapplications/reference/safarihtmlref/articles/MetaTags.html
or http://www.webmarketingnow.com/tips/meta-tags-uncovered.html ) via a new
trh:meta tag.
Currently it is quite tedious to create a meta tag out of a component:
tr:document ...
f:facet name=metaContainer
tr:group id=metaContainer
tr:outputText escape=false
value='lt;meta name=viewport
content=width=device-width'
id=metaTag1/
tr:outputText escape=false
value='lt;meta name=apple-mobile-web-app-capable
content=yes'
id=metaTag2/
tr:outputText escape=false
value='lt;meta http-equiv=refresh
content=2;url=./test/index.jspx'
id=metaTag3/
/tr:group
/f:facet
/tr:document
It would be much better if we had a trh:meta component that looked like this:
tr:document ...
f:facet name=metaContainer
tr:group id=metaContainer
trh:meta name=viewport content=width=device-width/
trh:meta name=apple-mobile-web-app-capable content=yes/
trh:meta name=refresh nameType=http-equiv
content=2;url=./test/index.jspx/
/tr:group
/f:facet
/tr:document
So I would like to see a new trh:meta component that has an API like this:
Tag name: trh:meta
UIComponent class: org.apache.myfaces.trinidad.component.core.CoreMeta
Component type: org.apache.myfaces.trinidad.CoreMeta
The meta component generates an HTML meta tag and is intended to be used
inside either the trh:head tag or the document component's metaContainer
facet.
Events
Type Phases Description
org.apache.myfaces.trinidad.event.AttributeChangeEventInvoke
Application, Apply Request ValuesEvent delivered to describe an
attribute change. Attribute change events are not delivered for any
programmatic change to a property. They are only delivered when a renderer
changes a property without the application's specific request. An example of
an attribute change events might include the width of a column that supported
client-side resizing.
Attributes
Name TypeSupports EL?Description
attributeChangeListener javax.el.MethodExpression Only EL
a method reference to an attribute change listener. Attribute change events
are not delivered for any programmatic change to a property. They are only
delivered when a renderer changes a property without the application's
specific request. An example of an attribute change events might include the
width of a column that supported client-side resizing.
binding org.apache.myfaces.trinidad.component.core.CoreMeta Only EL
an EL reference that will store the component instance on a bean.
This can be used to give programmatic access to a component from a backing
bean, or to move creation of the component to a backing bean.
idString No the identifier for the component. The identifier must
follow a subset of the syntax allowed in HTML:
* Must not be a zero-length String.
* First character must be an ASCII letter (A-Za-z) or an underscore ('_').
* Subsequent characters must be an ASCII letter or digit (A-Za-z0-9), an
underscore ('_'), or a dash ('-').
rendered boolean Yes whether the component is rendered. When
set to false, no output will be delivered for this component (the component
will not in any way be rendered, and cannot be made visible on the client).
name String Yes the name or http-equiv attribute of the meta attribute
(see nameType)
nameType String Yes name or http-equiv indicating which kind of
name attribute is desired (name is the most common attribute but some older
meta tags need http-equiv)
content String Yes the content of the meta attribute

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (TRINIDAD-1930) Ability to easily create a meta tag

2010-09-30 Thread Matt Cooper (JIRA)

[
https://issues.apache.org/jira/browse/TRINIDAD-1930?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12916667#action_12916667
]

Matt Cooper commented on TRINIDAD-1930:
---

Other changes for consistency with other components in the trh namespace:

UIComponent class: org.apache.myfaces.trinidad.component.html.HtmlMeta
Component type: org.apache.myfaces.trinidad.HtmlMeta

Ability to easily create a meta tag
---

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Resolved: (TRINIDAD-1930) Ability to easily create a meta tag

2010-09-30 Thread Matt Cooper (JIRA)

[
https://issues.apache.org/jira/browse/TRINIDAD-1930?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Matt Cooper resolved TRINIDAD-1930.
---

Fix Version/s: 1.2.14-core
2.0.0.2-core
Resolution: Fixed

Ability to easily create a meta tag
---

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (TRINIDAD-1930) Ability to easily create a meta tag

2010-09-29 Thread Matt Cooper (JIRA)

Ability to easily create a meta tag
---

Currently it is quite tedious to create a meta tag out of a component:

tr:document ...
f:facet name=metaContainer
tr:group id=metaContainer
tr:outputText escape=false
value='lt;meta name=viewport
content=width=device-width'
id=metaTag1/
tr:outputText escape=false
value='lt;meta name=apple-mobile-web-app-capable
content=yes'
id=metaTag2/
tr:outputText escape=false
value='lt;meta http-equiv=refresh
content=2;url=./test/index.jspx'
id=metaTag3/
/tr:group
/f:facet
/tr:document

It would be much better if we had a trh:meta component that looked like this:

tr:document ...
f:facet name=metaContainer
tr:group id=metaContainer
trh:meta name=viewport content=width=device-width/
trh:meta name=apple-mobile-web-app-capable content=yes/
trh:meta name=refresh nameType=http-equiv
content=2;url=./test/index.jspx/
/tr:group
/f:facet
/tr:document

So I would like to see a new trh:meta component that has an API like this:

Tag name: trh:meta
UIComponent class: org.apache.myfaces.trinidad.component.core.CoreMeta
Component type: org.apache.myfaces.trinidad.CoreMeta
The meta component generates an HTML meta tag and is intended to be used inside
either the trh:head tag or the document component's metaContainer facet.

Events
TypePhases Description
org.apache.myfaces.trinidad.event.AttributeChangeEvent Invoke Application,
Apply Request ValuesEvent delivered to describe an attribute change.
Attribute change events are not delivered for any programmatic change to a
property. They are only delivered when a renderer changes a property without
the application's specific request. An example of an attribute change events
might include the width of a column that supported client-side resizing.

Attributes
NameTypeSupports EL?Description
attributeChangeListener javax.el.MethodExpression Only EL
a method reference to an attribute change listener. Attribute change events are
not delivered for any programmatic change to a property. They are only
delivered when a renderer changes a property without the application's specific
request. An example of an attribute change events might include the width of a
column that supported client-side resizing.
binding org.apache.myfaces.trinidad.component.core.CoreMeta Only EL
an EL reference that will store the component instance on a bean. This
can be used to give programmatic access to a component from a backing bean, or
to move creation of the component to a backing bean.
id String No the identifier for the component. The identifier must
follow a subset of the syntax allowed in HTML:

* Must not be a zero-length String.
* First character must be an ASCII letter (A-Za-z) or an underscore ('_').
* Subsequent characters must be an ASCII letter or digit (A-Za-z0-9), an
underscore ('_'), or a dash ('-').

renderedboolean Yes whether the component is rendered. When
set to false, no output will be delivered for this component (the component
will not in any way be rendered, and cannot be made visible on the client).
nameString Yes the name or http-equiv attribute of the meta attribute
(see nameType)
nameTypeString Yes name or http-equiv indicating which kind of
name attribute is desired (name is the most common attribute but some older
meta tags need http-equiv)
content String Yes the content of the meta attribute

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (TRINIDAD-1913) All tr:group component attributes to specify boundary and title preferences

2010-09-14 Thread Matt Cooper (JIRA)


 [ 
https://issues.apache.org/jira/browse/TRINIDAD-1913?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Matt Cooper updated TRINIDAD-1913:
--

   Status: Resolved  (was: Patch Available)
 Assignee: Matt Cooper
Fix Version/s:  2.0.0.2-core 
   Resolution: Fixed

 All tr:group component attributes to specify boundary and title preferences
 ---

 Key: TRINIDAD-1913
 URL: https://issues.apache.org/jira/browse/TRINIDAD-1913
 Project: MyFaces Trinidad
  Issue Type: Improvement
 Environment: N/A
Reporter: Dave Robinson
Assignee: Matt Cooper
 Fix For:  2.0.0.2-core 

 Attachments: TRINIDAD-1913 for Trinidad Trunk.patch

   Original Estimate: 24h
  Remaining Estimate: 24h

 When groups are rendered it is up to the container component on whether to 
 include a graphical group boundaries or title values. 
 This improvement would be to add attributes to tr:group so that a group could 
 specify it's preference to the container to either show or hide boundaries 
 and to use custom title values. Here are the new attributes:
 startBoundary
 indicates if a visual group start boundary is desired. The default value of 
 'dontCare' indicates no preference. A value of 'show' indicates a preference 
 to show a start boundary. A value of 'hide' indicates a preference to not 
 show a start boundary. Regardless of the start boundary value, whether a 
 visual boundary will be displayed is up to the group's parent component.
 endBoundary
 indicates if a visual group end boundary is desired. The default value of 
 'dontCare' indicates no preference. A value of 'show' indicates a preference 
 to show an end boundary. A value of 'hide' indicates a preference to not show 
 an end boundary. Regardless of the end boundary value, whether a visual 
 boundary will be displayed is up to the group's parent component.
 title
 a title value for the group. Whether anything is done with this title value 
 is up to the group's parent component.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (TRINIDAD-1877) visitTree API issues for UIXIterator (stamping components) in Trinidad 1.2.12.3 and Trunk

2010-09-01 Thread Matt Cooper (JIRA)

[
https://issues.apache.org/jira/browse/TRINIDAD-1877?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Matt Cooper updated TRINIDAD-1877:
--

Status: Resolved (was: Patch Available)
Assignee: Matt Cooper
Fix Version/s: 1.2.14-core
Resolution: Fixed

Looks like this is already in 1.2.x now also in 1.2.12.3-branch.

visitTree API issues for UIXIterator (stamping components) in Trinidad
1.2.12.3 and Trunk
--

Key: TRINIDAD-1877
URL: https://issues.apache.org/jira/browse/TRINIDAD-1877
Project: MyFaces Trinidad
Issue Type: Bug
Affects Versions: 1.2.12-core
Environment: All
Reporter: Kamran Kashanian
Assignee: Matt Cooper
Fix For: 1.2.14-core

Attachments: visitTree1.patch

There are different implementations of visitTree API in Trinidad Trunk and
1.2.12.x. Both implementations have problems with visiting the children of
'stamping' components (UIXIterator, UIXTable, UIXTree, etc).
For example in 1.2.12.3 branch a PPRed stamped child of a UIXIterator can
fail to render (never gets visited during encoding) because visitTree never
establishes the parent component's 'currency' before visiting the children.
In Trunk, the UIXIterator's implementation of visitTree assumes that the
direct children of UIXIterator are always non-stamped columns and skips over
visiting the direct children (goes directly to grand-children) when visiting
stamped children. This assumption is incorrect for UIXIterator (when
component is not a UIXTable/UIXTreeTable).
Attaching a proposed fix to address the issue in 1.2.12.3. The patch
overrides the visitTree API in UIXIterator and establishes the correct
'currency' before visiting the children of UIXIterator. Appreciate a review
and feedback.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (TRINIDAD-1893) trh:tablelayout not a layout table in screen reader mode

2010-08-26 Thread Matt Cooper (JIRA)


 [ 
https://issues.apache.org/jira/browse/TRINIDAD-1893?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Matt Cooper updated TRINIDAD-1893:
--

   Status: Resolved  (was: Patch Available)
Fix Version/s:  2.0.0.2-core 
   Resolution: Fixed

 trh:tablelayout not a layout table in screen reader mode
 

 Key: TRINIDAD-1893
 URL: https://issues.apache.org/jira/browse/TRINIDAD-1893
 Project: MyFaces Trinidad
  Issue Type: Bug
Reporter: Dave Robinson
Assignee: Matt Cooper
 Fix For:  2.0.0.2-core 

 Attachments: TRINIDAD-1893 1.2.12.3-branch.patch, TRINIDAD-1893 
 trunk.patch


 trh:tableLayout should be identified as a layout table (having 
 role=presentation) when it is rendered in screen reader mode.
 TableLayoutRenderer currently calls the OutputUtils.renderDataTableAttributes 
 method to render its table, and does not get this role assignment. The 
 TableLayoutRenderer should be updated to call the 
 OutputUtils.renderLayoutTableAttributes method instead, so it will get the 
 role assignment.
 I'll create and upload a patch.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (TRINIDAD-1895) Issue with UIXIterator visitData implementation

2010-08-26 Thread Matt Cooper (JIRA)


 [ 
https://issues.apache.org/jira/browse/TRINIDAD-1895?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Matt Cooper updated TRINIDAD-1895:
--

   Status: Resolved  (was: Patch Available)
Fix Version/s:  2.0.0.2-core 
   Resolution: Fixed

 Issue with UIXIterator visitData implementation
 ---

 Key: TRINIDAD-1895
 URL: https://issues.apache.org/jira/browse/TRINIDAD-1895
 Project: MyFaces Trinidad
  Issue Type: Bug
  Components: Components
Affects Versions: 2.0.0-alpha
Reporter: Kamran Kashanian
Assignee: Matt Cooper
 Fix For:  2.0.0.2-core 

 Attachments: visitdata.patch


 The UIXIterator 'visitData' method is called during 'visitTree' invocation to 
 visit the stamped children of UIXIterator.
 The implementation uses an IndexedRunner/KeyedRunner  to loop over all or 
 some rows and visit the contents of the row.   The issue is that the code 
 skips over direct stamped children of the UIXIterator and instead visits the 
 grandchildren.   
 Looks like the code is assuming that direct children of UIXIterator are 
 unstamped columns (UIXColumn) and should be skipped over during 
 stamping-visit.   This assumption is correct for sub-classes of UIXIterator 
 but not for UIXIterator.  UIXIterator does not have columns.
 The visiting logic is already using a NoColumnFacetsVisitContext.  So on 
 invokeVisitCallback,  it skips over any columns and visits the column 
 children.  It also handles nested columns.  
 So the proposal is to change the code in IndexedRunner/KeyedRunner as 
 follows:
 Change this:
 @Override
 protected void process(UIComponent kid, ComponentProcessingContext 
 cpContext)
 {
   if (kid.getChildCount()  0)
   {
 for (UIComponent grandKid : kid.getChildren())
 {
   if (UIXComponent.visitTree(noColumnFacetContext, grandKid, 
 visitCallback))
   {
 throw new AbortProcessingException();
   }
 }
   }
 }
 To this:
 @Override
 protected void process(UIComponent kid, ComponentProcessingContext 
 cpContext)
 {
   if (UIXComponent.visitTree(noColumnFacetContext, kid, 
 visitCallback))
   {
 throw new AbortProcessingException();
   }
 }

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (TRINIDAD-1834) tr:showDetail prompt facet doesn't fire ActionEvents if it's closed

2010-08-13 Thread Matt Cooper (JIRA)


[ 
https://issues.apache.org/jira/browse/TRINIDAD-1834?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12898306#action_12898306
 ] 

Matt Cooper commented on TRINIDAD-1834:
---

I believe this patch will have a drastic negative impact on performance since 
with this patch, undisclosed content will be processed.

 tr:showDetail prompt facet doesn't fire ActionEvents if it's closed
 ---

 Key: TRINIDAD-1834
 URL: https://issues.apache.org/jira/browse/TRINIDAD-1834
 Project: MyFaces Trinidad
  Issue Type: Bug
  Components: Components
Affects Versions: 1.2.13-core 
 Environment: mojarra 1.2_10, facelets 1.1.14, ext-val 1.2.3
Reporter: Markus Dreher
 Attachments: patch.patch


 when I use a tr:commandLink in tr:showDetail prompt facet, the actionListener 
 is only invoke when the component is disclosed.
 tr:showDetail id=sdWeitereVornamen styleClass=showDetailInput
   f:facet name=prompt
   tr:commandLink 
 actionListener=#{einwohnerDetailsController.namensaenderung} 
 id=namensaenderungLink
 tr:image inlineStyle=width: 16px; height: 16px; 
 source= /images/bearbeiten.png /
   /tr:commandLink
   /f:facet  
 ...
 /tr:showDetail
 The actionlistener should also be invoked if it's closed. the same applies to 
 input components and validators.
 In processDecodes, (processUpdates, processValidators) in UIXShowDetail class
 , facets and children will only be processed, if the components is disclosed. 
 But facets should be processed in closed and disclosed state.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (TRINIDAD-1834) tr:showDetail prompt facet doesn't fire ActionEvents if it's closed

2010-08-13 Thread Matt Cooper (JIRA)


[ 
https://issues.apache.org/jira/browse/TRINIDAD-1834?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12898323#action_12898323
 ] 

Matt Cooper commented on TRINIDAD-1834:
---

If the issue is that the prompt facet is still visible and possible to click 
when the showDetail is undisclosed then perhaps the fix needs to be 
specifically for the UIXShowDetail's prompt facet--no other facets or children.

 tr:showDetail prompt facet doesn't fire ActionEvents if it's closed
 ---

 Key: TRINIDAD-1834
 URL: https://issues.apache.org/jira/browse/TRINIDAD-1834
 Project: MyFaces Trinidad
  Issue Type: Bug
  Components: Components
Affects Versions: 1.2.13-core 
 Environment: mojarra 1.2_10, facelets 1.1.14, ext-val 1.2.3
Reporter: Markus Dreher
 Attachments: patch.patch


 when I use a tr:commandLink in tr:showDetail prompt facet, the actionListener 
 is only invoke when the component is disclosed.
 tr:showDetail id=sdWeitereVornamen styleClass=showDetailInput
   f:facet name=prompt
   tr:commandLink 
 actionListener=#{einwohnerDetailsController.namensaenderung} 
 id=namensaenderungLink
 tr:image inlineStyle=width: 16px; height: 16px; 
 source= /images/bearbeiten.png /
   /tr:commandLink
   /f:facet  
 ...
 /tr:showDetail
 The actionlistener should also be invoked if it's closed. the same applies to 
 input components and validators.
 In processDecodes, (processUpdates, processValidators) in UIXShowDetail class
 , facets and children will only be processed, if the components is disclosed. 
 But facets should be processed in closed and disclosed state.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (TRINIDAD-1880) Changing the font-color of middle/top portion of a disabled tab doesn't work for Internet Explorer (v6-v8)

2010-08-12 Thread Matt Cooper (JIRA)

[
https://issues.apache.org/jira/browse/TRINIDAD-1880?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12897806#action_12897806
]

Matt Cooper commented on TRINIDAD-1880:
---

I vaguely remember IE6 having a problem with not being able to handle a certain
kind of selector. I don't recall if it was compound selectors (e.g. .x.y),
containment selectors (e.g. .x .y), or a combination of both (e.g. .x.y
.z). It sounds like this might be what you are running into.

Can you confirm which version(s) of Internet Explorer you are having this
problem in; is this only a problem in IE6?

I don't have access to a computer that runs IE6 but a definition like this
appears to be working in IE7 and IE8.

Changing the font-color of middle/top portion of a disabled tab doesn't work
for Internet Explorer (v6-v8)
--

Key: TRINIDAD-1880
URL: https://issues.apache.org/jira/browse/TRINIDAD-1880
Project: MyFaces Trinidad
Issue Type: Bug
Components: Skinning
Affects Versions: 1.0.8-core
Environment: windows xp, ie6, ie7, ie8
trinidad package: ...-api-1.0.8.jar and ...-impl-1.0.8.jar
Reporter: teckpro

hi there,
usually the (css-) skinning for an inactive middle tab works with
af|navigationPane::tabs-inactive af|navigationPane::tabs-mid and i got no
problem there. unfortunately the documentation doesn't explain how to style
disabled-inactive tabs. so after trying a bit i found out that
af|navigationPane::tabs-inactive:disabled af|navigationPane::tabs-mid
is the correct css-class for skinning the color. but then i realized that it
has no effect at all for every version of the IE and again unfortunately our
customer works exclusively with IE and nothing else.
can someone help me or fix the problem?
thanks in advance
jonathan

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (TRINIDAD-1880) Changing the font-color of middle/top portion of a disabled tab doesn't work for Internet Explorer (v6-v8)

2010-08-12 Thread Matt Cooper (JIRA)


[ 
https://issues.apache.org/jira/browse/TRINIDAD-1880?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12897807#action_12897807
 ] 

Matt Cooper commented on TRINIDAD-1880:
---

If what you are seeing reproduces in all versions of IE then perhaps this is 
simply a matter of CSS specificity; your disabled selector is less specific 
than the selector that is winning.

Here's a good page that describes how specificity is calculated:
http://www.w3.org/TR/CSS2/cascade.html#specificity

 Changing the font-color of middle/top portion of a disabled tab doesn't work 
 for Internet Explorer (v6-v8)
 --

 Key: TRINIDAD-1880
 URL: https://issues.apache.org/jira/browse/TRINIDAD-1880
 Project: MyFaces Trinidad
  Issue Type: Bug
  Components: Skinning
Affects Versions:  1.0.8-core
 Environment: windows xp, ie6, ie7, ie8
 trinidad package: ...-api-1.0.8.jar and ...-impl-1.0.8.jar
Reporter: teckpro

 hi there,
 usually the (css-) skinning for an inactive middle tab works with 
 af|navigationPane::tabs-inactive af|navigationPane::tabs-mid and i got no 
 problem there. unfortunately the documentation doesn't explain how to style 
 disabled-inactive tabs. so after trying a bit i found out that 
 af|navigationPane::tabs-inactive:disabled af|navigationPane::tabs-mid
 is the correct css-class for skinning the color. but then i realized that it 
 has no effect at all for every version of the IE and again unfortunately our 
 customer works exclusively with IE and nothing else.
 can someone help me or fix the problem?
 thanks in advance
 jonathan

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (TRINIDAD-1870) tr:commandLink blocks tr:panelAccordion

2010-07-30 Thread Matt Cooper (JIRA)


[ 
https://issues.apache.org/jira/browse/TRINIDAD-1870?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12894074#action_12894074
 ] 

Matt Cooper commented on TRINIDAD-1870:
---

The stateSaving property in my example can be deleted, e.g. 
tr:document title=test

 tr:commandLink blocks tr:panelAccordion
 ---

 Key: TRINIDAD-1870
 URL: https://issues.apache.org/jira/browse/TRINIDAD-1870
 Project: MyFaces Trinidad
  Issue Type: Bug
Affects Versions: 2.0.0.3-core
 Environment: MyFaces 2.0.1, Jetty 6.1.8, jdk 1.6.0_20, win 7
Reporter: Cedric Durmont

 I'm cleaning bugs in my app after my switch to Trinidad2, and I found
 2 problems that seems not to be on my side :
 1. I'm unable to change of tab in a panelTabbed with a click (works
 programmatically using disclosed attribute)
 2. Consider this sample.xhtml :
 ?xml version=1.0 encoding=windows-1252 ?
 !DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Transitional//EN
  http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd;
 html xmlns=http://www.w3.org/1999/xhtml;
xmlns:f=http://java.sun.com/jsf/core;
xmlns:tr=http://myfaces.apache.org/trinidad;
xmlns:t=http://myfaces.apache.org/tomahawk;
xmlns:trh=http://myfaces.apache.org/trinidad/html;
xmlns:c=http://java.sun.com/jsp/jstl/core;
xmlns:ui=http://java.sun.com/jsf/facelets;
 trh:head
titleSome title/title
tr:importScript/tr:importScript
 /trh:head
 trh:body
 tr:form
 tr:commandLink/
tr:panelAccordion
tr:showDetailItem text=foofoo/tr:showDetailItem
tr:showDetailItem text=barbar/tr:showDetailItem
 /tr:panelAccordion
 /tr:form
 /trh:body
 /html
 In this case, the panelAccordion does not work (details are not
 disclosed when you click on it). Remove the commandLink, it works
 again. Replace the commandLink by a commandButton, it works too.
 Setting attributes on the commandLink does not change the situation.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (TRINIDAD-1870) tr:commandLink blocks tr:panelAccordion

2010-07-30 Thread Matt Cooper (JIRA)


[ 
https://issues.apache.org/jira/browse/TRINIDAD-1870?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12894073#action_12894073
 ] 

Matt Cooper commented on TRINIDAD-1870:
---

I can confirm that in a Facelets xhtml page, this is the case.

Note that using a jspx page like this, it works fine:

?xml version=1.0 encoding=utf-8 standalone=yes ?
jsp:root xmlns:jsp=http://java.sun.com/JSP/Page; version=2.0
  xmlns:f=http://java.sun.com/jsf/core;
  xmlns:tr=http://myfaces.apache.org/trinidad;
  jsp:directive.page contentType=text/html;charset=utf-8/
  f:view
tr:document title=Apache Trinidad Demo Index stateSaving=client
   tr:form
 tr:commandLink/
 tr:panelAccordion
   tr:showDetailItem text=foofoo/tr:showDetailItem
   tr:showDetailItem text=barbar/tr:showDetailItem
 /tr:panelAccordion
  /tr:form
/tr:document
  /f:view
/jsp:root

 tr:commandLink blocks tr:panelAccordion
 ---

 Key: TRINIDAD-1870
 URL: https://issues.apache.org/jira/browse/TRINIDAD-1870
 Project: MyFaces Trinidad
  Issue Type: Bug
Affects Versions: 2.0.0.3-core
 Environment: MyFaces 2.0.1, Jetty 6.1.8, jdk 1.6.0_20, win 7
Reporter: Cedric Durmont

 I'm cleaning bugs in my app after my switch to Trinidad2, and I found
 2 problems that seems not to be on my side :
 1. I'm unable to change of tab in a panelTabbed with a click (works
 programmatically using disclosed attribute)
 2. Consider this sample.xhtml :
 ?xml version=1.0 encoding=windows-1252 ?
 !DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Transitional//EN
  http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd;
 html xmlns=http://www.w3.org/1999/xhtml;
xmlns:f=http://java.sun.com/jsf/core;
xmlns:tr=http://myfaces.apache.org/trinidad;
xmlns:t=http://myfaces.apache.org/tomahawk;
xmlns:trh=http://myfaces.apache.org/trinidad/html;
xmlns:c=http://java.sun.com/jsp/jstl/core;
xmlns:ui=http://java.sun.com/jsf/facelets;
 trh:head
titleSome title/title
tr:importScript/tr:importScript
 /trh:head
 trh:body
 tr:form
 tr:commandLink/
tr:panelAccordion
tr:showDetailItem text=foofoo/tr:showDetailItem
tr:showDetailItem text=barbar/tr:showDetailItem
 /tr:panelAccordion
 /tr:form
 /trh:body
 /html
 In this case, the panelAccordion does not work (details are not
 disclosed when you click on it). Remove the commandLink, it works
 again. Replace the commandLink by a commandButton, it works too.
 Setting attributes on the commandLink does not change the situation.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (TRINIDAD-1871) Add the ability to define skinning variables so things like colors can be abstract configurations not tied to specific color uses like border-color

2010-07-30 Thread Matt Cooper (JIRA)

Add the ability to define skinning variables so things like colors can be 
abstract configurations not tied to specific color uses like border-color
---

 Key: TRINIDAD-1871
 URL: https://issues.apache.org/jira/browse/TRINIDAD-1871
 Project: MyFaces Trinidad
  Issue Type: Improvement
  Components: Skinning
Affects Versions: 2.0.0-alpha
Reporter: Matt Cooper


A nice skinning enhancement would be to add the ability to define skinning 
variables so things like colors can be abstract configurations not tied to 
specific color uses like border-color.

For discussion purposes, let's say one of these variables is defined like this:

.AFSomeColor:variable {
  #aabbcc;
}

Notice that there is nothing forcing this color to be tied to a specific style 
property.  It is just an abstract global location for defining a given color 
value (or background image, dimension, etc.).
It is important to note that some variable may have spaces in their value.
I'm also not trying to force a syntax with this example so there may be a 
better syntax but what you see here is just one example to get the idea across.

Anyhow, once you have this variable defined, you can then use it anywhere you 
would type in a style value, e.g.:

af|table::column-resize-indicator {
  border-right: 2px dotted -tr-variable-ref(.AFSomeColor:variable);
}

then someone else could do this with the same variable:

af|someCustomComponent {
  background-color: -tr-variable-ref(.AFSomeColor:variable);
}

or even use that same color value in some future CSS property, e.g.:

af|someCustomComponent {
  -fancy-browser-custom-property: -tr-variable-ref(.AFSomeColor:variable);
}

If we abstracted our skins into some core variables, it would be super easy for 
someone to create a new skin by just changing a small number of color value 
variables.

If we really wanted to take this to a further level, we could apply transforms 
to these variables.  So for example, if someone defines a color variable in one 
location, selectors throughout the skin could consume that color variable but 
perform a transform on it, e.g. blend it a certain amount from that color to 
another color variable to create a color that is halfway between 2 colors, or 
to produce a desaturated version of that color value, etc.  If this sounds too 
much like scope creep, this can be spun off into its own JIRA issue but I 
mention it here in case it has any impact on how this skin variable idea gets 
implemented.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (TRINIDAD-1840) UIXTable and UIXTreeTable should provide hooks into decode/validate/updateChildrenImpl

2010-06-22 Thread Matt Cooper (JIRA)


 [ 
https://issues.apache.org/jira/browse/TRINIDAD-1840?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Matt Cooper updated TRINIDAD-1840:
--

   Status: Resolved  (was: Patch Available)
Fix Version/s: 2.0.0.3-core
   Resolution: Fixed

 UIXTable and UIXTreeTable should provide hooks into 
 decode/validate/updateChildrenImpl
 --

 Key: TRINIDAD-1840
 URL: https://issues.apache.org/jira/browse/TRINIDAD-1840
 Project: MyFaces Trinidad
  Issue Type: Improvement
  Components: Components
Affects Versions: 2.0.0-alpha
 Environment: All
Reporter: Kamran Kashanian
Assignee: Matt Cooper
 Fix For: 2.0.0.3-core

 Attachments: hooks.patch


 The Trinidad UIXCollection class provides hooks for processing of 
 stamped/unstamped children and facets during decode/validate/update-model JSF 
 lifecycle phases for any collection components that extent UIXCollection. 
 See the abstract method processFacetsAndChildren in 
 decode/validate/updateChildrenImpl in UIXCollection.   This allows collection 
 component subclasses to perform special logic for handling stamped/unstamped 
 children, and facets during decode/validate/update-model phases.
 UIXTable and UIXTreeTable provide concrete implementations for 
 processFacetsAndChildren.  However,  both of these components make 
 processFacetsAndChildren final and disallow any subclasses from overriding 
 and customizing the child processing logic.
 The proposal is to make UIXTable and UIXTreeTable child component processing 
 more extensible as follows:
 1) Remove the 'final' keyword from processFacetsAndChildren and allow 
 subclasses to override these methods
 2) Provide more hooks into the existing processFacetsAndChildren processing 
 by making the utility methods in TableUtils (processStampedChildren, 
 processColumnFacets, and processFacets) public.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Resolved: (TRINIDAD-1839) Agent PLATFORM_IPHONE should detect iPad as well

2010-06-18 Thread Matt Cooper (JIRA)


 [ 
https://issues.apache.org/jira/browse/TRINIDAD-1839?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Matt Cooper resolved TRINIDAD-1839.
---

Fix Version/s: 1.2.14-core 
   1.0.13-core 
   2.0.0.3-core
   Resolution: Fixed

 Agent PLATFORM_IPHONE should detect iPad as well
 

 Key: TRINIDAD-1839
 URL: https://issues.apache.org/jira/browse/TRINIDAD-1839
 Project: MyFaces Trinidad
  Issue Type: Bug
Affects Versions: 1.2.14-core , 1.0.13-core , 2.0.0.3-core
 Environment: iPad
Reporter: Dave Robinson
Assignee: Matt Cooper
 Fix For: 1.2.14-core , 1.0.13-core , 2.0.0.3-core


 We currently use agent platform iphone to identify iPhone and iPod touch. 
 It really means iOS. We should add iPad to this definition as well.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (TRINIDAD-1830) UIXHierarchy.visitHierarchy() has a bad if statement

2010-06-11 Thread Matt Cooper (JIRA)

UIXHierarchy.visitHierarchy() has a bad if statement


 Key: TRINIDAD-1830
 URL: https://issues.apache.org/jira/browse/TRINIDAD-1830
 Project: MyFaces Trinidad
  Issue Type: Bug
Affects Versions:  2.0.0.2-core 
Reporter: Matt Cooper
Assignee: Matt Cooper


I have found some code in UIXHierarchy.visitHierarchy() where according to the 
code's indentation, a return true should happen only if the if statement is 
true.

However, this if clause ends with a semicolon so regardless of whether the the 
clause is true, the return true will always happen.

This ends up causing UIXHierarchy.visitHierarchy() to short circuit prematurely 
(and a call to UIXTree.visitChildren() to in turn short circuit visitation of 
the view).

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Resolved: (TRINIDAD-1830) UIXHierarchy.visitHierarchy() has a bad if statement

2010-06-11 Thread Matt Cooper (JIRA)


 [ 
https://issues.apache.org/jira/browse/TRINIDAD-1830?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Matt Cooper resolved TRINIDAD-1830.
---

Fix Version/s: 1.2.14-core 
2.0.0.2-core 
   Resolution: Fixed

 UIXHierarchy.visitHierarchy() has a bad if statement
 

 Key: TRINIDAD-1830
 URL: https://issues.apache.org/jira/browse/TRINIDAD-1830
 Project: MyFaces Trinidad
  Issue Type: Bug
Affects Versions:  2.0.0.2-core 
Reporter: Matt Cooper
Assignee: Matt Cooper
 Fix For: 1.2.14-core ,  2.0.0.2-core 


 I have found some code in UIXHierarchy.visitHierarchy() where according to 
 the code's indentation, a return true should happen only if the if statement 
 is true.
 However, this if clause ends with a semicolon so regardless of whether the 
 the clause is true, the return true will always happen.
 This ends up causing UIXHierarchy.visitHierarchy() to short circuit 
 prematurely (and a call to UIXTree.visitChildren() to in turn short circuit 
 visitation of the view).

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Reopened: (TRINIDAD-885) Provide selector to show navigation bar on bottom of table

2010-05-28 Thread Matt Cooper (JIRA)


 [ 
https://issues.apache.org/jira/browse/TRINIDAD-885?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Matt Cooper reopened TRINIDAD-885:
--


 Provide selector to show navigation bar on bottom of table 
 ---

 Key: TRINIDAD-885
 URL: https://issues.apache.org/jira/browse/TRINIDAD-885
 Project: MyFaces Trinidad
  Issue Type: Wish
Reporter: Frank Nimphius
Assignee: Matt Cooper
Priority: Minor
 Fix For: 1.2.14-core ,  2.0.0.2-core 


 In ADF Faces there exist a selector -ora-repeat-control-bar that could be 
 used to show the table navigation bar on top and at the bottom of the table 
 (instead of on top only)
 af|table{ -ora-repeat-control-bar: true; } 
 A comparable selector is missing in Trinidad, which may become a problem fro 
 ADF Faces customers that migrate to Trinidad in JDeveloper 11. For a smooth 
 migration from ADF Faces to Trinidad it is highly desirable to have this 
 selector added to Trinidad

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Resolved: (TRINIDAD-885) Provide selector to show navigation bar on bottom of table

2010-05-28 Thread Matt Cooper (JIRA)


 [ 
https://issues.apache.org/jira/browse/TRINIDAD-885?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Matt Cooper resolved TRINIDAD-885.
--

Fix Version/s: 1.2.14-core 
   Resolution: Fixed

 Provide selector to show navigation bar on bottom of table 
 ---

 Key: TRINIDAD-885
 URL: https://issues.apache.org/jira/browse/TRINIDAD-885
 Project: MyFaces Trinidad
  Issue Type: Wish
Reporter: Frank Nimphius
Assignee: Matt Cooper
Priority: Minor
 Fix For: 1.2.14-core ,  2.0.0.2-core 


 In ADF Faces there exist a selector -ora-repeat-control-bar that could be 
 used to show the table navigation bar on top and at the bottom of the table 
 (instead of on top only)
 af|table{ -ora-repeat-control-bar: true; } 
 A comparable selector is missing in Trinidad, which may become a problem fro 
 ADF Faces customers that migrate to Trinidad in JDeveloper 11. For a smooth 
 migration from ADF Faces to Trinidad it is highly desirable to have this 
 selector added to Trinidad

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Resolved: (TRINIDAD-885) Provide selector to show navigation bar on bottom of table

2010-05-27 Thread Matt Cooper (JIRA)


 [ 
https://issues.apache.org/jira/browse/TRINIDAD-885?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Matt Cooper resolved TRINIDAD-885.
--

 Assignee: Matt Cooper
Fix Version/s:  2.0.0.2-core 
   Resolution: Fixed

 Provide selector to show navigation bar on bottom of table 
 ---

 Key: TRINIDAD-885
 URL: https://issues.apache.org/jira/browse/TRINIDAD-885
 Project: MyFaces Trinidad
  Issue Type: Wish
Reporter: Frank Nimphius
Assignee: Matt Cooper
Priority: Minor
 Fix For:  2.0.0.2-core 


 In ADF Faces there exist a selector -ora-repeat-control-bar that could be 
 used to show the table navigation bar on top and at the bottom of the table 
 (instead of on top only)
 af|table{ -ora-repeat-control-bar: true; } 
 A comparable selector is missing in Trinidad, which may become a problem fro 
 ADF Faces customers that migrate to Trinidad in JDeveloper 11. For a smooth 
 migration from ADF Faces to Trinidad it is highly desirable to have this 
 selector added to Trinidad

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (TRINIDAD-1696) acc (screen reader mode) layout tables should include role=presentation

2010-01-29 Thread Matt Cooper (JIRA)


 [ 
https://issues.apache.org/jira/browse/TRINIDAD-1696?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Matt Cooper updated TRINIDAD-1696:
--

   Resolution: Fixed
Fix Version/s: 1.2.14-core 
   Status: Resolved  (was: Patch Available)

 acc (screen reader mode) layout tables should include role=presentation
 -

 Key: TRINIDAD-1696
 URL: https://issues.apache.org/jira/browse/TRINIDAD-1696
 Project: MyFaces Trinidad
  Issue Type: Bug
Affects Versions:  1.2.12-core
 Environment: all
Reporter: Dave Robinson
Assignee: Matt Cooper
Priority: Minor
 Fix For: 1.2.14-core 

 Attachments: TRINIDAD-1696 for trinidad 1.2.12.1.patch, TRINIDAD-1696 
 for trinidad 1.2.12.2.patch, TRINIDAD-1696 for trinidad trunk.patch

   Original Estimate: 3h
  Remaining Estimate: 3h

 When using trh:tableLayout in our page to layout some UI components, it gives
 warning during Accessibility testing:
 WARNING - This layout Table could be confused for a data table by Screen
 Readers
 From the html perspective, this warning can be fixed by setting
 role=presentation
 on the html table element.  
 We can add
 role=presentation to layout tables with the following addition to
 org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.OutputTextUtils.renderLayoutTableAttributes():
 if (CoreRenderer.isScreenReaderMode(arc))
 {
   ResponseWriter writer = context.getResponseWriter();
   writer.writeAttribute(datatable, 0, null);
 -- writer.writeAttribute(role, presentation, null);  --
 }

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (TRINIDAD-1691) Skinning framework support for skin versioning

2010-01-20 Thread Matt Cooper (JIRA)

Skinning framework support for skin versioning
--

 Key: TRINIDAD-1691
 URL: https://issues.apache.org/jira/browse/TRINIDAD-1691
 Project: MyFaces Trinidad
  Issue Type: New Feature
  Components: Skinning
Reporter: Matt Cooper


UI designers periodically create new UI designs for various components with the 
goal of these designs being applied to a specific skin.  Although the visual 
design might be completely new for a given component, it is really meant to be 
available in context of other existing component designs of the same existing 
skin.

UI changes like this are sometimes considered to jarring for some customers and 
they would rather stick with the original designs.  This means that skins are 
eternally frozen after their first release so any new changes would need to be 
made in a new skin even though that new skin might be 75% identical to the 
original skin.

There is also a negative impact on customers that generate their own skin 
definitions when we introduce a new skin name.  Every skin (or skin addition) 
that they have created won't be able to uptake the new designs unless they 
physically go in and change all references from the old skin name to whatever 
the new skin's name is.  To remedy this while enabling the frozen state of 
the original designs, the skinning framework must support a concept of 
versioning.  Since the nature of software means that code lines branch into a 
vast tree structure, the version numbers of the skinning framework must fulfill 
this need.  A simple x.y will not be sufficient, we will require 
x.y.z.a.b.c.d.e.f.g and so on where each . represents another code branch 
off of the previous code branch, e.g. there will likely be a version that looks 
like 1.1.12.4.

Customers will then need a configuration option where they can specify which 
version of the skin they want to use.  (Presumably near the same location where 
they specify which skin name they want to use.)

Business needs:
Some customers need new UI designs applied to existing skins but other 
customers need the skin to remain unchanged.  Versioning will allow customers 
to optionally buy-into the new UI designs while other customers can happily 
live with the past designs.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (TRINIDAD-1691) Skinning framework support for skin versioning

2010-01-20 Thread Matt Cooper (JIRA)

[
https://issues.apache.org/jira/browse/TRINIDAD-1691?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12803068#action_12803068
]

Matt Cooper commented on TRINIDAD-1691:
---

See a thread on this topic here:
http://markmail.org/thread/cxzae34pt45k4j4i

Skinning framework support for skin versioning
--

Key: TRINIDAD-1691
URL: https://issues.apache.org/jira/browse/TRINIDAD-1691
Project: MyFaces Trinidad
Issue Type: New Feature
Components: Skinning
Reporter: Matt Cooper

UI designers periodically create new UI designs for various components with
the goal of these designs being applied to a specific skin. Although the
visual design might be completely new for a given component, it is really
meant to be available in context of other existing component designs of the
same existing skin.
UI changes like this are sometimes considered to jarring for some customers
and they would rather stick with the original designs. This means that skins
are eternally frozen after their first release so any new changes would need
to be made in a new skin even though that new skin might be 75% identical to
the original skin.
There is also a negative impact on customers that generate their own skin
definitions when we introduce a new skin name. Every skin (or skin addition)
that they have created won't be able to uptake the new designs unless they
physically go in and change all references from the old skin name to whatever
the new skin's name is. To remedy this while enabling the frozen state of
the original designs, the skinning framework must support a concept of
versioning. Since the nature of software means that code lines branch into a
vast tree structure, the version numbers of the skinning framework must
fulfill this need. A simple x.y will not be sufficient, we will require
x.y.z.a.b.c.d.e.f.g and so on where each . represents another code branch
off of the previous code branch, e.g. there will likely be a version that
looks like 1.1.12.4.
Customers will then need a configuration option where they can specify which
version of the skin they want to use. (Presumably near the same location
where they specify which skin name they want to use.)
Business needs:
Some customers need new UI designs applied to existing skins but other
customers need the skin to remain unchanged. Versioning will allow customers
to optionally buy-into the new UI designs while other customers can happily
live with the past designs.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (TRINIDAD-885) Provide selector to show navigation bar on bottom of table

2009-12-10 Thread Matt Cooper (JIRA)


[ 
https://issues.apache.org/jira/browse/TRINIDAD-885?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12789038#action_12789038
 ] 

Matt Cooper commented on TRINIDAD-885:
--

Though, perhaps it might not be used, it looks like the new key name is is:

af|table { -tr-repeat-control-bar: true; }

According to 
org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.SkinProperties.java

 Provide selector to show navigation bar on bottom of table 
 ---

 Key: TRINIDAD-885
 URL: https://issues.apache.org/jira/browse/TRINIDAD-885
 Project: MyFaces Trinidad
  Issue Type: Wish
Reporter: Frank Nimphius
Priority: Minor

 In ADF Faces there exist a selector -ora-repeat-control-bar that could be 
 used to show the table navigation bar on top and at the bottom of the table 
 (instead of on top only)
 af|table{ -ora-repeat-control-bar: true; } 
 A comparable selector is missing in Trinidad, which may become a problem fro 
 ADF Faces customers that migrate to Trinidad in JDeveloper 11. For a smooth 
 migration from ADF Faces to Trinidad it is highly desirable to have this 
 selector added to Trinidad

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Issue Comment Edited: (TRINIDAD-885) Provide selector to show navigation bar on bottom of table

2009-12-10 Thread Matt Cooper (JIRA)


[ 
https://issues.apache.org/jira/browse/TRINIDAD-885?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12789038#action_12789038
 ] 

Matt Cooper edited comment on TRINIDAD-885 at 12/11/09 12:07 AM:
-

Though, perhaps it might not be used, it looks like the new key name is:

af|table { -tr-repeat-control-bar: true; }

According to 
org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.SkinProperties.java

  was (Author: mattcooper):
Though, perhaps it might not be used, it looks like the new key name is is:

af|table { -tr-repeat-control-bar: true; }

According to 
org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.SkinProperties.java
  
 Provide selector to show navigation bar on bottom of table 
 ---

 Key: TRINIDAD-885
 URL: https://issues.apache.org/jira/browse/TRINIDAD-885
 Project: MyFaces Trinidad
  Issue Type: Wish
Reporter: Frank Nimphius
Priority: Minor

 In ADF Faces there exist a selector -ora-repeat-control-bar that could be 
 used to show the table navigation bar on top and at the bottom of the table 
 (instead of on top only)
 af|table{ -ora-repeat-control-bar: true; } 
 A comparable selector is missing in Trinidad, which may become a problem fro 
 ADF Faces customers that migrate to Trinidad in JDeveloper 11. For a smooth 
 migration from ADF Faces to Trinidad it is highly desirable to have this 
 selector added to Trinidad

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (TRINIDAD-1516) Add JSR-276 design time contract metadata for the trh:tableLayout component and its children

2009-06-22 Thread Matt Cooper (JIRA)

Add JSR-276 design time contract metadata for the trh:tableLayout component and 
its children


 Key: TRINIDAD-1516
 URL: https://issues.apache.org/jira/browse/TRINIDAD-1516
 Project: MyFaces Trinidad
  Issue Type: Improvement
  Components: Build
Affects Versions:  1.2.11-core
Reporter: Matt Cooper
Priority: Minor


Add JSR-276 design time contract metadata for the trh:tableLayout component and 
its children:
https://jsf-metadata-spec-public.dev.java.net/source/browse/*checkout*/jsf-metadata-spec-public/proposals/proposed-metadata-items.html

The trh:tableLayout tag is a required ancestor for trh:rowLayout components.
The trh:rowLayout tag is a required ancestor for trh:cellFormat components.

To improve the design time experience for these components, we should add the 
metadata that will help ensure the hierarchical ancestry contracts are 
satisfied.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Resolved: (TRINIDAD-1516) Add JSR-276 design time contract metadata for the trh:tableLayout component and its children

2009-06-22 Thread Matt Cooper (JIRA)


 [ 
https://issues.apache.org/jira/browse/TRINIDAD-1516?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Matt Cooper resolved TRINIDAD-1516.
---

   Resolution: Fixed
Fix Version/s:  1.2.12-core

 Add JSR-276 design time contract metadata for the trh:tableLayout component 
 and its children
 

 Key: TRINIDAD-1516
 URL: https://issues.apache.org/jira/browse/TRINIDAD-1516
 Project: MyFaces Trinidad
  Issue Type: Improvement
  Components: Build
Affects Versions:  1.2.11-core
Reporter: Matt Cooper
Assignee: Matt Cooper
Priority: Minor
 Fix For:  1.2.12-core


 Add JSR-276 design time contract metadata for the trh:tableLayout component 
 and its children:
 https://jsf-metadata-spec-public.dev.java.net/source/browse/*checkout*/jsf-metadata-spec-public/proposals/proposed-metadata-items.html
 The trh:tableLayout tag is a required ancestor for trh:rowLayout components.
 The trh:rowLayout tag is a required ancestor for trh:cellFormat components.
 To improve the design time experience for these components, we should add the 
 metadata that will help ensure the hierarchical ancestry contracts are 
 satisfied.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (TRINIDAD-1506) ClassCastException during surefire tests when calling ExternalContextUtils.getServletContextPath()

2009-06-16 Thread Matt Cooper (JIRA)


[ 
https://issues.apache.org/jira/browse/TRINIDAD-1506?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12720166#action_12720166
 ] 

Matt Cooper commented on TRINIDAD-1506:
---

Sure, here's a sample stack trace for this issue:

java.lang.ClassCastException: 
org.apache.myfaces.trinidadinternal.renderkit.MApplication cannot be cast to 
javax.servlet.ServletContext
at 
org.apache.myfaces.trinidad.util.ExternalContextUtils.getServletContextPath(ExternalContextUtils.java:193)
at 
custom.MyRenderer._someMethodThatCallsGetServletContextPathOnExternalContextUtils(MyRenderer.java:1110)
at custom.MyRenderer.encodeAll(MyRenderer.java:69)
at 
org.apache.myfaces.trinidad.render.CoreRenderer.encodeEnd(CoreRenderer.java:335)
at 
org.apache.myfaces.trinidad.component.UIXComponentBase.encodeEnd(UIXComponentBase.java:751)
at 
org.apache.myfaces.trinidad.render.RenderUtils.encodeRecursive(RenderUtils.java:70)
at 
org.apache.myfaces.trinidad.render.RenderUtils.encodeRecursive(RenderUtils.java:65)
at 
org.apache.myfaces.trinidadinternal.renderkit.RenderUtils.encodeRecursive(RenderUtils.java:47)
at 
org.apache.myfaces.trinidadinternal.renderkit.RenderKitTestCase$BaseTest.renderRoot(RenderKitTestCase.java:213)
at 
custom.MyRenderKitTest$ClientComponentTest.runTest(MyRenderKitTest.java:282)
at junit.framework.TestCase.runBare(TestCase.java:127)
at junit.framework.TestResult$1.protect(TestResult.java:106)
at junit.framework.TestResult.runProtected(TestResult.java:124)
at junit.framework.TestResult.run(TestResult.java:109)
at junit.framework.TestCase.run(TestCase.java:118)
at 
org.apache.myfaces.trinidadinternal.renderkit.RenderKitTestCase$BaseTest.run(RenderKitTestCase.java:143)
at junit.framework.TestSuite.runTest(TestSuite.java:208)
at junit.framework.TestSuite.run(TestSuite.java:203)
at 
org.apache.myfaces.trinidadinternal.renderkit.RenderKitTestCase.run(RenderKitTestCase.java:92)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at 
org.apache.maven.surefire.junit.JUnitTestSet.execute(JUnitTestSet.java:213)
at 
org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:138)
at 
org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:125)
at org.apache.maven.surefire.Surefire.run(Surefire.java:132)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at 
org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:290)
at 
org.apache.maven.surefire.booter.SurefireBooter.run(SurefireBooter.java:198)
at 
org.apache.maven.plugin.surefire.SurefirePlugin.execute(SurefirePlugin.java:398)
at 
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:451)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:558)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:499)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:478)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:330)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:291)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:142)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:336)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:129)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:287)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
at

[jira] Created: (TRINIDAD-1506) ClassCastException during surefire tests when calling ExternalContextUtils.getServletContextPath()

2009-06-15 Thread Matt Cooper (JIRA)

ClassCastException during surefire tests when calling 
ExternalContextUtils.getServletContextPath()
--

 Key: TRINIDAD-1506
 URL: https://issues.apache.org/jira/browse/TRINIDAD-1506
 Project: MyFaces Trinidad
  Issue Type: Bug
Affects Versions:  1.2.11-core
Reporter: Matt Cooper
Priority: Minor


If you have a renderer that makes a call like this:

ExternalContextUtils.getServletContextPath(context.getExternalContext());

Then, when running a surefire test for a component that uses such a renderer, a 
ClassCastException will be thrown where some underlying code is expecting a 
javax.servlet.ServletContext however, a 
org.apache.myfaces.trinidadinternal.renderkit.MApplication is provided instead. 
 Perhaps MApplication needs to implement/extend ServletContext or otherwise 
ExternalContextUtils.getServletContextPath() needs to return a dummy value when 
running surefire tests.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (TRINIDAD-1496) Need org.apache.myfaces.trinidad.skin.Icon to expose the raw content value instead of just getImageURI

2009-06-01 Thread Matt Cooper (JIRA)

Need org.apache.myfaces.trinidad.skin.Icon to expose the raw content value 
instead of just getImageURI
--

 Key: TRINIDAD-1496
 URL: https://issues.apache.org/jira/browse/TRINIDAD-1496
 Project: MyFaces Trinidad
  Issue Type: New Feature
  Components: Components
Affects Versions:  1.2.11-core
Reporter: Matt Cooper
Priority: Minor


In skinning, you can define image icons in 4 different ways:

1.) Absolute URLs specify the complete URL to the resource, including the 
protocol (e.g. http://). Example:
content: url(http://incubator.apache.org/images/asf_logo_wide.gif);

2.) Relative URLs are used if the specified URL does not start with a slash 
(/) and if there's no protocol present. A relative URL is based on the skin's 
CSS file location. For instance, if the CSS is located in 
MyWebApp/skins/mySkin/ and the specified url is skinImages/myImage.gif, then 
the final URL will be /MyWebApp/skins/mySkin/skinImages/myImage.gif. Example:
content: url(skin_images/ObjectIconError.gif);

3.) Context relative URLs are resolved relatively to the context root of the 
web application. To use them, you simply have to make it start with a single 
slash (/). For instance, if the context root is /MyWebApp and the specified 
URL is /images/myImage.jpeg, the resulting URL will be 
/MyWebApp/images/myImage.jpeg. Example:
content: url(/skins/mySkin/skin_images/ObjectIconError.gif);

4.) Server relative URLs are resolved relatively to the web server as opposed 
to the context root. This allow to easily refer to resources located on another 
application on the same server. To use this type of URL, the specified URL must 
starts with two slashes (//). Example:
content: url(//MyOtherWebApp/images/myCalendar.gif);

The org.apache.myfaces.trinidad.skin.Icon class currently provides a 
getImageURI() method.  This method returns a value that has the context path 
built-in.  If a component exposes an icon attribute (there are a handful in 
Apache MyFaces Trinidad and also in another framework that has components built 
upon Trinidad), that icon String supports these same alternative mechanisms for 
referring to the icon image.  Let's say you have a component that you want to 
keep abstract but might want it to reuse existing components (e.g. a rich text 
editor with a toolbar containing buttons that you want to reuse an existing 
toolbar button component so you can have consistency in button styling).  For 
that publicly-exposed component, you will want to allow people to customize in 
skinning what the icons are for its toolbar.  These icons must be defined in 
that publicly-exposed component but then converted into a String that can be 
passed into the toolbar button component.  With the current Icon.getImageURI(), 
if a user skinned the icon image using some of the 4 above paths, either the 
icon would have 2 context paths added to it (one from the skin framework and 
one from the toolbar button resource encoding) or it would have a context path 
when it should not be including the local context path (image definition option 
#4).  For the public component's renderer to support all 4 of these image 
definition options, the org.apache.myfaces.trinidad.skin.Icon needs to expose 
some mechanism to either let it have access to the raw content value so that 
raw value can be passed along to the button or at least some kind of mechanism 
to let the public component's renderer know that it is not safe to let the 
button add its own copy of the context path (e.g. add another leading / to 
the result).

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (TRINIDAD-1350) iPod Safari not identified as iPhone as intended in documentation

2008-12-16 Thread Matt Cooper (JIRA)

iPod Safari not identified as iPhone as intended in documentation
---

 Key: TRINIDAD-1350
 URL: https://issues.apache.org/jira/browse/TRINIDAD-1350
 Project: MyFaces Trinidad
  Issue Type: Bug
  Components: Skinning
Reporter: Matt Cooper
Assignee: Matt Cooper


The iPod version of Safari is not being identified as platform=iphone as is 
intended in the documentation for AgentFactoryImpl.java:
At the moment, all known iPhone and iPod touch agent strings contain iPhone 
-- not true, e.g.:
Mozila/5.0 (iPod; U; CPU like Mac OS X; en) AppleWebKit/420.1 (KHTML, like 
Geckto) Version/3.0 Mobile/3A101a Safari/419.3

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Resolved: (TRINIDAD-1350) iPod Safari not identified as iPhone as intended in documentation

2008-12-16 Thread Matt Cooper (JIRA)


 [ 
https://issues.apache.org/jira/browse/TRINIDAD-1350?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Matt Cooper resolved TRINIDAD-1350.
---

   Resolution: Fixed
Fix Version/s:  1.2.11-core
1.0.11-core

 iPod Safari not identified as iPhone as intended in documentation
 ---

 Key: TRINIDAD-1350
 URL: https://issues.apache.org/jira/browse/TRINIDAD-1350
 Project: MyFaces Trinidad
  Issue Type: Bug
  Components: Skinning
Reporter: Matt Cooper
Assignee: Matt Cooper
 Fix For:  1.0.11-core,  1.2.11-core


 The iPod version of Safari is not being identified as platform=iphone as is 
 intended in the documentation for AgentFactoryImpl.java:
 At the moment, all known iPhone and iPod touch agent strings contain iPhone 
 -- not true, e.g.:
 Mozila/5.0 (iPod; U; CPU like Mac OS X; en) AppleWebKit/420.1 (KHTML, like 
 Gecko) Version/3.0 Mobile/3A101a Safari/419.3

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (TRINIDAD-1297) select element is sensitive to white space and is impacted by IndentingResponseWriter

2008-11-10 Thread Matt Cooper (JIRA)

select element is sensitive to white space and is impacted by 
IndentingResponseWriter
-

 Key: TRINIDAD-1297
 URL: https://issues.apache.org/jira/browse/TRINIDAD-1297
 Project: MyFaces Trinidad
  Issue Type: Bug
  Components: Components
Affects Versions: 1.2.9-core, 1.0.9-core
Reporter: Matt Cooper
Assignee: Matt Cooper
Priority: Trivial


The select element is sensitive to white space and is impacted by 
IndentingResponseWriter.  It should be added to the list of 
white-space-sensitive elements.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Resolved: (TRINIDAD-1297) select element is sensitive to white space and is impacted by IndentingResponseWriter

2008-11-10 Thread Matt Cooper (JIRA)


 [ 
https://issues.apache.org/jira/browse/TRINIDAD-1297?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Matt Cooper resolved TRINIDAD-1297.
---

   Resolution: Fixed
Fix Version/s: 1.0.10-core
   1.2.10-core

 select element is sensitive to white space and is impacted by 
 IndentingResponseWriter
 -

 Key: TRINIDAD-1297
 URL: https://issues.apache.org/jira/browse/TRINIDAD-1297
 Project: MyFaces Trinidad
  Issue Type: Bug
  Components: Components
Affects Versions: 1.0.9-core, 1.2.9-core
Reporter: Matt Cooper
Assignee: Matt Cooper
Priority: Trivial
 Fix For: 1.2.10-core, 1.0.10-core


 The select element is sensitive to white space and is impacted by 
 IndentingResponseWriter.  It should be added to the list of 
 white-space-sensitive elements.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (TRINIDAD-1271) WebKit Agent Uses Incorrect Platform on non-Mac and non-iPhone platforms

2008-10-17 Thread Matt Cooper (JIRA)

WebKit Agent Uses Incorrect Platform on non-Mac and non-iPhone platforms


 Key: TRINIDAD-1271
 URL: https://issues.apache.org/jira/browse/TRINIDAD-1271
 Project: MyFaces Trinidad
  Issue Type: Bug
  Components: Components
Affects Versions: 1.2.9-core, 1.0.9-core,  1.2.8-core, 1.2.10-core, 
1.0.10-core
Reporter: Matt Cooper
Assignee: Matt Cooper
Priority: Minor


There are WebKit implementations (e.g. Safari, Android, Google Chrome) for 
platforms like Windows and Linux but currently the Agent in Trinidad declares 
them incorrectly as using the Mac platform.  The proper platform should be 
indicated instead.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Resolved: (TRINIDAD-1271) WebKit Agent Uses Incorrect Platform on non-Mac and non-iPhone platforms

2008-10-17 Thread Matt Cooper (JIRA)


 [ 
https://issues.apache.org/jira/browse/TRINIDAD-1271?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Matt Cooper resolved TRINIDAD-1271.
---

   Resolution: Fixed
Fix Version/s: 1.0.10-core
   1.2.10-core

 WebKit Agent Uses Incorrect Platform on non-Mac and non-iPhone platforms
 

 Key: TRINIDAD-1271
 URL: https://issues.apache.org/jira/browse/TRINIDAD-1271
 Project: MyFaces Trinidad
  Issue Type: Bug
  Components: Components
Affects Versions: 1.0.9-core, 1.2.9-core, 1.2.10-core, 1.0.10-core
Reporter: Matt Cooper
Assignee: Matt Cooper
Priority: Minor
 Fix For: 1.2.10-core, 1.0.10-core


 There are WebKit implementations (e.g. Safari, Android, Google Chrome) for 
 platforms like Windows and Linux but currently the Agent in Trinidad declares 
 them incorrectly as using the Mac platform.  The proper platform should be 
 indicated instead.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (TRINIDAD-1267) Viewport setting is needed for Mobile Safari browsers such as iPhone, BlackBerry Bold and Storm Browsers

2008-10-16 Thread Matt Cooper (JIRA)


[ 
https://issues.apache.org/jira/browse/TRINIDAD-1267?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12640321#action_12640321
 ] 

Matt Cooper commented on TRINIDAD-1267:
---

I believe this is a dangerous change because it will cause all pages to use a 
hard-coded scale factor and prevent user scaling of the page.

Instead, for the pages that want to use such a meta tag, those pages should 
insert the meta tag into the metaContainer facet of the af:document on just 
those specific pages:
http://myfaces.apache.org/trinidad/trinidad-1_2/trinidad-api/tagdoc/tr_document.html

 Viewport setting is needed for Mobile Safari browsers such as iPhone, 
 BlackBerry Bold and Storm Browsers
 

 Key: TRINIDAD-1267
 URL: https://issues.apache.org/jira/browse/TRINIDAD-1267
 Project: MyFaces Trinidad
  Issue Type: New Feature
  Components: Components
Affects Versions: 1.2.9-core
 Environment: Mobile Safari browsers such as iPhone, BlackBerry Bold 
 and Storm Browsers
Reporter: Tadashi Enomori
Priority: Minor
 Attachments: TRINIDAD-1267.patch


 In order to display a page in correct zoom ratio, it is necessary to add a 
 viewport meta tag in the header.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (TRINIDAD-1238) Allow children of iterator to use partialTriggers

2008-09-22 Thread Matt Cooper (JIRA)

Allow children of iterator to use partialTriggers
-

 Key: TRINIDAD-1238
 URL: https://issues.apache.org/jira/browse/TRINIDAD-1238
 Project: MyFaces Trinidad
  Issue Type: New Feature
  Components: Components
Affects Versions: 1.2.9-core, 1.0.9-core
Reporter: Matt Cooper


Today, if you have an iterator that stamps out components, these components 
cannot have partialTriggers where, for example, a specified button would not 
cause the component to be PPRed when clicked.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (TRINIDAD-1238) Allow children of iterator to use partialTriggers

2008-09-22 Thread Matt Cooper (JIRA)


[ 
https://issues.apache.org/jira/browse/TRINIDAD-1238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12633571#action_12633571
 ] 

Matt Cooper commented on TRINIDAD-1238:
---

In the test page, the desired effect is that the time stamp on the inputText 
whose id=stamped-but-not-switched would be updated when the user clicks on 
the commandButton whose id=externalButton.

 Allow children of iterator to use partialTriggers
 -

 Key: TRINIDAD-1238
 URL: https://issues.apache.org/jira/browse/TRINIDAD-1238
 Project: MyFaces Trinidad
  Issue Type: New Feature
  Components: Components
Affects Versions: 1.0.9-core, 1.2.9-core
Reporter: Matt Cooper
 Attachments: test.jspx, testCase.diff


 Today, if you have an iterator that stamps out components, these components 
 cannot have partialTriggers where, for example, a specified button would not 
 cause the component to be PPRed when clicked.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (TRINIDAD-1232) Agent support for iPhone

2008-09-17 Thread Matt Cooper (JIRA)


 [ 
https://issues.apache.org/jira/browse/TRINIDAD-1232?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Matt Cooper updated TRINIDAD-1232:
--

   Resolution: Fixed
Fix Version/s: 1.0.10-core
   1.2.10-core
   Status: Resolved  (was: Patch Available)

 Agent support for iPhone
 

 Key: TRINIDAD-1232
 URL: https://issues.apache.org/jira/browse/TRINIDAD-1232
 Project: MyFaces Trinidad
  Issue Type: Improvement
  Components: Archetype
Affects Versions: 1.2.9-core
Reporter: Andy Schwartz
Assignee: Matt Cooper
Priority: Minor
 Fix For: 1.2.10-core, 1.0.10-core

 Attachments: TRINIDAD-1232-trunk_1.2.x.patch


 Currently the Trinidad Agent code does not distinguish between Safari running 
 on iPhone vs. Safari running on desktop.  Since there are subtle differences 
 between these two agents, the Trinidad Agent implementation should be able to 
 identify each case.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (TRINIDAD-1155) Tree initiallyExpanded=true attribute leaves a dangling currency

2008-07-14 Thread Matt Cooper (JIRA)


 [ 
https://issues.apache.org/jira/browse/TRINIDAD-1155?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Matt Cooper updated TRINIDAD-1155:
--

   Resolution: Fixed
Fix Version/s: 1.2.9-core
   1.0.9-core
   Status: Resolved  (was: Patch Available)

 Tree initiallyExpanded=true attribute leaves a dangling currency
 --

 Key: TRINIDAD-1155
 URL: https://issues.apache.org/jira/browse/TRINIDAD-1155
 Project: MyFaces Trinidad
  Issue Type: Bug
Affects Versions:  1.2.8-core, 1.2.9-core
Reporter: Venkata Guddanti
 Fix For: 1.0.9-core, 1.2.9-core

 Attachments: trunk.patch


 If initiallyExpanded=true attribute is set on the tree, it leaves a 
 dangling currency pointing to the first row. This causes unexpected results 
 since the clientId of the tree now contains 0 (currency of the first row). 
 The fix is to make sure that after the first rowKey is expanded in the tree, 
 we restore the currency to the initial value.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (TRINIDAD-1153) Creating JPRs through maven's jdev:jdev on the 1.2.x trunk uses config for both RI and MyFaces libraries

2008-07-10 Thread Matt Cooper (JIRA)

Creating JPRs through maven's jdev:jdev on the 1.2.x trunk uses config for both 
RI and MyFaces libraries


 Key: TRINIDAD-1153
 URL: https://issues.apache.org/jira/browse/TRINIDAD-1153
 Project: MyFaces Trinidad
  Issue Type: Bug
  Components: Build
Affects Versions:  1.2.8-core
Reporter: Matt Cooper
Assignee: Scott O'Bryan
Priority: Minor


Creating JPRs through maven's jdev:jdev on the 1.2.x trunk uses config for both 
RI and MyFaces libraries.
The trinidad-blank project's web.xml ends up using the listener 
org.apache.myfaces.webapp.StartupServletContextListener when you set -Djsf=ri 
but the class cannot be found when running the project.
The trinidad-demo project has library entries for both the RI and for MyFaces.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (TRINIDAD-1128) Safari support in FileDownloadActionListener

2008-06-19 Thread Matt Cooper (JIRA)


 [ 
https://issues.apache.org/jira/browse/TRINIDAD-1128?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Matt Cooper updated TRINIDAD-1128:
--

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

 Safari support in FileDownloadActionListener
 

 Key: TRINIDAD-1128
 URL: https://issues.apache.org/jira/browse/TRINIDAD-1128
 Project: MyFaces Trinidad
  Issue Type: Improvement
  Components: Components
Affects Versions:  1.0.8-core,  1.2.8-core
 Environment: All
Reporter: Kamran Kashanian
Assignee: Matt Cooper
 Fix For: 1.0.9-core, 1.2.9-core

 Attachments: filedownload.1.2.x, filedownload.trunk


 FileDownLoadActionListener needs to use UTF-8 encoding for file names in 
 Safari. Attaching 1.2.x and trunk patches.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Resolved: (TRINIDAD-1120) HtmlResponseWriter should treat embed as an empty element

2008-06-16 Thread Matt Cooper (JIRA)


 [ 
https://issues.apache.org/jira/browse/TRINIDAD-1120?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Matt Cooper resolved TRINIDAD-1120.
---

   Resolution: Fixed
Fix Version/s: 1.2.9-core
   1.0.9-core

 HtmlResponseWriter should treat embed as an empty element
 -

 Key: TRINIDAD-1120
 URL: https://issues.apache.org/jira/browse/TRINIDAD-1120
 Project: MyFaces Trinidad
  Issue Type: Bug
  Components: Components
Affects Versions:  1.0.8-core,  1.2.8-core
Reporter: Matt Cooper
Assignee: Matt Cooper
Priority: Minor
 Fix For: 1.0.9-core, 1.2.9-core


 The HtmlResponseWriter has a list of element names that should have no body.  
 The embed element is not listed so when you encode an embed, it 
 improperly gets a closing tag.
 For more info on the embed element:
 http://www.w3.org/html/wg/html5/#the-embed

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (TRINIDAD-1120) HtmlResponseWriter should treat embed as an empty element

2008-06-13 Thread Matt Cooper (JIRA)

HtmlResponseWriter should treat embed as an empty element
-

 Key: TRINIDAD-1120
 URL: https://issues.apache.org/jira/browse/TRINIDAD-1120
 Project: MyFaces Trinidad
  Issue Type: Bug
  Components: Components
Affects Versions:  1.2.8-core
Reporter: Matt Cooper
Assignee: Matt Cooper
Priority: Minor
 Fix For: 1.2.7-plugins


The HtmlResponseWriter has a list of element names that should have no body.  
The embed element is not listed so when you encode an embed, it improperly 
gets a closing tag.

For more info on the embed element:
http://www.w3.org/html/wg/html5/#the-embed

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (TRINIDAD-1100) TrDateRestrictionValidator is creating messages with incorrect punctuation

2008-05-29 Thread Matt Cooper (JIRA)


 [ 
https://issues.apache.org/jira/browse/TRINIDAD-1100?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Matt Cooper updated TRINIDAD-1100:
--

   Resolution: Fixed
Fix Version/s: 1.2.9-core
   1.0.9-core
   Status: Resolved  (was: Patch Available)

Fixed in trunk_1.2.x in SVN revision 661396.
Fixed in 1.2.8.1-branch in SVN revision 661397.
Fixed in trunk in SVN revision 661399.

 TrDateRestrictionValidator is creating messages with incorrect punctuation
 --

 Key: TRINIDAD-1100
 URL: https://issues.apache.org/jira/browse/TRINIDAD-1100
 Project: MyFaces Trinidad
  Issue Type: Bug
  Components: Components
Affects Versions:  1.2.8-core, 1.2.9-core
Reporter: Gary VanMatre
Assignee: Matt Cooper
Priority: Minor
 Fix For: 1.0.9-core, 1.2.9-core

 Attachments: CoreFormat.patch


 The JS TrDateRestrictionValidator should be delimiting parameterized value 
 lists with a comma and a space.  The current script uses the standard JS 
 toString that only delimits lists using a comma.  
 For example: 
 Enter a date from the following month(s): 
 January,February,March,April,May,September,October,November,December.
 Besides being incorrect punctuation, the lacking breakable spaces plays havoc 
 with normal html text wrapping.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Resolved: (TRINIDAD-986) EXTERNAL DIALOG FAILING TO RESIZE TO CONTENT

2008-05-15 Thread Matt Cooper (JIRA)


 [ 
https://issues.apache.org/jira/browse/TRINIDAD-986?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Matt Cooper resolved TRINIDAD-986.
--

   Resolution: Fixed
Fix Version/s: (was: 1.2.7-core)
   (was: 1.0.7-core)
1.2.8-core

 EXTERNAL DIALOG FAILING TO RESIZE TO CONTENT
 

 Key: TRINIDAD-986
 URL: https://issues.apache.org/jira/browse/TRINIDAD-986
 Project: MyFaces Trinidad
  Issue Type: Bug
  Components: Components
Affects Versions: 1.2.6-core
 Environment: Win32 FireFox
Reporter: Gary VanMatre
Assignee: Matt Cooper
 Fix For:  1.2.8-core

 Attachments: Window.patch


 External Trinidad dialog windows are resized to content using the offsets 
 of the internal frame.  The script _sizeWin as part of the Trinidad commons 
 script resource bundling is failing to calculate the actual size of the inner 
 content frame.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (TRINIDAD-1) Add @agent support for skin properties

2008-04-15 Thread Matt Cooper (JIRA)


[ 
https://issues.apache.org/jira/browse/TRINIDAD-1?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12589259#action_12589259
 ] 

Matt Cooper commented on TRINIDAD-1:


I would like to see this supported on all @-rules, not just @agent.

 Add @agent support for skin properties
 --

 Key: TRINIDAD-1
 URL: https://issues.apache.org/jira/browse/TRINIDAD-1
 Project: MyFaces Trinidad
  Issue Type: Improvement
  Components: Skinning
Reporter: Matt Cooper

 We have @agent support for skin selectors where style entries that appear in 
 the client-side generated CSS file, but not for skin properties (which are 
 only present in the server-side skin).
 It would be useful to have different property values for ie than for gecko.
 af|someComponent {
   -tr-my-property: my-default-value;
 }
 @agent ie {
   af|someComponent {
 -tr-my-property: my-ie-value;
   }
 }
 What we have to do now is introduce properties with agent-specific names and 
 reference them by agent name:
 af|someComponent {
   -tr-my-property: my-default-value;
   -tr-my-property-for-ie: my-ie-value;
 }
 and then in the Renderer look up the value by name accordion to what agent is 
 currently in use.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Issue Comment Edited: (TRINIDAD-1) Add @agent support for skin properties

2008-04-15 Thread Matt Cooper (JIRA)


[ 
https://issues.apache.org/jira/browse/TRINIDAD-1?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12589259#action_12589259
 ] 

mattcooper edited comment on TRINIDAD-1 at 4/15/08 3:17 PM:
-

I would like to see this supported on all Trindad @-rules, not just @agent.  
For example, @accessibility-profile large-fonts {}.

  was (Author: mattcooper):
I would like to see this supported on all @-rules, not just @agent.
  
 Add @agent support for skin properties
 --

 Key: TRINIDAD-1
 URL: https://issues.apache.org/jira/browse/TRINIDAD-1
 Project: MyFaces Trinidad
  Issue Type: Improvement
  Components: Skinning
Reporter: Matt Cooper

 We have @agent support for skin selectors where style entries that appear in 
 the client-side generated CSS file, but not for skin properties (which are 
 only present in the server-side skin).
 It would be useful to have different property values for ie than for gecko.
 af|someComponent {
   -tr-my-property: my-default-value;
 }
 @agent ie {
   af|someComponent {
 -tr-my-property: my-ie-value;
   }
 }
 What we have to do now is introduce properties with agent-specific names and 
 reference them by agent name:
 af|someComponent {
   -tr-my-property: my-default-value;
   -tr-my-property-for-ie: my-ie-value;
 }
 and then in the Renderer look up the value by name accordion to what agent is 
 currently in use.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (TRINIDAD-822) Add additional accessibility features to skinning

2008-04-02 Thread Matt Cooper (JIRA)


 [ 
https://issues.apache.org/jira/browse/TRINIDAD-822?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Matt Cooper updated TRINIDAD-822:
-

   Resolution: Fixed
Fix Version/s:  1.2.8-core
1.0.8-core
   Status: Resolved  (was: Patch Available)

 Add additional accessibility features to skinning
 -

 Key: TRINIDAD-822
 URL: https://issues.apache.org/jira/browse/TRINIDAD-822
 Project: MyFaces Trinidad
  Issue Type: Improvement
  Components: Skinning
Affects Versions: 1.0.5-core, 1.2.4-core
Reporter: Matt Cooper
Assignee: Matt Cooper
 Fix For:  1.0.8-core,  1.2.8-core

 Attachments: TRINIDAD-822-1.2.x.patch, TRINIDAD-822-trunk.patch


 It is important to be able to define skin settings based on accessibility 
 policies such as:
 @accessibility-policy [low-vision, any-vision, high-contrast, any-contrast, 
 keyboard, mouse, touch]
 If this is added then a corresponding accessibility-policy property/object 
 for trinidad-config.xml would be needed.  There is an existing 
 accessibility-mode property/object available today so we may want to 
 incorporate that or otherwise deprecate it if it is not possible to use it to 
 enumerate all of the possible combinations of the above noted policies.
 Basically people should be able to define skin properties specific to 
 accessibility needs.  In the past the answer was to create a separate skin 
 for each need but it is becoming apparent that this is not ideal.  Take this 
 scenario for example:
 The Apache MyFaces Trinidad community has spent a lot of effort working on a 
 skin that meets all of the accessibility requirements of their customers.  
 You're a random customer of Trinidad, working on making an app for your own 
 organization and don't have the resources or expertise to make a skin that 
 meets the same needs on your own.  You are happy with most of what the 
 default skin provides but you really just want to make some minor color, 
 image, and font changes to match your organization's branding.  You really 
 just want to extend the provided skin and don't want to risk breaking 
 accessibility needs.  If you change the base styles, you'll be responsible 
 for coming up with low-vision, high-contrast styles too.  If you could 
 somehow just change the styles that won't impact the special needs users then 
 you can make your skin extension with much less effort--the any-contrast 
 and any-vision @accessibility-policy would enable you to do this.  Or the 
 inverse if some third party created a skin but you needed to make some tweaks 
 for high-contrast, low-vision, or touch-based entry users, etc.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (TRINIDAD-979) Create a new professional looking skin based on the MyFaces Logo proposed designs

2008-03-24 Thread Matt Cooper (JIRA)


[ 
https://issues.apache.org/jira/browse/TRINIDAD-979?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12581587#action_12581587
 ] 

Matt Cooper commented on TRINIDAD-979:
--

Note that the web page looks different now than what was uploaded to this issue 
earlier.

See http://myfaces.apache.org/core11/index.html for the latest version of the 
design.

 Create a new professional looking skin based on the MyFaces Logo proposed 
 designs
 -

 Key: TRINIDAD-979
 URL: https://issues.apache.org/jira/browse/TRINIDAD-979
 Project: MyFaces Trinidad
  Issue Type: Improvement
  Components: Skinning
Affects Versions: 1.2.6-core
Reporter: Andrew Robinson
Assignee: Andrew Robinson
 Attachments: webpage.png


 Trinidad doesn't have a professional looking skin. This makes people 
 reluctant to adopt this technology.
 I would like to start a new skin that will provide a quality look to Trinidad 
 compatible with at least IE7 and Firefox 2 based on the proposed web site 
 design by Adonis Raduca (see attached image)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (TRINIDAD-979) Create a new professional looking skin based on the MyFaces Logo proposed designs

2008-03-24 Thread Matt Cooper (JIRA)


[ 
https://issues.apache.org/jira/browse/TRINIDAD-979?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12581599#action_12581599
 ] 

Matt Cooper commented on TRINIDAD-979:
--

Andrew also has a wiki page to track this enhancement:
http://wiki.apache.org/myfaces/Trinidad_MyFaces_Skin_and_Demo_rewrite

 Create a new professional looking skin based on the MyFaces Logo proposed 
 designs
 -

 Key: TRINIDAD-979
 URL: https://issues.apache.org/jira/browse/TRINIDAD-979
 Project: MyFaces Trinidad
  Issue Type: Improvement
  Components: Skinning
Affects Versions: 1.2.6-core
Reporter: Andrew Robinson
Assignee: Andrew Robinson
 Attachments: webpage.png


 Trinidad doesn't have a professional looking skin. This makes people 
 reluctant to adopt this technology.
 I would like to start a new skin that will provide a quality look to Trinidad 
 compatible with at least IE7 and Firefox 2 based on the proposed web site 
 design by Adonis Raduca (see attached image)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (TRINIDAD-980) Recreate the Trinidad demo from the ground up

2008-03-24 Thread Matt Cooper (JIRA)


[ 
https://issues.apache.org/jira/browse/TRINIDAD-980?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12581600#action_12581600
 ] 

Matt Cooper commented on TRINIDAD-980:
--

Andrew is also tracking this in a wiki:
http://wiki.apache.org/myfaces/Trinidad_MyFaces_Skin_and_Demo_rewrite

 Recreate the Trinidad demo from the ground up
 -

 Key: TRINIDAD-980
 URL: https://issues.apache.org/jira/browse/TRINIDAD-980
 Project: MyFaces Trinidad
  Issue Type: Improvement
  Components: Components
Affects Versions: 1.2.6-core
Reporter: Andrew Robinson
Assignee: Andrew Robinson

 The current demo is more of a testing project. What I would like to do:
 1. Rename trinidad-demo to trinidad-test for developers to use as a feature 
 and component testing project
 2. Create a new trinidad-demo
 Goals:
 1. Showcase all components in a nice looking demo
 2. Default to showing the new skin proposed in 
 https://issues.apache.org/jira/browse/TRINIDAD-979
 3. Leverage Facelets 1.1.14 to build a template(s) for all component and 
 feature demo pages
 4. Provide a better example for users how to start making a more complex 
 Trinidad application
 5. Eat our own dog food by making the templates use Trinidad features

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (TRINIDAD-961) NON-FUNCTIONAL PARTIALTRIGGERS FOR TABLE COLUMN HEADER/FOOTER

2008-03-12 Thread Matt Cooper (JIRA)


 [ 
https://issues.apache.org/jira/browse/TRINIDAD-961?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Matt Cooper updated TRINIDAD-961:
-

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

1.2.8-core was not a listed unreleased version to select yet.  I believe the 
1.2.7-core release was already built so I don't believe I can mark this issue 
as resolved in that release.

 NON-FUNCTIONAL PARTIALTRIGGERS FOR TABLE COLUMN HEADER/FOOTER
 -

 Key: TRINIDAD-961
 URL: https://issues.apache.org/jira/browse/TRINIDAD-961
 Project: MyFaces Trinidad
  Issue Type: Bug
  Components: Components
Affects Versions: 1.2.6-core
 Environment: All
Reporter: Kamran Kashanian
Assignee: Matt Cooper
 Attachments: trinidad_1.2.x.patch


 If a UIComponent inside the table column header/footer contains a 
 partialTrigger referencing the component ID of a stamped component inside the 
 table. When the partialTrigger is invoked,  the client ID that gets added to 
 the partialTargets list  for the header/footer UIComponent includes the table 
 currency key. So the component inside the column header/footer is 
 incorrectly being treated as a stamped component. This prevents the update of 
 components inside table header/footer (as a result of changes in stamped 
 components in the table body) using partialTriggers. 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (TRINIDAD-986) EXTERNAL DIALOG FAILING TO RESIZE TO CONTENT

2008-03-04 Thread Matt Cooper (JIRA)


 [ 
https://issues.apache.org/jira/browse/TRINIDAD-986?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Matt Cooper updated TRINIDAD-986:
-

   Resolution: Fixed
Fix Version/s: (was: 1.2.6-core)
   1.2.7-core
   1.0.7-core
   Status: Resolved  (was: Patch Available)

 EXTERNAL DIALOG FAILING TO RESIZE TO CONTENT
 

 Key: TRINIDAD-986
 URL: https://issues.apache.org/jira/browse/TRINIDAD-986
 Project: MyFaces Trinidad
  Issue Type: Bug
  Components: Components
Affects Versions: 1.2.6-core
 Environment: Win32 FireFox
Reporter: Gary VanMatre
Assignee: Matt Cooper
 Fix For: 1.0.7-core, 1.2.7-core

 Attachments: Window.patch


 External Trinidad dialog windows are resized to content using the offsets 
 of the internal frame.  The script _sizeWin as part of the Trinidad commons 
 script resource bundling is failing to calculate the actual size of the inner 
 content frame.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (TRINIDAD-972) UIXIterator.processFlattenedChildren() and its underlying UIXCollection cache is not initialized or flushed properly

2008-02-26 Thread Matt Cooper (JIRA)

UIXIterator.processFlattenedChildren() and its underlying UIXCollection cache 
is not initialized or flushed properly


 Key: TRINIDAD-972
 URL: https://issues.apache.org/jira/browse/TRINIDAD-972
 Project: MyFaces Trinidad
  Issue Type: Bug
  Components: Components
Affects Versions: 1.2.6-core, 1.2.7-core
Reporter: Matt Cooper
Assignee: Matt Cooper


UIXIterator.processFlattenedChildren() and its underlying UIXCollection cache 
is not initialized or flushed properly.  This becomes a problem when you nest 
iterators.  During normal use of non-flattening iterators, its cache gets 
initialized and flushed during the encodeBegin() of its parent class, 
UIXCollection.  During a flattened use case (e.g. the parent component of the 
iterator has a renderer that uses UIXComponent.processFlattenedChildren()), 
encodeBegin() does not get invoked and thus the cache is neither initialized 
properly nor flushed.  We need to expose a non-public method on UIXCollection 
that invokes its private initialization and private flushing functionality so 
that UIXIterator which extends it can invoke this new method during its 
UIXIterator.processFlattenedChildren() and thus so that nested iterators where 
the inner iterator is flattened can work.  This change will have zero impact on 
the non-flattened use case so there is no risk to existing applications in that 
scenario.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Resolved: (TRINIDAD-972) UIXIterator.processFlattenedChildren() and its underlying UIXCollection cache is not initialized or flushed properly

2008-02-26 Thread Matt Cooper (JIRA)


 [ 
https://issues.apache.org/jira/browse/TRINIDAD-972?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Matt Cooper resolved TRINIDAD-972.
--

   Resolution: Fixed
Fix Version/s: 1.2.7-core

 UIXIterator.processFlattenedChildren() and its underlying UIXCollection cache 
 is not initialized or flushed properly
 

 Key: TRINIDAD-972
 URL: https://issues.apache.org/jira/browse/TRINIDAD-972
 Project: MyFaces Trinidad
  Issue Type: Bug
  Components: Components
Affects Versions: 1.2.6-core, 1.2.7-core
Reporter: Matt Cooper
Assignee: Matt Cooper
 Fix For: 1.2.7-core


 UIXIterator.processFlattenedChildren() and its underlying UIXCollection cache 
 is not initialized or flushed properly.  This becomes a problem when you nest 
 iterators.  During normal use of non-flattening iterators, its cache gets 
 initialized and flushed during the encodeBegin() of its parent class, 
 UIXCollection.  During a flattened use case (e.g. the parent component of the 
 iterator has a renderer that uses UIXComponent.processFlattenedChildren()), 
 encodeBegin() does not get invoked and thus the cache is neither initialized 
 properly nor flushed.  We need to expose a non-public method on UIXCollection 
 that invokes its private initialization and private flushing functionality so 
 that UIXIterator which extends it can invoke this new method during its 
 UIXIterator.processFlattenedChildren() and thus so that nested iterators 
 where the inner iterator is flattened can work.  This change will have zero 
 impact on the non-flattened use case so there is no risk to existing 
 applications in that scenario.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Reopened: (TRINIDAD-901) Trinidad demos use deprecated styleClass=AFDataText

2008-02-20 Thread Matt Cooper (JIRA)


 [ 
https://issues.apache.org/jira/browse/TRINIDAD-901?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Matt Cooper reopened TRINIDAD-901:
--


Reopen for backporting to 1.1 trunk.

 Trinidad demos use deprecated styleClass=AFDataText
 -

 Key: TRINIDAD-901
 URL: https://issues.apache.org/jira/browse/TRINIDAD-901
 Project: MyFaces Trinidad
  Issue Type: Bug
  Components: Components
Affects Versions: 1.2.5-core
Reporter: Sandy Schaffner
Assignee: Matt Cooper
Priority: Minor
 Fix For: 1.2.6-core, 1.0.7-core


 Manyy Trinidad demos use styleClass=AFDataText. 
 This should be styleClass=AFFieldTextMarker

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Resolved: (TRINIDAD-901) Trinidad demos use deprecated styleClass=AFDataText

2008-02-20 Thread Matt Cooper (JIRA)


 [ 
https://issues.apache.org/jira/browse/TRINIDAD-901?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Matt Cooper resolved TRINIDAD-901.
--

   Resolution: Fixed
Fix Version/s: 1.0.7-core

 Trinidad demos use deprecated styleClass=AFDataText
 -

 Key: TRINIDAD-901
 URL: https://issues.apache.org/jira/browse/TRINIDAD-901
 Project: MyFaces Trinidad
  Issue Type: Bug
  Components: Components
Affects Versions: 1.2.5-core
Reporter: Sandy Schaffner
Assignee: Matt Cooper
Priority: Minor
 Fix For: 1.0.7-core, 1.2.6-core


 Manyy Trinidad demos use styleClass=AFDataText. 
 This should be styleClass=AFFieldTextMarker

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Resolved: (TRINIDAD-927) The table element in the panelBox that contains its header has no specified width nor skin selector

2008-01-31 Thread Matt Cooper (JIRA)

[
https://issues.apache.org/jira/browse/TRINIDAD-927?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Matt Cooper resolved TRINIDAD-927.
--

Resolution: Fixed
Fix Version/s: 1.2.6-core
1.0.6-core

Turns out that no new skin selector was needed because the problem was that
there was definite different behavior when either the icon or text was present
and when they were both not present. Now, when they are present, the panelBox
header bar and content will support using the full width.

The table element in the panelBox that contains its header has no specified
width nor skin selector
---

Key: TRINIDAD-927
URL: https://issues.apache.org/jira/browse/TRINIDAD-927
Project: MyFaces Trinidad
Issue Type: Bug
Components: Components
Affects Versions: 1.0.5-core, 1.2.5-core
Reporter: Matt Cooper
Assignee: Matt Cooper
Fix For: 1.0.6-core, 1.2.6-core

The table element in the panelBox that contains its header has no specified
width nor skin selector.
If you run this demo:
http://www.irian.at/trinidad-demo/faces/components/panelBox.jspx
and view the source near the container header text, you'll see that the
table element that is the nearest ancestor to the element with class=x5g,
it has no width specfied. If the panelBox is stretched to be 100% wide,
there will be no way for the header to stretch as well. It appears strange
to me that this element doesn't have a 100% width because when the panelBox
is stretched (as seen when using inlineStyle=width:100%;, its header bar
doesn't span the entire width.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (TRINIDAD-757) partialTriggers Contract Fails if direct parent component is not a NamingContainer

2008-01-30 Thread Matt Cooper (JIRA)

[
https://issues.apache.org/jira/browse/TRINIDAD-757?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12564193#action_12564193
]

Matt Cooper commented on TRINIDAD-757:
--

Note Andrew logged an RI bug against UIComponent's findComponent API:
https://javaserverfaces.dev.java.net/issues/show_bug.cgi?id=690

partialTriggers Contract Fails if direct parent component is not a
NamingContainer
--

Key: TRINIDAD-757
URL: https://issues.apache.org/jira/browse/TRINIDAD-757
Project: MyFaces Trinidad
Issue Type: Bug
Components: Components
Affects Versions: 1.0.3-core, 1.2.2-core
Reporter: Matt Cooper
Assignee: Jeanne Waldman
Attachments: partialTriggers.jspx

The definition of partialTriggers is:
The IDs of the components that should trigger a partial update. This
component will listen on the trigger components. If one of the trigger
components receives an event that will cause it to update in some way, this
component will request to be updated too. Identifiers are relative to the
source component, and must account for NamingContainers. If your component is
already inside of a naming container, you can use a single colon to start the
search from the root, or multiple colons to move up through the
NamingContainers - :: will search from the parent naming container, :::
will search from the grandparent naming container, etc.
I am seeing that the multiple-colon use case will work as long as the direct
parent component is a NamingContainer. If the direct parent component is not
a NamingContainer then one additional colon is incorrectly required to make
it work. I will upload a test page that demonstrates this shortly.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Resolved: (TRINIDAD-833) Ability to sking branding facet for tr:panelPage

2008-01-24 Thread Matt Cooper (JIRA)


 [ 
https://issues.apache.org/jira/browse/TRINIDAD-833?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Matt Cooper resolved TRINIDAD-833.
--

   Resolution: Fixed
Fix Version/s: 1.2.6-core
   1.0.6-core

Added af|panelPage::branding which applies to the wrapper element around the 
content placed in the branding facet of the tr:panelPage component.  In the 
simple skin, this has no default styles.  In the minimal skin, this provides a 
4px padding style by default.

 Ability to sking branding facet for tr:panelPage
 

 Key: TRINIDAD-833
 URL: https://issues.apache.org/jira/browse/TRINIDAD-833
 Project: MyFaces Trinidad
  Issue Type: Improvement
  Components: Skinning
Affects Versions: 1.0.4-core
 Environment: --
Reporter: Mark Robinson
Assignee: Matt Cooper
 Fix For: 1.0.6-core, 1.2.6-core


 The skinning documentation describes that several of the panelPage facets are 
 skinnable but branding is not.  Would it be possible to add a skinning 
 selector for branding?

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Resolved: (TRINIDAD-901) Trinidad demos use deprecated styleClass=AFDataText

2008-01-23 Thread Matt Cooper (JIRA)


 [ 
https://issues.apache.org/jira/browse/TRINIDAD-901?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Matt Cooper resolved TRINIDAD-901.
--

   Resolution: Fixed
Fix Version/s: 1.2.6-core
 Assignee: Matt Cooper

Resolved in trinidad_1.2.x revision 614611.

 Trinidad demos use deprecated styleClass=AFDataText
 -

 Key: TRINIDAD-901
 URL: https://issues.apache.org/jira/browse/TRINIDAD-901
 Project: MyFaces Trinidad
  Issue Type: Bug
  Components: Components
Affects Versions: 1.2.5-core
Reporter: Sandy Schaffner
Assignee: Matt Cooper
Priority: Minor
 Fix For: 1.2.6-core


 Manyy Trinidad demos use styleClass=AFDataText. 
 This should be styleClass=AFFieldTextMarker

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Resolved: (TRINIDAD-903) demos for showDetail* components missing from demo index

2008-01-23 Thread Matt Cooper (JIRA)


 [ 
https://issues.apache.org/jira/browse/TRINIDAD-903?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Matt Cooper resolved TRINIDAD-903.
--

   Resolution: Fixed
Fix Version/s: 1.2.6-core
   1.0.6-core

Fixed in:
trinidad/trunk revision 614658
trinidad/trunk_1.2.x revision 614653

 demos for showDetail* components missing from demo index
 

 Key: TRINIDAD-903
 URL: https://issues.apache.org/jira/browse/TRINIDAD-903
 Project: MyFaces Trinidad
  Issue Type: Bug
  Components: Components
Affects Versions: 1.2.5-core
Reporter: Sandy Schaffner
Assignee: Matt Cooper
Priority: Minor
 Fix For: 1.0.6-core, 1.2.6-core


 http://www.irian.at/trinidad-demo/faces/componentDemos.jspx
 demos for tr:showDetailHeader and tr:showDetailItem exist but are not on 
 index.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (TRINIDAD-914) Selected and disclosed row key sets in UIXTableTemplate.java are assumed to be non-null

2008-01-22 Thread Matt Cooper (JIRA)

Selected and disclosed row key sets in UIXTableTemplate.java are assumed to be 
non-null
---

 Key: TRINIDAD-914
 URL: https://issues.apache.org/jira/browse/TRINIDAD-914
 Project: MyFaces Trinidad
  Issue Type: Bug
  Components: Components
Affects Versions: 1.2.5-core, 1.0.5-core
Reporter: Matt Cooper
Assignee: Matt Cooper


The selected and disclosed row key sets in UIXTableTemplate.java are assumed to 
be non-null.  However, it is possible that they are null instead of an empty 
row key set.  There is other table code which checks for null but in 
UIXTableTemplate.createCollectionModel(), it doesn't.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (TRINIDAD-914) Selected and disclosed row key sets in UIXTableTemplate.java are assumed to be non-null

2008-01-22 Thread Matt Cooper (JIRA)


[ 
https://issues.apache.org/jira/browse/TRINIDAD-914?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12561416#action_12561416
 ] 

Matt Cooper commented on TRINIDAD-914:
--

The fixes have been committed to:

trinidad/trunk revision 614284
trinidad/trunk_1.2.x revision 614285
trinidad/branches/1.2.4.1-branch revision 614282
trinidad/branches/1.2.5.1-branch revision 614283

 Selected and disclosed row key sets in UIXTableTemplate.java are assumed to 
 be non-null
 ---

 Key: TRINIDAD-914
 URL: https://issues.apache.org/jira/browse/TRINIDAD-914
 Project: MyFaces Trinidad
  Issue Type: Bug
  Components: Components
Affects Versions: 1.0.5-core, 1.2.5-core
Reporter: Matt Cooper
Assignee: Matt Cooper
   Original Estimate: 24h
  Remaining Estimate: 24h

 The selected and disclosed row key sets in UIXTableTemplate.java are assumed 
 to be non-null.  However, it is possible that they are null instead of an 
 empty row key set.  There is other table code which checks for null but in 
 UIXTableTemplate.createCollectionModel(), it doesn't.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (TRINIDAD-642) UIXTable.createCollectionModel throws null pointer exception if selectedRowKeys evaluates to null

2008-01-22 Thread Matt Cooper (JIRA)


 [ 
https://issues.apache.org/jira/browse/TRINIDAD-642?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Matt Cooper updated TRINIDAD-642:
-

   Resolution: Fixed
Fix Version/s: 1.2.6-core
   1.0.6-core
   Status: Resolved  (was: Patch Available)

Fixed under these revisions:

trinidad/trunk revision 614388
trinidad/trunk_1.2.x revision 614381
trinidad/branches/1.2.4.1-branch revision 614383
trinidad/branches/1.2.5.1-branch revision 614385

 UIXTable.createCollectionModel throws null pointer exception if 
 selectedRowKeys evaluates to null
 -

 Key: TRINIDAD-642
 URL: https://issues.apache.org/jira/browse/TRINIDAD-642
 Project: MyFaces Trinidad
  Issue Type: Bug
  Components: Components
Affects Versions: 1.2.1-core
Reporter: Max Starets
Assignee: Matt Cooper
 Fix For: 1.0.6-core, 1.2.6-core

 Attachments: jira-642.patch


 UIXTable.createCollectionModel() expects that selectedRowKeys and 
 disclosedRowKeys are always non-null.
 To avoid null-pointer exceptions, we need two fixes:
 1) Call _init() in UIXCollection.invokeOnComponent() to ensure that these 
 properties are initialized;
 2) If the properties are still null in createColelctionModel() (presumably 
 because the values were EL-bound and
 got evaluated to null, but the _init() did not proceed because UIXColelction 
 has already been initialized), we need
 to manually allocate RowKeySetImpl object and set the properties

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (TRINIDAD-850) Virtual Attributes in Component Generator hard-code accessKey

2007-12-05 Thread Matt Cooper (JIRA)

Virtual Attributes in Component Generator hard-code accessKey
-

Key: TRINIDAD-850
URL: https://issues.apache.org/jira/browse/TRINIDAD-850
Project: MyFaces Trinidad
Issue Type: Bug
Components: Plugins
Affects Versions: 1.2.5-plugins
Reporter: Matt Cooper
Assignee: Matt Cooper
Priority: Minor

Whenever a Trinidad component has a text/label/value and a corresponding
accessKey, a third attribute is added to the tag to simplify the assignment of
the first two attributes, e.g. to help with translations. This attribute is
identified as a virtual attribute meaning that it only exists on the tag and
not on the component. The names of these attributes are textAndAccessKey,
labelAndAccessKey, or valueAndAccessKey.

The plug-in code
org.apache.myfaces.trinidadbuild.plugin.faces.generator.taglib.TrinidadComponentTagGenerator._getAccessKeyPropertyKeys()
unfortunately hard-codes accessKey as the secondary non-virtual attribute
instead of searching for And and then using the leading and the following
strings around it.

This hard-coding becomes a problem when you have components where you need to
define multiple text/label/value and accessKey pairs. Let's say these are the
virtual attribute names desired:

- yesTextAndAccessKey
- noTextAndAccessKey
- cancelTextAndAccessKey

These separate out into these non-virtual attributes:

- yesText, accessKey
- noText, accessKey
- cancelText, accessKey

Notice the collisions. Instead, this is the desired separation is:

- yesText, yesAccessKey
- noText, noAccessKey
- cancelText, cancelAccessKey

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (TRINIDAD-825) Make the Generated Skin File Cache Read Only

2007-11-16 Thread Matt Cooper (JIRA)

Make the Generated Skin File Cache Read Only


 Key: TRINIDAD-825
 URL: https://issues.apache.org/jira/browse/TRINIDAD-825
 Project: MyFaces Trinidad
  Issue Type: Bug
  Components: Skinning
Affects Versions: 1.0.5-core, 1.2.4-core
Reporter: Matt Cooper
Assignee: Matt Cooper
Priority: Trivial


The generated skin cache css files don't need to be writable so we can set them 
as read only.  If read only, it is still deletable so this would be an okay 
change.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Resolved: (TRINIDAD-825) Make the Generated Skin File Cache Read Only

2007-11-16 Thread Matt Cooper (JIRA)


 [ 
https://issues.apache.org/jira/browse/TRINIDAD-825?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Matt Cooper resolved TRINIDAD-825.
--

   Resolution: Fixed
Fix Version/s: 1.0.5-core

Committed to Trinidad trunk r595806.

 Make the Generated Skin File Cache Read Only
 

 Key: TRINIDAD-825
 URL: https://issues.apache.org/jira/browse/TRINIDAD-825
 Project: MyFaces Trinidad
  Issue Type: Bug
  Components: Skinning
Affects Versions: 1.0.5-core, 1.2.4-core
Reporter: Matt Cooper
Assignee: Matt Cooper
Priority: Trivial
 Fix For: 1.0.5-core


 The generated skin cache css files don't need to be writable so we can set 
 them as read only.  If read only, it is still deletable so this would be an 
 okay change.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (TRINIDAD-666) Make ExternalContextUtils part of the public API

2007-10-24 Thread Matt Cooper (JIRA)


[ 
https://issues.apache.org/jira/browse/TRINIDAD-666?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12537359
 ] 

Matt Cooper commented on TRINIDAD-666:
--

Note regarding Scott's comment about not being able to go into 1.2.3, he 
mentions this just because of process.  It is perfectly fine to go into 
1.2.4--no patches are necessary since this will happen once committed to the 
trunk and the 1.2.4 branch is created.  The confusion here is that the JSF 1.1 
code is still in trunk, not off into a maintenance branch and the JSF 1.2 code 
is in a branch, not yet in the trunk.

 Make ExternalContextUtils part of the public API
 

 Key: TRINIDAD-666
 URL: https://issues.apache.org/jira/browse/TRINIDAD-666
 Project: MyFaces Trinidad
  Issue Type: Improvement
Affects Versions: 1.0.1-core, 1.0.2-core, 1.2.1-core
Reporter: Scott O'Bryan
Assignee: Matt Cooper
 Fix For: 1.0.4-core

 Attachments: TRINIDAD-666_1_2_3.patch, TRINIDAD-666_trunk.patch


 The org.apache.myfaces.trinidadinternal.utils.ExternalContextUtils package 
 should be promoted to the API package.  
 As part of this promotion, we should take a perepheral look at the 
 isActionRequest method and instead return an enumeration (possibly with the 
 ability to query capabilities).  For JSR-168 and Servlet requests, the 
 current API is satisfactory, but we will need something that could more 
 easily be extended to support  JSR-286 request types.  We do not need to 
 support these requests until the spec is final, but we should have a good 
 upgrade path so as not to dirty the Trinidad API.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (TRINIDAD-757) partialTriggers Contract Fails if direct parent component is not a NamingContainer

2007-10-05 Thread Matt Cooper (JIRA)

partialTriggers Contract Fails if direct parent component is not a 
NamingContainer
--

 Key: TRINIDAD-757
 URL: https://issues.apache.org/jira/browse/TRINIDAD-757
 Project: MyFaces Trinidad
  Issue Type: Bug
  Components: Components
Affects Versions: 1.2.2-core, 1.0.3-core
Reporter: Matt Cooper
Assignee: Matt Cooper


The definition of partialTriggers is:

The IDs of the components that should trigger a partial update. This component 
will listen on the trigger components. If one of the trigger components 
receives an event that will cause it to update in some way, this component will 
request to be updated too. Identifiers are relative to the source component, 
and must account for NamingContainers. If your component is already inside of a 
naming container, you can use a single colon to start the search from the root, 
or multiple colons to move up through the NamingContainers - :: will search 
from the parent naming container, ::: will search from the grandparent naming 
container, etc.

I am seeing that the multiple-colon use case will work as long as the direct 
parent component is a NamingContainer.  If the direct parent component is not a 
NamingContainer then one additional colon is incorrectly required to make it 
work.  I will upload a test page that demonstrates this shortly.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Issue Comment Edited: (TRINIDAD-757) partialTriggers Contract Fails if direct parent component is not a NamingContainer

2007-10-05 Thread Matt Cooper (JIRA)


[ 
https://issues.apache.org/jira/browse/TRINIDAD-757?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12532765
 ] 

mattcooper edited comment on TRINIDAD-757 at 10/5/07 2:34 PM:
---

This test page has 4 buttons:
- button 1 is what all of the other buttons' partialTriggers will be pointing to
- button 2's partialTrigger works, has the incorrect number of colons, and has 
a direct NamingContainer parent
- button 3's partialTrigger fails, has the incorrect number of colons, and has 
a direct non-NamingContainer parent
- button 4's partialTrigger works, has the correct number of colons, and has a 
direct non-NamingContainer parent

When you run the page and click on any of the buttons, you will see an error 
logged to the console like this:

Oct 5, 2007 2:04:50 PM 
org.apache.myfaces.trinidadinternal.context.RequestContextImpl 
addPartialTriggerListeners
WARNING: Could not find partial trigger 
:::button1WrapperA:button1WrapperB:button1 from 
CoreCommandButton[UIXFacesBeanImpl, id=button3]

This is wrong, Andrew and I feel that button 2 and 3's partialTriggers should 
fail.

  was (Author: mattcooper):
This test page has 4 buttons:
- button 1 is what all of the other buttons' partialTriggers will be pointing to
- button 2's partialTrigger works, has the correct number of colons, and has a 
direct NamingContainer parent
- button 3's partialTrigger fails, has the correct number of colons, and has a 
direct non-NamingContainer parent
- button 4's partialTrigger works, has the incorrect number of colons, and has 
a direct non-NamingContainer parent

When you run the page and click on any of the buttons, you will see an error 
logged to the console like this:

Oct 5, 2007 2:04:50 PM 
org.apache.myfaces.trinidadinternal.context.RequestContextImpl 
addPartialTriggerListeners
WARNING: Could not find partial trigger 
:::button1WrapperA:button1WrapperB:button1 from 
CoreCommandButton[UIXFacesBeanImpl, id=button3]

This is wrong, button 3's partialTrigger should work.  Instead, the error 
should be for button 4.
  
 partialTriggers Contract Fails if direct parent component is not a 
 NamingContainer
 --

 Key: TRINIDAD-757
 URL: https://issues.apache.org/jira/browse/TRINIDAD-757
 Project: MyFaces Trinidad
  Issue Type: Bug
  Components: Components
Affects Versions: 1.0.3-core, 1.2.2-core
Reporter: Matt Cooper
Assignee: Matt Cooper
 Attachments: partialTriggers.jspx


 The definition of partialTriggers is:
 The IDs of the components that should trigger a partial update. This 
 component will listen on the trigger components. If one of the trigger 
 components receives an event that will cause it to update in some way, this 
 component will request to be updated too. Identifiers are relative to the 
 source component, and must account for NamingContainers. If your component is 
 already inside of a naming container, you can use a single colon to start the 
 search from the root, or multiple colons to move up through the 
 NamingContainers - :: will search from the parent naming container, ::: 
 will search from the grandparent naming container, etc.
 I am seeing that the multiple-colon use case will work as long as the direct 
 parent component is a NamingContainer.  If the direct parent component is not 
 a NamingContainer then one additional colon is incorrectly required to make 
 it work.  I will upload a test page that demonstrates this shortly.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (TRINIDAD-749) Launching modal dialog when the launcher window body has position:absolute in IE makes launcher page look corrupt

2007-10-01 Thread Matt Cooper (JIRA)

Launching modal dialog when the launcher window body has position:absolute in 
IE makes launcher page look corrupt
-

 Key: TRINIDAD-749
 URL: https://issues.apache.org/jira/browse/TRINIDAD-749
 Project: MyFaces Trinidad
  Issue Type: Bug
  Components: Components
Affects Versions: 1.2.2-core, 1.0.3-core
 Environment: Microsoft Windows XP SP2, Internet Explorer 7.0.5730.11
Reporter: Matt Cooper
Assignee: Matt Cooper
Priority: Minor
 Fix For: 1.0.3-core


When launching a modal dialog in Trinidad using IE7, it will change the opacity 
of the body element to 50% to give the page a disabled appearance.

However, if there are other semi-opaque elements on the page and if the body 
uses absolute positioning, then those semi-opaque elements will be drawn as if 
they were opaque.  This will end up masking areas of the page that shouldn't be 
masked and give the appearance of the launching window as being corrupt.

Instead, the window launching code should not mess with the body element and 
instead overlay a DIV, achieving the desired appearance regardless of the 
presence of other semi-opaque elements on the page.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (TRINIDAD-653) PanelLabelAndMessageRenderer shouldn't need the for given to detect what it is for

2007-08-27 Thread Matt Cooper (JIRA)


[ 
https://issues.apache.org/jira/browse/TRINIDAD-653?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12523101
 ] 

Matt Cooper commented on TRINIDAD-653:
--

If there are multiple EditableValueHolders inside the body of the 
panelLabelAndMessage, perhaps the default behavior (if no for is specified) 
should be to traverse through the children/grandchildren until the first one is 
found.  The children might be wrapped in some other layout component in which 
we would probably want to skip over.

 PanelLabelAndMessageRenderer shouldn't need the for given to detect what it 
 is for
 

 Key: TRINIDAD-653
 URL: https://issues.apache.org/jira/browse/TRINIDAD-653
 Project: MyFaces Trinidad
  Issue Type: Improvement
Affects Versions: 1.0.2-core
Reporter: Andrew Robinson

 Since CorePanelLabelAndMessage will usually be used having the first child 
 component as the input, the renderer should be able to determine the for 
 attribute value without it being specified. Here is code that can be used in 
 the PanelLabelAndMessageRenderer:
   @Override
   protected String getLabelFor(FacesContext context, RenderingContext arc,
 UIComponent component, FacesBean bean)
   {
 String forValue = getFor(bean);
 String val = MessageUtils.getClientIdFor(context, component, forValue);
 if (val == null)
 {
   if (component.getChildCount()  0)
   {
 UIComponent firstChild = (UIComponent)component.getChildren().get(0);
 if (firstChild instanceof EditableValueHolder)
 {
   val = firstChild.getClientId(context);
 }
   }
 }
 return val;
   }

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

87 matches

Mail list logo