[jira] [Commented] (TRINIDAD-2507) Allow CoreRenderer to take part in broadcast of a FacesEvent
[ https://issues.apache.org/jira/browse/TRINIDAD-2507?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14092937#comment-14092937 ] Andrew Robinson commented on TRINIDAD-2507: --- Committed revision 1617320. Allow CoreRenderer to take part in broadcast of a FacesEvent Key: TRINIDAD-2507 URL: https://issues.apache.org/jira/browse/TRINIDAD-2507 Project: MyFaces Trinidad Issue Type: Improvement Components: Components Affects Versions: 2.1.1-core Reporter: Andrew Robinson Assignee: Andrew Robinson Fix For: 2.1.1-core There are times that a renderer (especially during decode) could want a callback during a later lifecycle. For example, a renderer may want to queue an event and handle that event itself when broadcast. JSF does not make this easy, keeping all the FacesEvent logic in the component and making addFacesListener a protected, instead of public, method. We can improve this for Trinidad by adding a method to CoreRenderer (public void broadcast(UIXComponent component, FacesEvent event)) that the UIXComponentBase could call. The default implementation would be a no-op but could be overwritten to provide the necessary functionality. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (TRINIDAD-2507) Allow CoreRenderer to take part in broadcast of a FacesEvent
[ https://issues.apache.org/jira/browse/TRINIDAD-2507?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Robinson resolved TRINIDAD-2507. --- Resolution: Fixed Fix Version/s: 2.1.1-core Allow CoreRenderer to take part in broadcast of a FacesEvent Key: TRINIDAD-2507 URL: https://issues.apache.org/jira/browse/TRINIDAD-2507 Project: MyFaces Trinidad Issue Type: Improvement Components: Components Affects Versions: 2.1.1-core Reporter: Andrew Robinson Assignee: Andrew Robinson Fix For: 2.1.1-core There are times that a renderer (especially during decode) could want a callback during a later lifecycle. For example, a renderer may want to queue an event and handle that event itself when broadcast. JSF does not make this easy, keeping all the FacesEvent logic in the component and making addFacesListener a protected, instead of public, method. We can improve this for Trinidad by adding a method to CoreRenderer (public void broadcast(UIXComponent component, FacesEvent event)) that the UIXComponentBase could call. The default implementation would be a no-op but could be overwritten to provide the necessary functionality. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (TRINIDAD-2507) Allow CoreRenderer to take part in broadcast of a FacesEvent
Andrew Robinson created TRINIDAD-2507: - Summary: Allow CoreRenderer to take part in broadcast of a FacesEvent Key: TRINIDAD-2507 URL: https://issues.apache.org/jira/browse/TRINIDAD-2507 Project: MyFaces Trinidad Issue Type: Improvement Components: Components Affects Versions: 2.1.1-core Reporter: Andrew Robinson Assignee: Andrew Robinson There are times that a renderer (especially during decode) could want a callback during a later lifecycle. For example, a renderer may want to queue an event and handle that event itself when broadcast. JSF does not make this easy, keeping all the FacesEvent logic in the component and making addFacesListener a protected, instead of public, method. We can improve this for Trinidad by adding a method to CoreRenderer (public void broadcast(UIXComponent component, FacesEvent event)) that the UIXComponentBase could call. The default implementation would be a no-op but could be overwritten to provide the necessary functionality. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (TRINIDAD-2500) RequestContext.applicationScopedConcurrentMap pins objects in memory
Andrew Robinson created TRINIDAD-2500: - Summary: RequestContext.applicationScopedConcurrentMap pins objects in memory Key: TRINIDAD-2500 URL: https://issues.apache.org/jira/browse/TRINIDAD-2500 Project: MyFaces Trinidad Issue Type: Bug Components: Components Affects Versions: 2.1.1-core Reporter: Andrew Robinson Assignee: Andrew Robinson If an app is undeployed or redeployed from an application server the objects that RequestContext.applicationScopedConcurrentMap stores are never removed. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (TRINIDAD-2500) RequestContext.applicationScopedConcurrentMap pins objects in memory
[ https://issues.apache.org/jira/browse/TRINIDAD-2500?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Robinson resolved TRINIDAD-2500. --- Resolution: Fixed Fix Version/s: 2.1.1-core Committed revision 1615192 RequestContext.applicationScopedConcurrentMap pins objects in memory Key: TRINIDAD-2500 URL: https://issues.apache.org/jira/browse/TRINIDAD-2500 Project: MyFaces Trinidad Issue Type: Bug Components: Components Affects Versions: 2.1.1-core Reporter: Andrew Robinson Assignee: Andrew Robinson Fix For: 2.1.1-core If an app is undeployed or redeployed from an application server the objects that RequestContext.applicationScopedConcurrentMap stores are never removed. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TRINIDAD-2500) RequestContext.applicationScopedConcurrentMap pins objects in memory
[ https://issues.apache.org/jira/browse/TRINIDAD-2500?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14082868#comment-14082868 ] Andrew Robinson commented on TRINIDAD-2500: --- Committed revision 1615213 RequestContext.applicationScopedConcurrentMap pins objects in memory Key: TRINIDAD-2500 URL: https://issues.apache.org/jira/browse/TRINIDAD-2500 Project: MyFaces Trinidad Issue Type: Bug Components: Components Affects Versions: 2.1.1-core Reporter: Andrew Robinson Assignee: Andrew Robinson Fix For: 2.1.1-core If an app is undeployed or redeployed from an application server the objects that RequestContext.applicationScopedConcurrentMap stores are never removed. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Reopened] (TRINIDAD-2483) UIXComponentELTag causes an exception in Glassfish
[ https://issues.apache.org/jira/browse/TRINIDAD-2483?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Robinson reopened TRINIDAD-2483: --- Need to fix more occurrences of passing null to getValue UIXComponentELTag causes an exception in Glassfish -- Key: TRINIDAD-2483 URL: https://issues.apache.org/jira/browse/TRINIDAD-2483 Project: MyFaces Trinidad Issue Type: Bug Components: Components Affects Versions: 2.1.0-core Reporter: Andrew Robinson Assignee: Andrew Robinson Fix For: 2.1.1-core A null pointer exception is thrown in glassfish when org.apache.myfaces.trinidad.webapp.UIXComponentELTag.setProperty is called since the EL context is not passed -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TRINIDAD-2483) UIXComponentELTag causes an exception in Glassfish
[ https://issues.apache.org/jira/browse/TRINIDAD-2483?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14048922#comment-14048922 ] Andrew Robinson commented on TRINIDAD-2483: --- Maven Trinidad plugins: commit revision 1607100 UIXComponentELTag causes an exception in Glassfish -- Key: TRINIDAD-2483 URL: https://issues.apache.org/jira/browse/TRINIDAD-2483 Project: MyFaces Trinidad Issue Type: Bug Components: Components Affects Versions: 2.1.0-core Reporter: Andrew Robinson Assignee: Andrew Robinson Fix For: 2.1.1-core A null pointer exception is thrown in glassfish when org.apache.myfaces.trinidad.webapp.UIXComponentELTag.setProperty is called since the EL context is not passed -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (TRINIDAD-2483) UIXComponentELTag causes an exception in Glassfish
[ https://issues.apache.org/jira/browse/TRINIDAD-2483?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Robinson resolved TRINIDAD-2483. --- Resolution: Fixed Fixed in both the plugins and the trunk. This is needed as the JEE specification has changed and now the EL spec is using the ELContext in all expression evaluations so passing null is not going to work UIXComponentELTag causes an exception in Glassfish -- Key: TRINIDAD-2483 URL: https://issues.apache.org/jira/browse/TRINIDAD-2483 Project: MyFaces Trinidad Issue Type: Bug Components: Components Affects Versions: 2.1.0-core Reporter: Andrew Robinson Assignee: Andrew Robinson Fix For: 2.1.1-core A null pointer exception is thrown in glassfish when org.apache.myfaces.trinidad.webapp.UIXComponentELTag.setProperty is called since the EL context is not passed -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TRINIDAD-2483) UIXComponentELTag causes an exception in Glassfish
[ https://issues.apache.org/jira/browse/TRINIDAD-2483?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14048924#comment-14048924 ] Andrew Robinson commented on TRINIDAD-2483: --- Trinidad Trunk: Committed revision 1607101 UIXComponentELTag causes an exception in Glassfish -- Key: TRINIDAD-2483 URL: https://issues.apache.org/jira/browse/TRINIDAD-2483 Project: MyFaces Trinidad Issue Type: Bug Components: Components Affects Versions: 2.1.0-core Reporter: Andrew Robinson Assignee: Andrew Robinson Fix For: 2.1.1-core A null pointer exception is thrown in glassfish when org.apache.myfaces.trinidad.webapp.UIXComponentELTag.setProperty is called since the EL context is not passed -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (TRINIDAD-2483) UIXComponentELTag causes an exception in Glassfish
Andrew Robinson created TRINIDAD-2483: - Summary: UIXComponentELTag causes an exception in Glassfish Key: TRINIDAD-2483 URL: https://issues.apache.org/jira/browse/TRINIDAD-2483 Project: MyFaces Trinidad Issue Type: Bug Components: Components Affects Versions: 2.1.0-core Reporter: Andrew Robinson Assignee: Andrew Robinson A null pointer exception is thrown in glassfish when org.apache.myfaces.trinidad.webapp.UIXComponentELTag.setProperty is called since the EL context is not passed -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (TRINIDAD-2483) UIXComponentELTag causes an exception in Glassfish
[ https://issues.apache.org/jira/browse/TRINIDAD-2483?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Robinson resolved TRINIDAD-2483. --- Resolution: Fixed Fix Version/s: 2.1.1-core Committed revision 1603543 UIXComponentELTag causes an exception in Glassfish -- Key: TRINIDAD-2483 URL: https://issues.apache.org/jira/browse/TRINIDAD-2483 Project: MyFaces Trinidad Issue Type: Bug Components: Components Affects Versions: 2.1.0-core Reporter: Andrew Robinson Assignee: Andrew Robinson Fix For: 2.1.1-core A null pointer exception is thrown in glassfish when org.apache.myfaces.trinidad.webapp.UIXComponentELTag.setProperty is called since the EL context is not passed -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (TRINIDAD-2474) AutoSubmitUtils and XhtmlUtils can cause a thread deadlock
Andrew Robinson created TRINIDAD-2474: - Summary: AutoSubmitUtils and XhtmlUtils can cause a thread deadlock Key: TRINIDAD-2474 URL: https://issues.apache.org/jira/browse/TRINIDAD-2474 Project: MyFaces Trinidad Issue Type: Bug Components: Components Affects Versions: 2.1.0-core Reporter: Andrew Robinson AutoSubmitUtils calls XhtmlScriptletFactory.registerAllScriptlets which in tern uses XhtmlUtils which has a static initializer that calls XhtmlScriptletFactory.registerAllScriptlets. If another thread uses XhtmlUtils, that initialization will wait on the AutoSubmitUtils which is waiting to use XhtmlUtils, deadlocking the threads. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (TRINIDAD-2474) AutoSubmitUtils and XhtmlUtils can cause a thread deadlock
[ https://issues.apache.org/jira/browse/TRINIDAD-2474?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Robinson resolved TRINIDAD-2474. --- Resolution: Fixed Fix Version/s: 2.1.1-core Assignee: Andrew Robinson Remove the redundant call to XhtmlScriptletFactory.registerAllScriptlets in AutoSubmitUtils. This will prevent the thread deadlock issue by ensuring that only XhtmlUtils calls XhtmlScriptletFactory.registerAllScriptlets Committed revision 1596427. AutoSubmitUtils and XhtmlUtils can cause a thread deadlock -- Key: TRINIDAD-2474 URL: https://issues.apache.org/jira/browse/TRINIDAD-2474 Project: MyFaces Trinidad Issue Type: Bug Components: Components Affects Versions: 2.1.0-core Reporter: Andrew Robinson Assignee: Andrew Robinson Fix For: 2.1.1-core AutoSubmitUtils calls XhtmlScriptletFactory.registerAllScriptlets which in tern uses XhtmlUtils which has a static initializer that calls XhtmlScriptletFactory.registerAllScriptlets. If another thread uses XhtmlUtils, that initialization will wait on the AutoSubmitUtils which is waiting to use XhtmlUtils, deadlocking the threads. -- This message was sent by Atlassian JIRA (v6.2#6252)
Re: [Trinidad] New API addition for Trinidad's UIXCollection
How is this different from just setting the current row index to -1?
On Tue, May 6, 2014 at 1:49 PM, Jing Wu jing.x...@oracle.com wrote:
Thanks Blake for your comment!
It's the component that is hanging onto a rowkey, the model naturally
reacts to key change and has valid state. But UIXCollection component
caches the key in it's internal state object which needs to be cleared out
and recalculated. So the proposal is to simply provide a hook for module
(e.g. a listener that listens to key change) to clear out the component's
cache. So when next time there's need to get the current key from the
component, since there's no cached value, the component will retrieve it
from the model which contains the already updated key.
Thanks,
Jing
On 5/5/2014 8:33 PM, Blake Sullivan wrote:
Jing,
What is an example of a case where code external to the model
implementation knows that:
1) The model is hanging onto a rowKey
2) The key is invalid
The model implementation is typical supposed to encapsulate this
information.
-- Blake Sullivan
On May 5, 2014, at 3:26 PM, Jing Wu wrote:
Hi,
This is for JIRA https://issues.apache.org/jira/browse/TRINIDAD-2471.
UIXCollection caches the current row key in its internal state. There
are cases that the row key becomes stale / invalid in the middle of
processing a row. A new API invalidateCurrentRowKey() is added to
UIXCollection to clear out the cached current row key, so next time when it
is requested, this current new key will be recalculated from model.
/**
* Invalidate the cached current row key so it will be recalculated
* from the model next time when it is requested.
*/
public void invalidateCurrentRowKey()
{
}
Any comment is welcome!
Thanks,
Jing
[jira] [Updated] (TRINIDAD-2469) trinidad date picker selects previous day when using lightweight dialogs
[ https://issues.apache.org/jira/browse/TRINIDAD-2469?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Robinson updated TRINIDAD-2469: -- Resolution: Fixed Fix Version/s: 2.1.1-core Status: Resolved (was: Patch Available) Patch committed trinidad date picker selects previous day when using lightweight dialogs - Key: TRINIDAD-2469 URL: https://issues.apache.org/jira/browse/TRINIDAD-2469 Project: MyFaces Trinidad Issue Type: Bug Components: Components Affects Versions: 2.1.1-core Reporter: Paresh Kumar Acharya Fix For: 2.1.1-core Attachments: 18443584.patch The issue is with tr:inputDate control, when you select a date between Mar 9 and Nov 2, it keeps selecting the previous day. The issue seems to be specific around day light saving time. If the customer remove the lightweight dialogs change then it opens as a popup and works correctly without any issues. The issue occurs when the server's current date is non DST and clients date is in DST. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TRINIDAD-2469) trinidad date picker selects previous day when using lightweight dialogs
[ https://issues.apache.org/jira/browse/TRINIDAD-2469?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13984923#comment-13984923 ] Andrew Robinson commented on TRINIDAD-2469: --- Committed revision 1591131. trinidad date picker selects previous day when using lightweight dialogs - Key: TRINIDAD-2469 URL: https://issues.apache.org/jira/browse/TRINIDAD-2469 Project: MyFaces Trinidad Issue Type: Bug Components: Components Affects Versions: 2.1.1-core Reporter: Paresh Kumar Acharya Fix For: 2.1.1-core Attachments: 18443584.patch The issue is with tr:inputDate control, when you select a date between Mar 9 and Nov 2, it keeps selecting the previous day. The issue seems to be specific around day light saving time. If the customer remove the lightweight dialogs change then it opens as a popup and works correctly without any issues. The issue occurs when the server's current date is non DST and clients date is in DST. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (TRINIDAD-2446) Trinidad varStatus does not expose a getStep method
Andrew Robinson created TRINIDAD-2446: - Summary: Trinidad varStatus does not expose a getStep method Key: TRINIDAD-2446 URL: https://issues.apache.org/jira/browse/TRINIDAD-2446 Project: MyFaces Trinidad Issue Type: Bug Components: Components Affects Versions: 2.1.1-core Reporter: Andrew Robinson Assignee: Andrew Robinson -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Resolved] (TRINIDAD-2446) Trinidad varStatus does not expose a getStep method
[ https://issues.apache.org/jira/browse/TRINIDAD-2446?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Robinson resolved TRINIDAD-2446. --- Resolution: Fixed Fix Version/s: 2.1.1-core Committed revision 1,560,197 Trinidad varStatus does not expose a getStep method --- Key: TRINIDAD-2446 URL: https://issues.apache.org/jira/browse/TRINIDAD-2446 Project: MyFaces Trinidad Issue Type: Bug Components: Components Affects Versions: 2.1.1-core Reporter: Andrew Robinson Assignee: Andrew Robinson Fix For: 2.1.1-core -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (TRINIDAD-2437) documentation about cilent side rules does not mention about aliases
[
https://issues.apache.org/jira/browse/TRINIDAD-2437?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Robinson updated TRINIDAD-2437:
--
Resolution: Fixed
Fix Version/s: 2.1.1-core
Status: Resolved (was: Patch Available)
Applied the patch from Anand
documentation about cilent side rules does not mention about aliases
Key: TRINIDAD-2437
URL: https://issues.apache.org/jira/browse/TRINIDAD-2437
Project: MyFaces Trinidad
Issue Type: Bug
Components: Skinning
Affects Versions: 2.1.0-core
Reporter: Anand V Nath
Priority: Minor
Fix For: 2.1.1-core
Attachments: skin-doc-update.patch
CSS Client rules are executed at client side. Skin has many features like
aliases, rule refs, property refs which gets evaluated at server side. So
there are usecases which wont work with client side rules.
Eg:
@media screen and (max-width: 1680px) {
.AFBrandingBackgroundColor:alias {
color: Red;
}
}
This will not get applied because we evaluate the @media rule at client side.
The alias however is evaluated at the server side and skinning framework
would not be able to decide when the alias specified above will be
applicable. We documented about the -tr rules in the skinning dev guide, but
missed out on the alias usecase.
This bug is to update the alias usecase. Also please suggest if I am missing
out any other usecase that we need to mention in conjunction with client side
rules.
--
This message was sent by Atlassian JIRA
(v6.1.4#6159)
[jira] [Created] (TRINIDAD-2435) Trinidad's date converter does not allow a separation of language and locale
Andrew Robinson created TRINIDAD-2435: - Summary: Trinidad's date converter does not allow a separation of language and locale Key: TRINIDAD-2435 URL: https://issues.apache.org/jira/browse/TRINIDAD-2435 Project: MyFaces Trinidad Issue Type: Bug Components: Components Affects Versions: 2.1.1-core Reporter: Andrew Robinson Trinidad uses MessageBundle and LocaleElements for i18n. On iOS and Mac OSX, the user's language may be different from their locale. This means that the month, day and other translatable strings should be in the MessageBundle, not the LocaleElements. This may not be an issue with HTML in a browser, but is an issue when desiring to use Trinidad within a Cordova application and trying to use the native locale and language. -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Resolved] (TRINIDAD-2430) ForEach looses varStatus data if JSP tags are not executed
[ https://issues.apache.org/jira/browse/TRINIDAD-2430?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Robinson resolved TRINIDAD-2430. --- Resolution: Fixed Fix Version/s: 2.1.1-core Added an API to RequestContext to be used by ForEachTag to avoid cleaning up when tags are not going to be executed during a request ForEach looses varStatus data if JSP tags are not executed -- Key: TRINIDAD-2430 URL: https://issues.apache.org/jira/browse/TRINIDAD-2430 Project: MyFaces Trinidad Issue Type: Bug Components: Components Affects Versions: 2.1.1-core Reporter: Andrew Robinson Assignee: Andrew Robinson Fix For: 2.1.1-core the ForEachTag has a phase listener that removes unused iteration data (varStatus data). If a 3rd party JSF library skips JSP tag execution during a request, that code assumes the ForEachTag is no longer used. The result is the data is thrown out when it should not need to be. There should be a way to allow such a library notify Trinidad that the JSP tags are not being executed so that the information is not cleaned up. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Created] (TRINIDAD-2430) ForEach looses varStatus data if JSP tags are not executed
Andrew Robinson created TRINIDAD-2430: - Summary: ForEach looses varStatus data if JSP tags are not executed Key: TRINIDAD-2430 URL: https://issues.apache.org/jira/browse/TRINIDAD-2430 Project: MyFaces Trinidad Issue Type: Bug Components: Components Affects Versions: 2.1.1-core Reporter: Andrew Robinson Assignee: Andrew Robinson the ForEachTag has a phase listener that removes unused iteration data (varStatus data). If a 3rd party JSF library skips JSP tag execution during a request, that code assumes the ForEachTag is no longer used. The result is the data is thrown out when it should not need to be. There should be a way to allow such a library notify Trinidad that the JSP tags are not being executed so that the information is not cleaned up. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Created] (TRINIDAD-2429) UIXCollection sets up the context when not necessary
Andrew Robinson created TRINIDAD-2429: - Summary: UIXCollection sets up the context when not necessary Key: TRINIDAD-2429 URL: https://issues.apache.org/jira/browse/TRINIDAD-2429 Project: MyFaces Trinidad Issue Type: Bug Components: Components Affects Versions: 2.1.1-core Reporter: Andrew Robinson Assignee: Andrew Robinson UIXCollection assumes that the component is not in context when methods like processEvent are called. The issue will happen when these methods are called inside of a visit callback. In these cases the UIXCollection is setup twice and torn down twice. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Resolved] (TRINIDAD-2429) UIXCollection sets up the context when not necessary
[ https://issues.apache.org/jira/browse/TRINIDAD-2429?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Robinson resolved TRINIDAD-2429. --- Resolution: Fixed Fix Version/s: 2.1.1-core UIXCollection sets up the context when not necessary Key: TRINIDAD-2429 URL: https://issues.apache.org/jira/browse/TRINIDAD-2429 Project: MyFaces Trinidad Issue Type: Bug Components: Components Affects Versions: 2.1.1-core Reporter: Andrew Robinson Assignee: Andrew Robinson Fix For: 2.1.1-core UIXCollection assumes that the component is not in context when methods like processEvent are called. The issue will happen when these methods are called inside of a visit callback. In these cases the UIXCollection is setup twice and torn down twice. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (TRINIDAD-2376) Provide a means allow partial lazy loading of children components
[ https://issues.apache.org/jira/browse/TRINIDAD-2376?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13679922#comment-13679922 ] Andrew Robinson commented on TRINIDAD-2376: --- Committed revision 1,491,604. Provide a means allow partial lazy loading of children components - Key: TRINIDAD-2376 URL: https://issues.apache.org/jira/browse/TRINIDAD-2376 Project: MyFaces Trinidad Issue Type: Improvement Components: Components Affects Versions: 2.1.0-core Reporter: Andrew Robinson Assignee: Andrew Robinson Fix For: 2.1.0-core With complex component trees and the Trinidad component set, there are frequent use cases where components are generated that are never rendered. This puts an unnecessary overhead on component state, JSP processing time, component tree processing, etc. In order to improve performance, it would be beneficial to allow tags to lazily load their children. For example, the UIXShowDetailHeader does not need to load its children (just its facets) if none of its stamps are disclosed. If a parent could dictate to a Trinidad child component tag if the component should be generated, it would be a good performance gain. In my use case mentioned above, the UIXShowDetailHeader would allow non-component tags like f:attribute/ to be executed and tags that are building the facets (the components that are rendered even when it is collapsed) but skip the creation of the children components until the request that un-discloses the show detail header. This would be an optional setting, controlled by an attribute on the show detail header. -- 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] [Resolved] (TRINIDAD-2376) Provide a means allow partial lazy loading of children components
[ https://issues.apache.org/jira/browse/TRINIDAD-2376?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Robinson resolved TRINIDAD-2376. --- Resolution: Fixed Fix Version/s: 2.1.0-core Provide a means allow partial lazy loading of children components - Key: TRINIDAD-2376 URL: https://issues.apache.org/jira/browse/TRINIDAD-2376 Project: MyFaces Trinidad Issue Type: Improvement Components: Components Affects Versions: 2.1.0-core Reporter: Andrew Robinson Assignee: Andrew Robinson Fix For: 2.1.0-core With complex component trees and the Trinidad component set, there are frequent use cases where components are generated that are never rendered. This puts an unnecessary overhead on component state, JSP processing time, component tree processing, etc. In order to improve performance, it would be beneficial to allow tags to lazily load their children. For example, the UIXShowDetailHeader does not need to load its children (just its facets) if none of its stamps are disclosed. If a parent could dictate to a Trinidad child component tag if the component should be generated, it would be a good performance gain. In my use case mentioned above, the UIXShowDetailHeader would allow non-component tags like f:attribute/ to be executed and tags that are building the facets (the components that are rendered even when it is collapsed) but skip the creation of the children components until the request that un-discloses the show detail header. This would be an optional setting, controlled by an attribute on the show detail header. -- 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] [Resolved] (TRINIDAD-1892) Sub-class support for for JSP tag generation
[
https://issues.apache.org/jira/browse/TRINIDAD-1892?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Robinson resolved TRINIDAD-1892.
---
Resolution: Fixed
Fix Version/s: 2.0.8-plugins
Provided the ability to generate the base classes of JSP tags so that custom
sub-classes may be used to override functionality. The plug-in will now create
Partial[tag name].java files that can be extended by custom classes.
Sub-class support for for JSP tag generation
Key: TRINIDAD-1892
URL: https://issues.apache.org/jira/browse/TRINIDAD-1892
Project: MyFaces Trinidad
Issue Type: Improvement
Components: Build
Affects Versions: 2.0.0-alpha
Reporter: Andy Schwartz
Assignee: Andrew Robinson
Fix For: 2.0.8-plugins
Trinidad's GenerateComponentMojo allows a base source template to be
specified for components that are generated. The contents of the template
file are merged with the generated contents to form the complete component
class.
Trinidad's GenerateJspTaglibsMojo, while containing some code that hints at
this support, eg:
private class IfComponentModifiedFilter extends ComponentFilter
{
protected boolean accept(
ComponentBean component)
{
String tagClass = component.getTagClass();
String sourcePath = Util.convertClassToSourcePath(tagClass, .java);
String templatePath = Util.convertClassToSourcePath(tagClass,
Template.java);
File targetFile = new File(generatedSourceDirectory, sourcePath);
File templateFile = new File(templateSourceDirectory, templatePath);
// accept if templateFile is newer or component has been modified
return (templateFile.lastModified() targetFile.lastModified() ||
component.isModifiedSince(targetFile.lastModified()));
}
}
Does not appear to fully support this.
Opening this issue to request that we enhance GenerateJspTaglibsMojo to
include support for allowing a base template source file to be specified for
generated component tags. Without this, if any tag customization is
necessary, the tag generation tool cannot be used - ie. the entire tag must
be written from scratch.
--
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] [Commented] (TRINIDAD-1892) Sub-class support for for JSP tag generation
[
https://issues.apache.org/jira/browse/TRINIDAD-1892?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13627036#comment-13627036
]
Andrew Robinson commented on TRINIDAD-1892:
---
Due to the fact that the preferred method seems to be to use sub-classes and
call the generated class Partial+ originalName, I'm implementing the
sub-class approach for the tag classes. I changed the code to create and pass
the SourceTemplate to the generator, but at this time the
AbstractComponentTagGenerator is not consuming the SourceTemplate parameter. I
added TODO comments to functions that need to support it.
If someone desires the SourceTemplate approach over the sub-class approach, a
separate ER may be filed to add that code.
Sub-class support for for JSP tag generation
Key: TRINIDAD-1892
URL: https://issues.apache.org/jira/browse/TRINIDAD-1892
Project: MyFaces Trinidad
Issue Type: Improvement
Components: Build
Affects Versions: 2.0.0-alpha
Reporter: Andy Schwartz
Assignee: Andrew Robinson
Trinidad's GenerateComponentMojo allows a base source template to be
specified for components that are generated. The contents of the template
file are merged with the generated contents to form the complete component
class.
Trinidad's GenerateJspTaglibsMojo, while containing some code that hints at
this support, eg:
private class IfComponentModifiedFilter extends ComponentFilter
{
protected boolean accept(
ComponentBean component)
{
String tagClass = component.getTagClass();
String sourcePath = Util.convertClassToSourcePath(tagClass, .java);
String templatePath = Util.convertClassToSourcePath(tagClass,
Template.java);
File targetFile = new File(generatedSourceDirectory, sourcePath);
File templateFile = new File(templateSourceDirectory, templatePath);
// accept if templateFile is newer or component has been modified
return (templateFile.lastModified() targetFile.lastModified() ||
component.isModifiedSince(targetFile.lastModified()));
}
}
Does not appear to fully support this.
Opening this issue to request that we enhance GenerateJspTaglibsMojo to
include support for allowing a base template source file to be specified for
generated component tags. Without this, if any tag customization is
necessary, the tag generation tool cannot be used - ie. the entire tag must
be written from scratch.
--
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] [Created] (TRINIDAD-2376) Provide a means allow partial lazy loading of children components
Andrew Robinson created TRINIDAD-2376: - Summary: Provide a means allow partial lazy loading of children components Key: TRINIDAD-2376 URL: https://issues.apache.org/jira/browse/TRINIDAD-2376 Project: MyFaces Trinidad Issue Type: Improvement Components: Components Affects Versions: 2.1.0-core Reporter: Andrew Robinson Assignee: Andrew Robinson With complex component trees and the Trinidad component set, there are frequent use cases where components are generated that are never rendered. This puts an unnecessary overhead on component state, JSP processing time, component tree processing, etc. In order to improve performance, it would be beneficial to allow tags to lazily load their children. For example, the UIXShowDetailHeader does not need to load its children (just its facets) if none of its stamps are disclosed. If a parent could dictate to a Trinidad child component tag if the component should be generated, it would be a good performance gain. In my use case mentioned above, the UIXShowDetailHeader would allow non-component tags like f:attribute/ to be executed and tags that are building the facets (the components that are rendered even when it is collapsed) but skip the creation of the children components until the request that un-discloses the show detail header. This would be an optional setting, controlled by an attribute on the show detail header. -- 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] [Resolved] (TRINIDAD-1940) Problems with the tr:forEach
[
https://issues.apache.org/jira/browse/TRINIDAD-1940?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Robinson resolved TRINIDAD-1940.
---
Resolution: Fixed
Problems with the tr:forEach
Key: TRINIDAD-1940
URL: https://issues.apache.org/jira/browse/TRINIDAD-1940
Project: MyFaces Trinidad
Issue Type: Bug
Components: Components
Affects Versions: 2.0.0-beta-1
Reporter: Andrew Robinson
Assignee: Andrew Robinson
Fix For: 2.1.0-core
The tr:forEach tag has issues when trying to use component references and
trying to keep the component state in sync with the items in a list. It also
does not support Maps like the c:forEach tag does.
I seek to improve the forEach tag in Trinidad, and propose that JSF/JSTL does
something similar so that user's can really use the for each tag without
issues. Some of the for each problems are described in my blog:
http://drewdev.blogspot.com/2008/08/cforeach-with-jsf-could-ruin-your-day.html
I propose to address each of the issues with the JSP tag.
First, reliable component references:
tr:forEach var=item items=#{myBean.items}
tr:panelGroupLayout id=pgl1 layout=horizontal
tr:inputText id=it1 label=Enter value: value=#{item.text}
autoSubmit=true /
tr:outputText id=ot1 value=Value is: #{item.text}
partialTriggers=it1 /
/tr:panelGroupLayout
/tr:forEach
The problem is that the author intended the output text component to
partially updated by the sibling input text when it changed value, but that
is not the result. Instead, the partial triggers is always it1, but the
generated input text components are ot1, ot1j_id_1 and ot1j_id_2. The
result is that the output text components all partially update only when the
first input text is changed.
Another problem is that the indexed value expressions and the var status map
that is put into the variable mapper by the for each loop is static. Take
the following example:
tr:panelGroupLayout id=pgl1 layout=scroll
tr:forEach var=item items=#{myBean.items} varStatus=vs
tr:outputText id=ot1 value=This is the last item in the list:
#{vs.last}. Item #{item.text}. /
/tr:forEach
/tr:panelGroupLayout
Say during the first pass, the items in the list are A, B and C and the page
would look like this:
This is the last item in the list: false. Item A.
This is the last item in the list: false. Item B.
This is the last item in the list: true. Item C.
Now, consider what the output would be if someone added an object D to the
end of the list during invoke application:
This is the last item in the list: false. Item A.
This is the last item in the list: false. Item B.
This is the last item in the list: true. Item C.
This is the last item in the list: true. Item D.
Notice that both C and D think they are the last. The reason is that the
UIComponentClassicTagBase will find the components generated for A, B and C
during the findComponent call. It will only create a new component for D.
When D is created, it will pick up the new variable status map created by the
for each tag in its value expressions. Because when three earlier components
were build, C was the last item, and the variable status map in their value
expressions did not reflect any changes. D gets the correct values since it
was just created.
-
I propose to reduce any work required by page developers to implement the for
each loop with re-ordering support (avoid having to use immediate EL in the
ID attribute) and fix the issues above.
The proposal is that Trinidad Tag based components (those components created
by UIXComponentELTag) will be able to have key-based IDs automatically
generated as a result of being in a for each tag. So consider this example:
tr:forEach var=item items=#{bean.items} varStatus=vs
tr:inputText id=it1 value=#{item.value} partialSubmit=true /
tr:outputText id=ot1 value=Value is: #{item.value}
partialTriggers=it1_${vs.key} /
/tr:forEach
In this code, the IDs of the components would automatically pick up the item
key. The item key would be stored on the var status. For List this key would
simply be the index, for Map it would be the map key and CollectionModel
would use the row key. UIXComponentELTag could check to see if a parent tag
desires to alter the component IDs, which in this case, the for each would.
With that set, the tags would alter the component IDs to append the key. For
example, _ + key would be appended to each component ID (it1 would become
it1_A if the key were A).
The for each tag would set the key into the variable mapper so that, instead
of indexes, the key would be used to evaluate the EL with the limitation that
the key would be the index for List, in which the current behavior would
[jira] [Reopened] (TRINIDAD-1940) Problems with the tr:forEach
[
https://issues.apache.org/jira/browse/TRINIDAD-1940?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Robinson reopened TRINIDAD-1940:
---
Found issues with the current code. Re-opening so that I can address them.
Problems with the tr:forEach
Key: TRINIDAD-1940
URL: https://issues.apache.org/jira/browse/TRINIDAD-1940
Project: MyFaces Trinidad
Issue Type: Bug
Components: Components
Affects Versions: 2.0.0-beta-1
Reporter: Andrew Robinson
Assignee: Andrew Robinson
Fix For: 2.1.0-core
The tr:forEach tag has issues when trying to use component references and
trying to keep the component state in sync with the items in a list. It also
does not support Maps like the c:forEach tag does.
I seek to improve the forEach tag in Trinidad, and propose that JSF/JSTL does
something similar so that user's can really use the for each tag without
issues. Some of the for each problems are described in my blog:
http://drewdev.blogspot.com/2008/08/cforeach-with-jsf-could-ruin-your-day.html
I propose to address each of the issues with the JSP tag.
First, reliable component references:
tr:forEach var=item items=#{myBean.items}
tr:panelGroupLayout id=pgl1 layout=horizontal
tr:inputText id=it1 label=Enter value: value=#{item.text}
autoSubmit=true /
tr:outputText id=ot1 value=Value is: #{item.text}
partialTriggers=it1 /
/tr:panelGroupLayout
/tr:forEach
The problem is that the author intended the output text component to
partially updated by the sibling input text when it changed value, but that
is not the result. Instead, the partial triggers is always it1, but the
generated input text components are ot1, ot1j_id_1 and ot1j_id_2. The
result is that the output text components all partially update only when the
first input text is changed.
Another problem is that the indexed value expressions and the var status map
that is put into the variable mapper by the for each loop is static. Take
the following example:
tr:panelGroupLayout id=pgl1 layout=scroll
tr:forEach var=item items=#{myBean.items} varStatus=vs
tr:outputText id=ot1 value=This is the last item in the list:
#{vs.last}. Item #{item.text}. /
/tr:forEach
/tr:panelGroupLayout
Say during the first pass, the items in the list are A, B and C and the page
would look like this:
This is the last item in the list: false. Item A.
This is the last item in the list: false. Item B.
This is the last item in the list: true. Item C.
Now, consider what the output would be if someone added an object D to the
end of the list during invoke application:
This is the last item in the list: false. Item A.
This is the last item in the list: false. Item B.
This is the last item in the list: true. Item C.
This is the last item in the list: true. Item D.
Notice that both C and D think they are the last. The reason is that the
UIComponentClassicTagBase will find the components generated for A, B and C
during the findComponent call. It will only create a new component for D.
When D is created, it will pick up the new variable status map created by the
for each tag in its value expressions. Because when three earlier components
were build, C was the last item, and the variable status map in their value
expressions did not reflect any changes. D gets the correct values since it
was just created.
-
I propose to reduce any work required by page developers to implement the for
each loop with re-ordering support (avoid having to use immediate EL in the
ID attribute) and fix the issues above.
The proposal is that Trinidad Tag based components (those components created
by UIXComponentELTag) will be able to have key-based IDs automatically
generated as a result of being in a for each tag. So consider this example:
tr:forEach var=item items=#{bean.items} varStatus=vs
tr:inputText id=it1 value=#{item.value} partialSubmit=true /
tr:outputText id=ot1 value=Value is: #{item.value}
partialTriggers=it1_${vs.key} /
/tr:forEach
In this code, the IDs of the components would automatically pick up the item
key. The item key would be stored on the var status. For List this key would
simply be the index, for Map it would be the map key and CollectionModel
would use the row key. UIXComponentELTag could check to see if a parent tag
desires to alter the component IDs, which in this case, the for each would.
With that set, the tags would alter the component IDs to append the key. For
example, _ + key would be appended to each component ID (it1 would become
it1_A if the key were A).
The for each tag would set the key into the variable mapper so that, instead
of indexes, the key would be used to evaluate the EL with the limitation that
the key would
[jira] [Resolved] (TRINIDAD-1940) Problems with the tr:forEach
[
https://issues.apache.org/jira/browse/TRINIDAD-1940?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Robinson resolved TRINIDAD-1940.
---
Resolution: Fixed
Fix Version/s: 2.1.0-core
Fixed and provided a demo in trinidad-demo (since it is a JSP only tag at the
moment, I could not add it to trinidad-components-showcase). I also improved
the tag documentation and mention what is and what is not supported.
Problems with the tr:forEach
Key: TRINIDAD-1940
URL: https://issues.apache.org/jira/browse/TRINIDAD-1940
Project: MyFaces Trinidad
Issue Type: Bug
Components: Components
Affects Versions: 2.0.0-beta-1
Reporter: Andrew Robinson
Assignee: Andrew Robinson
Fix For: 2.1.0-core
The tr:forEach tag has issues when trying to use component references and
trying to keep the component state in sync with the items in a list. It also
does not support Maps like the c:forEach tag does.
I seek to improve the forEach tag in Trinidad, and propose that JSF/JSTL does
something similar so that user's can really use the for each tag without
issues. Some of the for each problems are described in my blog:
http://drewdev.blogspot.com/2008/08/cforeach-with-jsf-could-ruin-your-day.html
I propose to address each of the issues with the JSP tag.
First, reliable component references:
tr:forEach var=item items=#{myBean.items}
tr:panelGroupLayout id=pgl1 layout=horizontal
tr:inputText id=it1 label=Enter value: value=#{item.text}
autoSubmit=true /
tr:outputText id=ot1 value=Value is: #{item.text}
partialTriggers=it1 /
/tr:panelGroupLayout
/tr:forEach
The problem is that the author intended the output text component to
partially updated by the sibling input text when it changed value, but that
is not the result. Instead, the partial triggers is always it1, but the
generated input text components are ot1, ot1j_id_1 and ot1j_id_2. The
result is that the output text components all partially update only when the
first input text is changed.
Another problem is that the indexed value expressions and the var status map
that is put into the variable mapper by the for each loop is static. Take
the following example:
tr:panelGroupLayout id=pgl1 layout=scroll
tr:forEach var=item items=#{myBean.items} varStatus=vs
tr:outputText id=ot1 value=This is the last item in the list:
#{vs.last}. Item #{item.text}. /
/tr:forEach
/tr:panelGroupLayout
Say during the first pass, the items in the list are A, B and C and the page
would look like this:
This is the last item in the list: false. Item A.
This is the last item in the list: false. Item B.
This is the last item in the list: true. Item C.
Now, consider what the output would be if someone added an object D to the
end of the list during invoke application:
This is the last item in the list: false. Item A.
This is the last item in the list: false. Item B.
This is the last item in the list: true. Item C.
This is the last item in the list: true. Item D.
Notice that both C and D think they are the last. The reason is that the
UIComponentClassicTagBase will find the components generated for A, B and C
during the findComponent call. It will only create a new component for D.
When D is created, it will pick up the new variable status map created by the
for each tag in its value expressions. Because when three earlier components
were build, C was the last item, and the variable status map in their value
expressions did not reflect any changes. D gets the correct values since it
was just created.
-
I propose to reduce any work required by page developers to implement the for
each loop with re-ordering support (avoid having to use immediate EL in the
ID attribute) and fix the issues above.
The proposal is that Trinidad Tag based components (those components created
by UIXComponentELTag) will be able to have key-based IDs automatically
generated as a result of being in a for each tag. So consider this example:
tr:forEach var=item items=#{bean.items} varStatus=vs
tr:inputText id=it1 value=#{item.value} partialSubmit=true /
tr:outputText id=ot1 value=Value is: #{item.value}
partialTriggers=it1_${vs.key} /
/tr:forEach
In this code, the IDs of the components would automatically pick up the item
key. The item key would be stored on the var status. For List this key would
simply be the index, for Map it would be the map key and CollectionModel
would use the row key. UIXComponentELTag could check to see if a parent tag
desires to alter the component IDs, which in this case, the for each would.
With that set, the tags would alter the component IDs to append the key. For
example, _ + key would be appended to each component ID (it1 would become
[jira] [Resolved] (TRINIDAD-2318) Support EL embedded in a literal partialTriggers attribute
[
https://issues.apache.org/jira/browse/TRINIDAD-2318?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Robinson resolved TRINIDAD-2318.
---
Resolution: Fixed
Fix Version/s: 2.1.0-core
Support EL embedded in a literal partialTriggers attribute
--
Key: TRINIDAD-2318
URL: https://issues.apache.org/jira/browse/TRINIDAD-2318
Project: MyFaces Trinidad
Issue Type: Bug
Components: Components
Affects Versions: 2.0.1-core
Reporter: Andrew Robinson
Assignee: Andrew Robinson
Fix For: 2.1.0-core
In order to allow users to put EL inside of partial triggers attributes, we
should convert any strings to string arrays for this attribute by wrapping
any value expressions assigned in the tag. This will allow for values like:
tr:outputText partialTriggers=inputText_#{vs.key} /
This is needed to help users with partial triggers and the for each loop with
the work being done in TRINIDAD-1940.
--
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] [Created] (TRINIDAD-2319) Panel popup renderer breaks rendering of the command button
Andrew Robinson created TRINIDAD-2319: - Summary: Panel popup renderer breaks rendering of the command button Key: TRINIDAD-2319 URL: https://issues.apache.org/jira/browse/TRINIDAD-2319 Project: MyFaces Trinidad Issue Type: Bug Components: Components Affects Versions: 2.1.0-core Reporter: Andrew Robinson Priority: Critical If you put a command button in a panel popup, the page will fail to render. The cause appears to be the popup using a renderer delegation to itself with an inner renderer. The result is an exception: Caused by: java.lang.AssertionError at org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.CommandButtonRenderer.encodeAll(CommandButtonRenderer.java:82) at org.apache.myfaces.trinidad.render.CoreRenderer.encodeEnd(CoreRenderer.java:511) at org.apache.myfaces.trinidad.component.UIXComponentBase.encodeEnd(UIXComponentBase.java:1082) at javax.faces.component.UIComponent.encodeAll(UIComponent.java:1786) at org.apache.myfaces.trinidad.render.CoreRenderer.encodeChild(CoreRenderer.java:624) at org.apache.myfaces.trinidad.render.CoreRenderer.encodeAllChildren(CoreRenderer.java:641) at org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.PanelPopupRenderer.encodeAll(PanelPopupRenderer.java:221) -- 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] [Resolved] (TRINIDAD-2319) Panel popup renderer breaks rendering of the command button
[ https://issues.apache.org/jira/browse/TRINIDAD-2319?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Robinson resolved TRINIDAD-2319. --- Resolution: Fixed Fix Version/s: 1.2.14-plugins Move the call to clear the rendering context client ID to before the encoding of the children Panel popup renderer breaks rendering of the command button --- Key: TRINIDAD-2319 URL: https://issues.apache.org/jira/browse/TRINIDAD-2319 Project: MyFaces Trinidad Issue Type: Bug Components: Components Affects Versions: 2.1.0-core Reporter: Andrew Robinson Priority: Critical Fix For: 1.2.14-plugins If you put a command button in a panel popup, the page will fail to render. Exception: Caused by: java.lang.AssertionError at org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.CommandButtonRenderer.encodeAll(CommandButtonRenderer.java:82) at org.apache.myfaces.trinidad.render.CoreRenderer.encodeEnd(CoreRenderer.java:511) at org.apache.myfaces.trinidad.component.UIXComponentBase.encodeEnd(UIXComponentBase.java:1082) at javax.faces.component.UIComponent.encodeAll(UIComponent.java:1786) at org.apache.myfaces.trinidad.render.CoreRenderer.encodeChild(CoreRenderer.java:624) at org.apache.myfaces.trinidad.render.CoreRenderer.encodeAllChildren(CoreRenderer.java:641) at org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.PanelPopupRenderer.encodeAll(PanelPopupRenderer.java:221) -- 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] [Created] (TRINIDAD-2320) Panel popup renderer breaks rendering of the command button if in the trigger
Andrew Robinson created TRINIDAD-2320: - Summary: Panel popup renderer breaks rendering of the command button if in the trigger Key: TRINIDAD-2320 URL: https://issues.apache.org/jira/browse/TRINIDAD-2320 Project: MyFaces Trinidad Issue Type: Bug Components: Components Affects Versions: 2.1.0-core Reporter: Andrew Robinson Priority: Critical Fix For: 2.1.0-core If you put a command button in a panel popup, the page will fail to render. Exception: Caused by: java.lang.AssertionError at org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.CommandButtonRenderer.encodeAll(CommandButtonRenderer.java:82) at org.apache.myfaces.trinidad.render.CoreRenderer.encodeEnd(CoreRenderer.java:511) at org.apache.myfaces.trinidad.component.UIXComponentBase.encodeEnd(UIXComponentBase.java:1082) at javax.faces.component.UIComponent.encodeAll(UIComponent.java:1786) at org.apache.myfaces.trinidad.render.CoreRenderer.encodeChild(CoreRenderer.java:624) at org.apache.myfaces.trinidad.render.CoreRenderer.encodeAllChildren(CoreRenderer.java:641) at org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.PanelPopupRenderer.encodeAll(PanelPopupRenderer.java:221) -- 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] [Resolved] (TRINIDAD-2320) Panel popup renderer breaks rendering of the command button if in the trigger
[ https://issues.apache.org/jira/browse/TRINIDAD-2320?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Robinson resolved TRINIDAD-2320. --- Resolution: Fixed Fix Version/s: 2.1.0-core Panel popup renderer breaks rendering of the command button if in the trigger - Key: TRINIDAD-2320 URL: https://issues.apache.org/jira/browse/TRINIDAD-2320 Project: MyFaces Trinidad Issue Type: Bug Components: Components Affects Versions: 2.1.0-core Reporter: Andrew Robinson Priority: Critical Fix For: 2.1.0-core If you put a command button in a panel popup trigger facet, the page will fail to render due to the client ID still being saved on the rendering context -- 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] [Created] (TRINIDAD-2321) Panel popup does not close if it is open during a PPR that replaces the component's HTML
Andrew Robinson created TRINIDAD-2321: - Summary: Panel popup does not close if it is open during a PPR that replaces the component's HTML Key: TRINIDAD-2321 URL: https://issues.apache.org/jira/browse/TRINIDAD-2321 Project: MyFaces Trinidad Issue Type: Bug Components: Components Affects Versions: 2.1.0-core Reporter: Andrew Robinson If you open a panel popup and PPR the parent of the panel popup, the popup remains open. It should close since it has been replaced. -- 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] [Commented] (TRINIDAD-2321) Panel popup does not close if it is open during a PPR that replaces the component's HTML
[ https://issues.apache.org/jira/browse/TRINIDAD-2321?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13465939#comment-13465939 ] Andrew Robinson commented on TRINIDAD-2321: --- The other alternative is that the popup remains open but its content is updated, but either way right now the content will remain old. Panel popup does not close if it is open during a PPR that replaces the component's HTML Key: TRINIDAD-2321 URL: https://issues.apache.org/jira/browse/TRINIDAD-2321 Project: MyFaces Trinidad Issue Type: Bug Components: Components Affects Versions: 2.1.0-core Reporter: Andrew Robinson If you open a panel popup and PPR the parent of the panel popup, the popup remains open. It should close since it has been replaced. -- 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] [Created] (TRINIDAD-2323) ChangeManager does not apply changes that are added in the renderer response before phase
Andrew Robinson created TRINIDAD-2323: - Summary: ChangeManager does not apply changes that are added in the renderer response before phase Key: TRINIDAD-2323 URL: https://issues.apache.org/jira/browse/TRINIDAD-2323 Project: MyFaces Trinidad Issue Type: Bug Components: Components Affects Versions: 2.1.0-core Reporter: Andrew Robinson In order to re-order components for components that have not yet been built yet (ones that will be created by the JSP tags during the buildView call of the RENDER_RESPONSE phase), the change manager will not apply the changes for a ReorderChildrenComponentChange added at that time. Use case: For each loop on the page and the user wants to add a new item to the beginning of the iteration. Because the new component does not exist yet, the user uses f:view beforePhase=...EL... to have a callback. In tha callback, the backing bean adds a ReorderChildrenComponentChange to the change manager. That change will not be applied until the next request. The change should be applied immediately or at least after all of the phase listeners have been fired. Right now the changes are being applied at the end of the build view, but before the view phase listeners have been fired. The current alternative now is to not use the components to get the current IDs, but for the backing bean to know the IDs of the components before they are created and add the change during the INVOKE_APPLICATION phase -- 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] [Created] (TRINIDAD-2318) Support EL embedded in a literal partialTriggers attribute
Andrew Robinson created TRINIDAD-2318:
-
Summary: Support EL embedded in a literal partialTriggers attribute
Key: TRINIDAD-2318
URL: https://issues.apache.org/jira/browse/TRINIDAD-2318
Project: MyFaces Trinidad
Issue Type: Bug
Components: Build
Affects Versions: 2.0.7-plugins
Reporter: Andrew Robinson
Assignee: Andrew Robinson
In order to allow users to put EL inside of partial triggers attributes, we
should convert any strings to string arrays for this attribute by wrapping any
value expressions assigned in the tag. This will allow for values like:
tr:outputText partialTriggers=inputText_#{vs.key} /
This is needed to help users with partial triggers and the for each loop with
the work being done in TRINIDAD-1940.
--
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] [Reopened] (TRINIDAD-1940) Problems with the tr:forEach
[
https://issues.apache.org/jira/browse/TRINIDAD-1940?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Robinson reopened TRINIDAD-1940:
---
Re-opening. The issue I was having appears to be a myfaces-core issue, not a
general issue
Problems with the tr:forEach
Key: TRINIDAD-1940
URL: https://issues.apache.org/jira/browse/TRINIDAD-1940
Project: MyFaces Trinidad
Issue Type: Bug
Components: Components
Affects Versions: 2.0.0-beta-1
Reporter: Andrew Robinson
Assignee: Andrew Robinson
The tr:forEach tag has issues when trying to use component references and
trying to keep the component state in sync with the items in a list. It also
does not support Maps like the c:forEach tag does.
I seek to improve the forEach tag in Trinidad, and propose that JSF/JSTL does
something similar so that user's can really use the for each tag without
issues. Some of the for each problems are described in my blog:
http://drewdev.blogspot.com/2008/08/cforeach-with-jsf-could-ruin-your-day.html
I propose to address each of the issues with the JSP tag.
First, reliable component references:
tr:forEach var=item items=#{myBean.items}
tr:panelGroupLayout id=pgl1 layout=horizontal
tr:inputText id=it1 label=Enter value: value=#{item.text}
autoSubmit=true /
tr:outputText id=ot1 value=Value is: #{item.text}
partialTriggers=it1 /
/tr:panelGroupLayout
/tr:forEach
The problem is that the author intended the output text component to
partially updated by the sibling input text when it changed value, but that
is not the result. Instead, the partial triggers is always it1, but the
generated input text components are ot1, ot1j_id_1 and ot1j_id_2. The
result is that the output text components all partially update only when the
first input text is changed.
Another problem is that the indexed value expressions and the var status map
that is put into the variable mapper by the for each loop is static. Take
the following example:
tr:panelGroupLayout id=pgl1 layout=scroll
tr:forEach var=item items=#{myBean.items} varStatus=vs
tr:outputText id=ot1 value=This is the last item in the list:
#{vs.last}. Item #{item.text}. /
/tr:forEach
/tr:panelGroupLayout
Say during the first pass, the items in the list are A, B and C and the page
would look like this:
This is the last item in the list: false. Item A.
This is the last item in the list: false. Item B.
This is the last item in the list: true. Item C.
Now, consider what the output would be if someone added an object D to the
end of the list during invoke application:
This is the last item in the list: false. Item A.
This is the last item in the list: false. Item B.
This is the last item in the list: true. Item C.
This is the last item in the list: true. Item D.
Notice that both C and D think they are the last. The reason is that the
UIComponentClassicTagBase will find the components generated for A, B and C
during the findComponent call. It will only create a new component for D.
When D is created, it will pick up the new variable status map created by the
for each tag in its value expressions. Because when three earlier components
were build, C was the last item, and the variable status map in their value
expressions did not reflect any changes. D gets the correct values since it
was just created.
-
I propose to reduce any work required by page developers to implement the for
each loop with re-ordering support (avoid having to use immediate EL in the
ID attribute) and fix the issues above.
The proposal is that Trinidad Tag based components (those components created
by UIXComponentELTag) will be able to have key-based IDs automatically
generated as a result of being in a for each tag. So consider this example:
tr:forEach var=item items=#{bean.items} varStatus=vs
tr:inputText id=it1 value=#{item.value} partialSubmit=true /
tr:outputText id=ot1 value=Value is: #{item.value}
partialTriggers=it1_${vs.key} /
/tr:forEach
In this code, the IDs of the components would automatically pick up the item
key. The item key would be stored on the var status. For List this key would
simply be the index, for Map it would be the map key and CollectionModel
would use the row key. UIXComponentELTag could check to see if a parent tag
desires to alter the component IDs, which in this case, the for each would.
With that set, the tags would alter the component IDs to append the key. For
example, _ + key would be appended to each component ID (it1 would become
it1_A if the key were A).
The for each tag would set the key into the variable mapper so that, instead
of indexes, the key would be used to evaluate the EL with the limitation that
the key would be the index for List
[jira] [Commented] (TRINIDAD-2271) The immediate child element of fmd:global-metadata, javaee:property-extension mfp:component-metadata is not copied over
[ https://issues.apache.org/jira/browse/TRINIDAD-2271?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13289481#comment-13289481 ] Andrew Robinson commented on TRINIDAD-2271: --- Patch requires ASF grant to be allowed The immediate child element of fmd:global-metadata, javaee:property-extension mfp:component-metadata is not copied over --- Key: TRINIDAD-2271 URL: https://issues.apache.org/jira/browse/TRINIDAD-2271 Project: MyFaces Trinidad Issue Type: Bug Components: Build, Plugins Reporter: Arjun Vade Attachments: 13490529.patch Our transform20.xsl permits unknown namespaced elements under property-extension, global-metadata and component-metadata. While copying these unknown namespace elements, the immediate child element of these above mentioned nodes is left out and only sub-children nodes are copied over. E.g. In transform20.xsl, we have this code xsl:template match=fmd:global-metadata/*[ namespace-uri() != 'http://java.sun.com/xml/ns/javaee' and namespace-uri() !='http://myfaces.apache.org/maven-faces-plugin' and namespace-uri() !='http://java.sun.com/xml/ns/javaee/faces/design-time-metadata'] xsl:copy-of select=*/ /xsl:template With fmd:global-metadata/* we are already referring to child element of fmd:global-metadata. And then when we select * in xsl:copy-of select=*/, we are copying over the child of the child. Thus, the immediate child element of global-metadata element is left out. The fix is to replace * with . in xsl:copy-of select=*/ -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TRINIDAD-2271) The immediate child element of fmd:global-metadata, javaee:property-extension mfp:component-metadata is not copied over
[ https://issues.apache.org/jira/browse/TRINIDAD-2271?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Robinson updated TRINIDAD-2271: -- Resolution: Fixed Fix Version/s: 2.0.8-plugins Status: Resolved (was: Patch Available) The immediate child element of fmd:global-metadata, javaee:property-extension mfp:component-metadata is not copied over --- Key: TRINIDAD-2271 URL: https://issues.apache.org/jira/browse/TRINIDAD-2271 Project: MyFaces Trinidad Issue Type: Bug Components: Build, Plugins Reporter: Arjun Vade Fix For: 2.0.8-plugins Attachments: 13490529.patch Our transform20.xsl permits unknown namespaced elements under property-extension, global-metadata and component-metadata. While copying these unknown namespace elements, the immediate child element of these above mentioned nodes is left out and only sub-children nodes are copied over. E.g. In transform20.xsl, we have this code xsl:template match=fmd:global-metadata/*[ namespace-uri() != 'http://java.sun.com/xml/ns/javaee' and namespace-uri() !='http://myfaces.apache.org/maven-faces-plugin' and namespace-uri() !='http://java.sun.com/xml/ns/javaee/faces/design-time-metadata'] xsl:copy-of select=*/ /xsl:template With fmd:global-metadata/* we are already referring to child element of fmd:global-metadata. And then when we select * in xsl:copy-of select=*/, we are copying over the child of the child. Thus, the immediate child element of global-metadata element is left out. The fix is to replace * with . in xsl:copy-of select=*/ -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TRINIDAD-2240) Add new namespace declaration http://xmlns.oracle.com/bali/xml/faces-metadata-extension at root element
[ https://issues.apache.org/jira/browse/TRINIDAD-2240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13228926#comment-13228926 ] Andrew Robinson commented on TRINIDAD-2240: --- I would like to know why this is needed in Trinidad, and how this adds value to MyFaces by doing so. If Oracle wishes to add information to their own XML files, then they can extend or fork the Trinidad plug-ins, but we should not be introducing 3rd party code into Trinidad that does not benefit the entire community. Add new namespace declaration http://xmlns.oracle.com/bali/xml/faces-metadata-extension; at root element - Key: TRINIDAD-2240 URL: https://issues.apache.org/jira/browse/TRINIDAD-2240 Project: MyFaces Trinidad Issue Type: Task Components: Build Reporter: Arjun Vade Attachments: 8248475_trinidad-maven.patch Need to introduce a new namespace declaration http://xmlns.oracle.com/bali/xml/faces-metadata-extension; at root element. This new namespace is required for JDeveloper. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TRINIDAD-2230) adjustments to the UIXComponentBase subscribeToEvent and unsubscribeFromEvent implementation
[ https://issues.apache.org/jira/browse/TRINIDAD-2230?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Robinson updated TRINIDAD-2230: -- Resolution: Fixed Fix Version/s: 2.0.2-core Status: Resolved (was: Patch Available) adjustments to the UIXComponentBase subscribeToEvent and unsubscribeFromEvent implementation Key: TRINIDAD-2230 URL: https://issues.apache.org/jira/browse/TRINIDAD-2230 Project: MyFaces Trinidad Issue Type: Bug Components: Components Affects Versions: 2.0.1-core Environment: n/a Reporter: Gary VanMatre Fix For: 2.0.2-core Attachments: UIXComponentBase.patch These new JSF 2 methods on the UIComponent (subscribeToEvent and unsubscribeFromEvent) has a very strange contract. The formal parameter for the listener is of type ComponentSystemEventListener. However, the method to query for the registered listeners getListenersForEventClass returns a list of SystemEventListener. The ComponentSystemEventListener and SystemEventListener do not have a common heritage so the subscribeToEvent and unsubscribeFromEvent creates a wrapper that implements the SystemEventListener. Since the resultant objects from getListenersForEventClass are a wrapper, there is no way to determine if the original listener added by calling subscribeToEvent is in the list of wrapper objects since the wrapper is a private nested class and doesn't necessary implement the ComponentSystemEventListener interfaces. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [VOTE] Release of Trinidad 2.0.1
+1 On Fri, Feb 24, 2012 at 8:17 AM, Mark Struberg strub...@yahoo.de wrote: Hi Scott! While checking the release I also scanned the other stuff and the rest looks good. sorry for the inconvenience... LieGrue, strub - Original Message - From: Scott O'Bryan darkar...@gmail.com To: MyFaces Development dev@myfaces.apache.org Cc: Sent: Friday, February 24, 2012 3:49 PM Subject: Re: [VOTE] Release of Trinidad 2.0.1 I stand corrected, it IS in there. :D We've had those repos in there forever. Anyway, thanks Mark. So I've checked in the changes you requested to the latest tag and set up the rat audit tool to run as part of the standard build so we don't hit this issue again. Can you do me a favor and check the tag to make sure it looks good and then I'll promote it to the repository and start over the vote. Thanks,  Scott On Fri 24 Feb 2012 06:56:50 AM MST, Scott O'Bryan wrote:  I'm not sure I agree with this. In the case of java.net, removing the  invalid repo is a fair assessment, but I'm unaware of any rules in  maven-central that says build artifacts cannot be pulled in from other  repositories. Am I missing something here?  That said, I didn't have time yesterday to investigate the problem.  It might just be a simple Geronimo dep issue. I have a few mins to  look at this. Hopefully it's not a difficult problem.  Sent from my iPhone  On Feb 24, 2012, at 6:33 AM, Mark Strubergstrub...@yahoo.de wrote:  Hi Scott!  As for the repositories, I removed them and now seem to be getting an  error during testing.  Well, doesn't that mean that the source repository doesn't properly build?  Also, such artifacts should not get propagated to maven.central as per it's policies.  If you need help with the repo stuff then please ping me on IRC and I'll help.  LieGrue,  strub  - Original Message -  From: Scott O'Bryandarkar...@gmail.com  To: MyFaces Developmentdev@myfaces.apache.org  Cc:  Sent: Friday, February 24, 2012 2:07 PM  Subject: Re: [VOTE] Release of Trinidad 2.0.1  Okay Marc, I fixed rat and the few license headers we have. It will  now also run automagically as part of the Trinidad build so we can  catch these sooner.  As for the repositories, I removed them and now seem to be getting an  error during testing. I guess my question is this, since we don't  distribute any jboss code with the product, is the repository issue  still a blocker or can it be handled as a bug next release?  Scott  Sent from my iPhone  On Feb 23, 2012, at 7:07 AM, Mark Strubergstrub...@yahoo.de wrote:  Hi!  I'm really sorry, but I fear I have to cast a  -1 :(  A few smallish but imo important things which I found during the review:  1.)    repositories     !-- needed for Bean Validation API --     repository      idjboss/id      namejboss nexus/name urlhttp://repository.jboss.org/nexus/content/groups/public-jboss//url     /repository     !-- Needed for Mojarra --     repository      idmaven2-repository.dev.java.net/id      nameJava.net Repository for Maven/name urlhttp://download.java.net/maven/2//url     /repository    /repositories  is this really needed?  please the geronimo-spec jar for JSR-303 and Apache BVal instead.  the java.net repo is btw dead already... All mojarra artifacts are  available on maven.central  Artifacts with a dead repo in it should definitely not get propagated to  maven.central!  2.) please run mvn apache-rat:check  The following files misses an ALv2 header: trinidad-build/src/main/resources/META-INF/maven-faces-plugin/Global.xml trinidad-api/src/main/conf/META-INF/myfaces-core-2_0-metadata.xml trinidad-impl/src/test/resources/org/apache/myfaces/trinidadinternal/renderkit/testScripts/  contains a lot of stuff, but this should get excluded as they are only test  resources.  Please add the apache-rat plugin to the build and fix the missing headers  or tweak the excludes until the build runs fine.  LieGrue,  strub  - Original Message -  From: Andy Schwartzandy.g.schwa...@gmail.com  To: MyFaces Developmentdev@myfaces.apache.org  Cc:  Sent: Thursday, February 23, 2012 1:31 PM  Subject: Re: [VOTE] Release of Trinidad 2.0.1  +1  Andy  On Feb 22, 2012, at 12:18 AM, Scott O'Bryan  darkar...@gmail.com  wrote:  Hi Everyone,  I was running the tasks needed to get the Trinidad 2.0.1 release  out and  now I need a vote as to whether everything looks good or not. I have  committed  most of the most recent submitted patches and things look to be fairly  stable.  There are a few patches outstanding, but I wanted to put those into  trunk so  that they can get some more testing.  This is a very big release with many bug fixes and quite a few  fixes to  support the MyFaces checkstyle audits. You will notice the absence of  the  component showcase example
Re: [VOTE] Trinidad 2.0.1 (try 2)
+1 On Mon, Feb 27, 2012 at 9:22 AM, Grant Smith work.gr...@gmail.com wrote: +1 On Mon, Feb 27, 2012 at 8:18 AM, Matt Cooper mcoo...@apache.org wrote: +1 On Sat, Feb 25, 2012 at 7:46 PM, Blake Sullivan blake.sulli...@oracle.com wrote: +1 -- Blake Sullivan On Feb 25, 2012, at 3:36 AM, Andy Schwartz wrote: +1. Thanks for putting this together Scott. Andy On Feb 24, 2012, at 12:30 PM, Scott O'Bryan darkar...@gmail.com wrote: Hi Everyone, I was running the tasks needed to get the Trinidad 2.0.1 release out and now I need a vote as to whether everything looks good or not. I have committed most of the most recent submitted patches and things look to be fairly stable. There are a few patches outstanding, but I wanted to put those into trunk so that they can get some more testing. This is a very big release with many bug fixes and quite a few fixes to support the MyFaces checkstyle audits. You will notice the absence of the component showcase example module. It was decided to remove this module because it contains code brought in by Maven which is NOT under the Apache license. The component showcase *IS* available by building the source manually. The last vote was vetoed because some files were missing licenses and there were some references to external repositories. The new staging repositories contain fixes for all of these issues including an enhancement to the base POM file which will automatically run the rat verifications at build to prevent the licensing issues in the future. At this time, I would like to ask for a vote, once again, on this release. All of the following should be ready for review: * The generated repository and assembly artifacts [1] * The generated source archive [2] * The updated svn repository [3] Please review the artifacts and vote according to the following: [ ] +1 for community members who have reviewed the bits [ ] +0 [ ] -1 for fatal flaws that should cause these bits not to be released,  and why.. This vote will remain open for at least 72 hours. Thanks,  Scott O'Bryan [1] https://repository.apache.org/content/repositories/orgapachemyfaces-067 [2] https://repository.apache.org/content/repositories/orgapachemyfaces-067/org/apache/myfaces/trinidad/trinidad/2.0.1/trinidad-2.0.1-source-release.zip [3] https://svn.apache.org/repos/asf/myfaces/trinidad/tags/trinidad-2.0.1/ -- Grant Smith - V.P. Information Technology Marathon Computer Systems, LLC.
[jira] [Created] (TRINIDAD-2214) VisitTree in UIXIterator causes reentrant calls to setupVisitingContext
VisitTree in UIXIterator causes reentrant calls to setupVisitingContext --- Key: TRINIDAD-2214 URL: https://issues.apache.org/jira/browse/TRINIDAD-2214 Project: MyFaces Trinidad Issue Type: Bug Components: Components Affects Versions: 2.0.2-core Reporter: Andrew Robinson Assignee: Andrew Robinson UIXIterator calls visitTree on the component being visiting, resulting in a second call to setupVisitingContext -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (TRINIDAD-2214) VisitTree in UIXIterator causes reentrant calls to setupVisitingContext
[ https://issues.apache.org/jira/browse/TRINIDAD-2214?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Robinson resolved TRINIDAD-2214. --- Resolution: Fixed Fix Version/s: 2.0.2-core VisitTree in UIXIterator causes reentrant calls to setupVisitingContext --- Key: TRINIDAD-2214 URL: https://issues.apache.org/jira/browse/TRINIDAD-2214 Project: MyFaces Trinidad Issue Type: Bug Components: Components Affects Versions: 2.0.2-core Reporter: Andrew Robinson Assignee: Andrew Robinson Fix For: 2.0.2-core UIXIterator calls visitTree on the component being visiting, resulting in a second call to setupVisitingContext -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (TRINIDAD-2203) UIXComponent does not check if in context when setupChildrenContext is called
[ https://issues.apache.org/jira/browse/TRINIDAD-2203?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Robinson resolved TRINIDAD-2203. --- Resolution: Fixed UIXComponent does not check if in context when setupChildrenContext is called - Key: TRINIDAD-2203 URL: https://issues.apache.org/jira/browse/TRINIDAD-2203 Project: MyFaces Trinidad Issue Type: Improvement Components: Components Affects Versions: 2.0.2-core Reporter: Andrew Robinson Assignee: Andrew Robinson Fix For: 2.0.2-core UIXComponent has methods: setupVisitingContext setupChildrenEncodingContext setupEncodingContext setupChildrenVisitingContext and the corresponding tear down methods. The problem is that there is no code that validates that these methods have not been called more than once at a time. For example, if a component overrides the setupChildrenEncodingContext with code, and that method is called more than once, it may cause issues. By adding boolean flags and simple checks with warnings to the LOG it would be much easier for component authors to determine where the issue is instead of just allowing, silently, the excessive calls to be made. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TRINIDAD-2205) Update mavin-faces-plugin to accept JSF 2.1 spec
[ https://issues.apache.org/jira/browse/TRINIDAD-2205?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Robinson updated TRINIDAD-2205: -- Resolution: Fixed Fix Version/s: 2.0.8-plugins Status: Resolved (was: Patch Available) Update mavin-faces-plugin to accept JSF 2.1 spec Key: TRINIDAD-2205 URL: https://issues.apache.org/jira/browse/TRINIDAD-2205 Project: MyFaces Trinidad Issue Type: Improvement Components: Build, Plugins Affects Versions: 2.0.8-plugins Reporter: Jeremy C. Hull Fix For: 2.0.8-plugins Attachments: jsfSpec21.diff, jsfSpec21.diff Original Estimate: 24h Remaining Estimate: 24h JsfVersion.java doesn't have enum property and associated accessors for JSF_21. GenerateFacesConfigMojo.java needs to handle 2.1 by loading new XSL for 2.1 Need a new XSL for 2.1 which extends the 2.0 XSL, but sets new version and XSD URI for JSF 2.1 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Reopened] (TRINIDAD-2203) UIXComponent does not check if in context when setupChildrenContext is called
[ https://issues.apache.org/jira/browse/TRINIDAD-2203?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Robinson reopened TRINIDAD-2203: --- Reopening as this causes false warnings with reentrant code and visitTree/invokeOnComponent. Since the current component is not notified that a nested component traversal (visitTree) is being made and the flags are no longer correct. UIXComponent does not check if in context when setupChildrenContext is called - Key: TRINIDAD-2203 URL: https://issues.apache.org/jira/browse/TRINIDAD-2203 Project: MyFaces Trinidad Issue Type: Improvement Components: Components Affects Versions: 2.0.2-core Reporter: Andrew Robinson Assignee: Andrew Robinson Fix For: 2.0.2-core UIXComponent has methods: setupVisitingContext setupChildrenEncodingContext setupEncodingContext setupChildrenVisitingContext and the corresponding tear down methods. The problem is that there is no code that validates that these methods have not been called more than once at a time. For example, if a component overrides the setupChildrenEncodingContext with code, and that method is called more than once, it may cause issues. By adding boolean flags and simple checks with warnings to the LOG it would be much easier for component authors to determine where the issue is instead of just allowing, silently, the excessive calls to be made. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TRINIDAD-2203) UIXComponent does not check if in context when setupChildrenContext is called
UIXComponent does not check if in context when setupChildrenContext is called - Key: TRINIDAD-2203 URL: https://issues.apache.org/jira/browse/TRINIDAD-2203 Project: MyFaces Trinidad Issue Type: Improvement Components: Components Affects Versions: 2.0.2-core Reporter: Andrew Robinson Assignee: Andrew Robinson UIXComponent has methods: setupVisitingContext setupChildrenEncodingContext setupEncodingContext setupChildrenVisitingContext and the corresponding tear down methods. The problem is that there is no code that validates that these methods have not been called more than once at a time. For example, if a component overrides the setupChildrenEncodingContext with code, and that method is called more than once, it may cause issues. By adding boolean flags and simple checks with warnings to the LOG it would be much easier for component authors to determine where the issue is instead of just allowing, silently, the excessive calls to be made. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (TRINIDAD-2203) UIXComponent does not check if in context when setupChildrenContext is called
[ https://issues.apache.org/jira/browse/TRINIDAD-2203?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Robinson resolved TRINIDAD-2203. --- Resolution: Fixed Fix Version/s: 2.0.2-core UIXComponent does not check if in context when setupChildrenContext is called - Key: TRINIDAD-2203 URL: https://issues.apache.org/jira/browse/TRINIDAD-2203 Project: MyFaces Trinidad Issue Type: Improvement Components: Components Affects Versions: 2.0.2-core Reporter: Andrew Robinson Assignee: Andrew Robinson Fix For: 2.0.2-core UIXComponent has methods: setupVisitingContext setupChildrenEncodingContext setupEncodingContext setupChildrenVisitingContext and the corresponding tear down methods. The problem is that there is no code that validates that these methods have not been called more than once at a time. For example, if a component overrides the setupChildrenEncodingContext with code, and that method is called more than once, it may cause issues. By adding boolean flags and simple checks with warnings to the LOG it would be much easier for component authors to determine where the issue is instead of just allowing, silently, the excessive calls to be made. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TRINIDAD-2200) Allow non-http://java.sun.com/xml/ns/javaee/faces/design-time-metadata namespaced elements in the global-metadata
Allow non-http://java.sun.com/xml/ns/javaee/faces/design-time-metadata; namespaced elements in the global-metadata --- Key: TRINIDAD-2200 URL: https://issues.apache.org/jira/browse/TRINIDAD-2200 Project: MyFaces Trinidad Issue Type: Improvement Components: Build Affects Versions: 2.0.8-plugins Reporter: Andrew Robinson Assignee: Andrew Robinson Our transform20.xsl permits unknown namespaced elements under property-extension and facet-extension, but not faces-config-extension/fmd:global-metadata. It would be helpful to certain IDEs and frameworks built on Trinidad to allow for additional elements to be supported in the same way that they are supported by property-extension and facet-extension. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TRINIDAD-2193) Add CSS3 gradients validation support
[ https://issues.apache.org/jira/browse/TRINIDAD-2193?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Robinson updated TRINIDAD-2193: -- Resolution: Fixed Fix Version/s: 2.0.2-core Status: Resolved (was: Patch Available) Add CSS3 gradients validation support - Key: TRINIDAD-2193 URL: https://issues.apache.org/jira/browse/TRINIDAD-2193 Project: MyFaces Trinidad Issue Type: Improvement Components: Skinning Affects Versions: 2.0.1-core Reporter: Anand V Nath Fix For: 2.0.2-core Attachments: jira-2193.patch Currently we warn about usage of CSS3 gradient syntax in skin files. -moz-linear-gradient -webkit-linear-gradient radial-gradient linear-gradient repeating-linear-gradient repeating-radial-gradient Rendering is not affected, but these warnings can be removed. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [TRINIDAD] Switch of trinidad-maven trunks
Thanks for fixing this Scott. On Thu, Dec 22, 2011 at 11:18 AM, Scott O'Bryan darkar...@gmail.com wrote: Quite a few months back, the MyFaces community voted to make Trinidad 2.0.x the trunk. Â Unfortunately this work was never completed and the trinidad-maven plugin branches never changed over. Â I went ahead and finally fixed this, so the changes are below. trinidad-maven/trunk - trinidad-maven/branches/trinidad-maven-1.2.x trinidad-maven/branches/2.0.x-branch - trinidad-maven/trunk This moves the source for the trinidad plugins inline with the trinidad main codeline. Â If anyone has local branches parented to one of these code lines, simply reparent them to these new directories. Thanks, Â Scott
[jira] [Resolved] (TRINIDAD-2150) iOS versions prior to 4.3 are not pulling in the new touchScreen capability
[ https://issues.apache.org/jira/browse/TRINIDAD-2150?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Robinson resolved TRINIDAD-2150. --- Resolution: Fixed Fix Version/s: 2.0.2-core iOS versions prior to 4.3 are not pulling in the new touchScreen capability --- Key: TRINIDAD-2150 URL: https://issues.apache.org/jira/browse/TRINIDAD-2150 Project: MyFaces Trinidad Issue Type: Bug Components: Components Affects Versions: 2.0.2-core Reporter: Andrew Robinson Assignee: Andrew Robinson Fix For: 2.0.2-core Due to the version matching I added in the capabilities.xml, webkit versions prior to 533 (iOS 4.3) are not being recognized as touchScreen devices. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TRINIDAD-2108) Add touch capability to the agent API to be able to determine agents that are touch screen based.
[ https://issues.apache.org/jira/browse/TRINIDAD-2108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13173680#comment-13173680 ] Andrew Robinson commented on TRINIDAD-2108: --- Note that I just just removed the patch since I forgot to grant the usage. I did not apply the patch, but rather just made the changes and commit them myself. I can upload it again if that would make any feel more comfortable Add touch capability to the agent API to be able to determine agents that are touch screen based. - Key: TRINIDAD-2108 URL: https://issues.apache.org/jira/browse/TRINIDAD-2108 Project: MyFaces Trinidad Issue Type: Improvement Components: Components Affects Versions: 2.0.1-core Reporter: Andrew Robinson Assignee: Andrew Robinson Priority: Minor Fix For: 2.0.1-core There is currently no means to tell from the Agent that it has a touch screen or not to know if a component may need to use touch* events on the client as opposed to mouse* events. It would be nice to have such a capability for identifying Android and iOS as touch screen devices. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TRINIDAD-2158) NodeIterator iterates the colection more no of times than the size of the collection.
[ https://issues.apache.org/jira/browse/TRINIDAD-2158?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Robinson updated TRINIDAD-2158: -- Resolution: Fixed Fix Version/s: 2.0.2-core Status: Resolved (was: Patch Available) NodeIterator iterates the colection more no of times than the size of the collection. - Key: TRINIDAD-2158 URL: https://issues.apache.org/jira/browse/TRINIDAD-2158 Project: MyFaces Trinidad Issue Type: Bug Components: Components Affects Versions: 2.0.2-core Reporter: Paresh Kumar Acharya Fix For: 2.0.2-core Attachments: Bug13355971.patch, trunk.patch, trunk.patch The class org.apache.myfaces.trinidad.model.RowKeySetTreeImpl contains two Iterator Implementations PathIterator and NodeIterator. When the NodeIterator is used interanally to iterate the selected Tree or TreeTable nodes(rows), the iterator iterates more no of times than the total number of the slected nodes(rows). The iterator.next() returns the same node(row) more than once. This issue occurs because of the follwoing 2 reasons. 1) The currentIterator instance is not updated by taking the next iterator from the iteratorStack when one node completeley iterator. 2) Even when a node doesn't have any child nodes, iterator instances are created and pushed to the iteratorStack. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (TRINIDAD-2174) CSS parsing for skins does not currently allow comments inside @ rules
[
https://issues.apache.org/jira/browse/TRINIDAD-2174?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Robinson resolved TRINIDAD-2174.
---
Resolution: Fixed
Fix Version/s: 2.0.2-core
CSS parsing for skins does not currently allow comments inside @ rules
--
Key: TRINIDAD-2174
URL: https://issues.apache.org/jira/browse/TRINIDAD-2174
Project: MyFaces Trinidad
Issue Type: Improvement
Components: Components
Affects Versions: 2.0.2-core
Reporter: Andrew Robinson
Assignee: Andrew Robinson
Priority: Minor
Fix For: 2.0.2-core
The Trinidad Skin CSS parser currently does not handle comments in @ rules.
Example:
@agent gecko /* COMMENT */
{
CustomGeckoStyle
{
color:Aqua;
}
}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TRINIDAD-2174) CSS parsing for skins does not currently allow comments inside @ rules
CSS parsing for skins does not currently allow comments inside @ rules
--
Key: TRINIDAD-2174
URL: https://issues.apache.org/jira/browse/TRINIDAD-2174
Project: MyFaces Trinidad
Issue Type: Improvement
Components: Components
Affects Versions: 2.0.2-core
Reporter: Andrew Robinson
Assignee: Andrew Robinson
Priority: Minor
The Trinidad Skin CSS parser currently does not handle comments in @ rules.
Example:
@agent gecko /* COMMENT */
{
CustomGeckoStyle
{
color:Aqua;
}
}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TRINIDAD-2168) The ComponentContextManager does not document when the stack is suspended/resumed
The ComponentContextManager does not document when the stack is suspended/resumed - Key: TRINIDAD-2168 URL: https://issues.apache.org/jira/browse/TRINIDAD-2168 Project: MyFaces Trinidad Issue Type: Bug Components: Documentation Reporter: Andrew Robinson Assignee: Andrew Robinson Priority: Minor The JavaDoc for ComponentContextManager does not state when the stack is suspend, it should mention that the stack is only suspended within the html:body, html:head and tr:document components. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (TRINIDAD-2168) The ComponentContextManager does not document when the stack is suspended/resumed
[ https://issues.apache.org/jira/browse/TRINIDAD-2168?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Robinson resolved TRINIDAD-2168. --- Resolution: Fixed Fix Version/s: 2.0.2-core The ComponentContextManager does not document when the stack is suspended/resumed - Key: TRINIDAD-2168 URL: https://issues.apache.org/jira/browse/TRINIDAD-2168 Project: MyFaces Trinidad Issue Type: Bug Components: Documentation Affects Versions: 2.0.2-core Reporter: Andrew Robinson Assignee: Andrew Robinson Priority: Minor Fix For: 2.0.2-core The JavaDoc for ComponentContextManager does not state when the stack is suspend, it should mention that the stack is only suspended within the html:body, html:head and tr:document components. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TRINIDAD-2154) processFlattenedChildren on several components is calling setupVisitingContext when encoding
processFlattenedChildren on several components is calling setupVisitingContext when encoding Key: TRINIDAD-2154 URL: https://issues.apache.org/jira/browse/TRINIDAD-2154 Project: MyFaces Trinidad Issue Type: Bug Components: Components Affects Versions: 2.0.2-core Reporter: Andrew Robinson Assignee: Andrew Robinson UIXIterator, UIXGroup, etc, (flattening components) are not checking to see if the component is being flattened for encoding. If so, it should be calling setupEncodingContext instead of setupVisitingContext -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (TRINIDAD-2154) processFlattenedChildren on several components is calling setupVisitingContext when encoding
[ https://issues.apache.org/jira/browse/TRINIDAD-2154?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Robinson resolved TRINIDAD-2154. --- Resolution: Fixed Fix Version/s: 2.0.2-core processFlattenedChildren on several components is calling setupVisitingContext when encoding Key: TRINIDAD-2154 URL: https://issues.apache.org/jira/browse/TRINIDAD-2154 Project: MyFaces Trinidad Issue Type: Bug Components: Components Affects Versions: 2.0.2-core Reporter: Andrew Robinson Assignee: Andrew Robinson Fix For: 2.0.2-core UIXIterator, UIXGroup, etc, (flattening components) are not checking to see if the component is being flattened for encoding. If so, it should be calling setupEncodingContext instead of setupVisitingContext -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TRINIDAD-2150) iOS versions prior to 4.3 are not pulling in the new touchScreen capability
iOS versions prior to 4.3 are not pulling in the new touchScreen capability --- Key: TRINIDAD-2150 URL: https://issues.apache.org/jira/browse/TRINIDAD-2150 Project: MyFaces Trinidad Issue Type: Bug Components: Components Affects Versions: 2.0.2-core Reporter: Andrew Robinson Assignee: Andrew Robinson Due to the version matching I added in the capabilities.xml, webkit versions prior to 533 (iOS 4.3) are not being recognized as touchScreen devices. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TRINIDAD-2111) skinning ability for tablet devices (ipad, iphone etc)
[ https://issues.apache.org/jira/browse/TRINIDAD-2111?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Robinson updated TRINIDAD-2111: -- Resolution: Fixed Status: Resolved (was: Patch Available) skinning ability for tablet devices (ipad, iphone etc) -- Key: TRINIDAD-2111 URL: https://issues.apache.org/jira/browse/TRINIDAD-2111 Project: MyFaces Trinidad Issue Type: New Feature Components: Skinning Reporter: Anand V Nath Assignee: Andrew Robinson Fix For: 2.0.1 Attachments: tri-code-07072011.patch, tri-code-07092011.patch, tri-code-24082011.patch, tri-doc-20110902.patch Skinning requirements for tablet devices are different from desktop. So it is desirable to have a skin hierarchy support for tablet devices. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TRINIDAD-2136) Disabled attribute in option element is not supported in IOS
[ https://issues.apache.org/jira/browse/TRINIDAD-2136?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Robinson updated TRINIDAD-2136: -- Resolution: Fixed Fix Version/s: 2.0.1 Status: Resolved (was: Patch Available) Applied the patch Disabled attribute in option element is not supported in IOS - Key: TRINIDAD-2136 URL: https://issues.apache.org/jira/browse/TRINIDAD-2136 Project: MyFaces Trinidad Issue Type: Bug Components: Components Affects Versions: 2.0.0 Environment: IOS Reporter: Bino Kohli Fix For: 2.0.1 Attachments: Trinidad_Bug_12928351.patch Original Estimate: 12h Remaining Estimate: 12h Disabled option , ie option disabled =disabled not supported on IOS , -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Reopened] (TRINIDAD-2111) skinning ability for tablet devices (ipad, iphone etc)
[ https://issues.apache.org/jira/browse/TRINIDAD-2111?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Robinson reopened TRINIDAD-2111: --- Assignee: Andrew Robinson Will be backing this out. After looking into this more, the separate renderkit for tablets is overkill and causes issues with people that have made custom skins. I am thinking that an extension to @agent in the CSS skin parser would be preferable. skinning ability for tablet devices (ipad, iphone etc) -- Key: TRINIDAD-2111 URL: https://issues.apache.org/jira/browse/TRINIDAD-2111 Project: MyFaces Trinidad Issue Type: New Feature Components: Skinning Reporter: Anand V Nath Assignee: Andrew Robinson Fix For: 2.0.1 Attachments: tri-code-07072011.patch Skinning requirements for tablet devices are different from desktop. So it is desirable to have a skin hierarchy support for tablet devices. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TRINIDAD-2111) skinning ability for tablet devices (ipad, iphone etc)
[ https://issues.apache.org/jira/browse/TRINIDAD-2111?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Robinson updated TRINIDAD-2111: -- Resolution: Fixed Fix Version/s: 2.0.1 Status: Resolved (was: Patch Available) Commit the patch skinning ability for tablet devices (ipad, iphone etc) -- Key: TRINIDAD-2111 URL: https://issues.apache.org/jira/browse/TRINIDAD-2111 Project: MyFaces Trinidad Issue Type: New Feature Components: Skinning Reporter: Anand V Nath Fix For: 2.0.1 Attachments: tri-code-07072011.patch Skinning requirements for tablet devices are different from desktop. So it is desirable to have a skin hierarchy support for tablet devices. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TRINIDAD-2108) Add touch capability to the agent API to be able to determine agents that are touch screen based.
[ https://issues.apache.org/jira/browse/TRINIDAD-2108?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Robinson updated TRINIDAD-2108: -- Resolution: Fixed Fix Version/s: 2.0.1 Status: Resolved (was: Patch Available) Add touch capability to the agent API to be able to determine agents that are touch screen based. - Key: TRINIDAD-2108 URL: https://issues.apache.org/jira/browse/TRINIDAD-2108 Project: MyFaces Trinidad Issue Type: Improvement Components: Components Affects Versions: 2.0.1 Reporter: Andrew Robinson Assignee: Andrew Robinson Priority: Minor Fix For: 2.0.1 Attachments: TRINIDAD-2108.patch There is currently no means to tell from the Agent that it has a touch screen or not to know if a component may need to use touch* events on the client as opposed to mouse* events. It would be nice to have such a capability for identifying Android and iOS as touch screen devices. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TRINIDAD-2108) Add touch capability to the agent API to be able to determine agents that are touch screen based.
[ https://issues.apache.org/jira/browse/TRINIDAD-2108?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Robinson updated TRINIDAD-2108: -- Status: Patch Available (was: Open) Add touch capability to the agent API to be able to determine agents that are touch screen based. - Key: TRINIDAD-2108 URL: https://issues.apache.org/jira/browse/TRINIDAD-2108 Project: MyFaces Trinidad Issue Type: Improvement Components: Components Affects Versions: 2.0.1 Reporter: Andrew Robinson Assignee: Andrew Robinson Priority: Minor There is currently no means to tell from the Agent that it has a touch screen or not to know if a component may need to use touch* events on the client as opposed to mouse* events. It would be nice to have such a capability for identifying Android and iOS as touch screen devices. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [TRINIDAD] Supporting touch capability
Here is a proposed patch: https://issues.apache.org/jira/secure/attachment/12482729/TRINIDAD-2108.patch Sorry for the odd diff, the svn EOL was not set to native for the capabilities.xml. I can add a none for all other browsers, but it appears that for the other capabilities, the none is not used, but instead the capability is simply not set and therefore null. On Mon, Jun 13, 2011 at 3:24 PM, Blake Sullivan blake.sulli...@oracle.comwrote: I think we should have one per device and we might eventually want to support some keyboard-related ones as well to include differences between real and various on-screen keyboards. -- Blake Sullivan On 6/13/11 10:52 AM, Andrew Robinson wrote: We could have it return constant strings of none, single and multiple if that would suit our needs. So my question is if we want one capability per-human interaction device or multiple? Option 1, one-per: 1. touchScreen capability 2. mouse capability 3. drawingPad capability Option 2, one that returns a set interactionDevices capability with touchScreen, mouse, drawingPad, etc. If using the former, we could have strings returned and not boolean (touchScreen could return multiTouch, singleTouch). Not sure how that would look for option 2 other than a MapString, String being returned, but that API seems a bit ugly to me with having to down-cast the capability value to a generic collection. Thoughts? On Mon, Jun 13, 2011 at 10:31 AM, Blake Sullivan blake.sulli...@oracle.com wrote: On 6/13/11 9:22 AM, Andrew Robinson wrote: https://issues.apache.org/jira/browse/TRINIDAD-2108 I am proposing to add a new Agent capability for touch devices. It would involve adding: static public final CapabilityKey CAP_TOUCH_SCREEN = CapabilityKey.getCapabilityKey(touchScreen, true); To org.apache.myfaces.trinidadinternal.agent.TrinidadAgent. And also adding the code to add this for the Andoid and iOS devices. Any comments? Name of the key sound reasonable to everyone? Thanks, Andrew I think that we want to consider the cases where the device supports both touch gestures and other input devices at the same time. So, it depends on the expected usage. Are consumers of this api supposed to use it to query whether the device could send them touch events, or are they expected to use it to determine whether the device is primarily touch? If it is for the first case, then I think we should expand the values to encompass the quality of the touch events. For example, is multi-touch supported? Anyway, we know from experience that we really don't want to ever add any boolean values. -- Blake Sullivan
[jira] [Created] (TRINIDAD-2108) Add touch capability to the agent API to be able to determine agents that are touch screen based.
Add touch capability to the agent API to be able to determine agents that are touch screen based. - Key: TRINIDAD-2108 URL: https://issues.apache.org/jira/browse/TRINIDAD-2108 Project: MyFaces Trinidad Issue Type: Improvement Components: Components Affects Versions: 2.0.1 Reporter: Andrew Robinson Assignee: Andrew Robinson Priority: Minor There is currently no means to tell from the Agent that it has a touch screen or not to know if a component may need to use touch* events on the client as opposed to mouse* events. It would be nice to have such a capability for identifying Android and iOS as touch screen devices. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[TRINIDAD] Supporting touch capability
https://issues.apache.org/jira/browse/TRINIDAD-2108 I am proposing to add a new Agent capability for touch devices. It would involve adding: static public final CapabilityKey CAP_TOUCH_SCREEN = CapabilityKey.getCapabilityKey(touchScreen, true); To org.apache.myfaces.trinidadinternal.agent.TrinidadAgent. And also adding the code to add this for the Andoid and iOS devices. Any comments? Name of the key sound reasonable to everyone? Thanks, Andrew
Re: [TRINIDAD] Supporting touch capability
We could have it return constant strings of none, single and multiple if that would suit our needs. So my question is if we want one capability per-human interaction device or multiple? Option 1, one-per: 1. touchScreen capability 2. mouse capability 3. drawingPad capability Option 2, one that returns a set interactionDevices capability with touchScreen, mouse, drawingPad, etc. If using the former, we could have strings returned and not boolean (touchScreen could return multiTouch, singleTouch). Not sure how that would look for option 2 other than a MapString, String being returned, but that API seems a bit ugly to me with having to down-cast the capability value to a generic collection. Thoughts? On Mon, Jun 13, 2011 at 10:31 AM, Blake Sullivan blake.sulli...@oracle.comwrote: On 6/13/11 9:22 AM, Andrew Robinson wrote: https://issues.apache.org/jira/browse/TRINIDAD-2108 I am proposing to add a new Agent capability for touch devices. It would involve adding: static public final CapabilityKey CAP_TOUCH_SCREEN = CapabilityKey.getCapabilityKey(touchScreen, true); To org.apache.myfaces.trinidadinternal.agent.TrinidadAgent. And also adding the code to add this for the Andoid and iOS devices. Any comments? Name of the key sound reasonable to everyone? Thanks, Andrew I think that we want to consider the cases where the device supports both touch gestures and other input devices at the same time. So, it depends on the expected usage. Are consumers of this api supposed to use it to query whether the device could send them touch events, or are they expected to use it to determine whether the device is primarily touch? If it is for the first case, then I think we should expand the values to encompass the quality of the touch events. For example, is multi-touch supported? Anyway, we know from experience that we really don't want to ever add any boolean values. -- Blake Sullivan
[jira] [Commented] (TRINIDAD-2108) Add touch capability to the agent API to be able to determine agents that are touch screen based.
[ https://issues.apache.org/jira/browse/TRINIDAD-2108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13048868#comment-13048868 ] Andrew Robinson commented on TRINIDAD-2108: --- static public final CapabilityKey CAP_TOUCH_SCREEN = CapabilityKey.getCapabilityKey(touchScreen, true); This capability would return null, single or multiple indicating no touch support, one finger or multiple simultaneous touches. Add touch capability to the agent API to be able to determine agents that are touch screen based. - Key: TRINIDAD-2108 URL: https://issues.apache.org/jira/browse/TRINIDAD-2108 Project: MyFaces Trinidad Issue Type: Improvement Components: Components Affects Versions: 2.0.1 Reporter: Andrew Robinson Assignee: Andrew Robinson Priority: Minor There is currently no means to tell from the Agent that it has a touch screen or not to know if a component may need to use touch* events on the client as opposed to mouse* events. It would be nice to have such a capability for identifying Android and iOS as touch screen devices. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (TRINIDAD-2101) Provide partial lifecycle hooks for UIXComponent implementations
[ https://issues.apache.org/jira/browse/TRINIDAD-2101?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Robinson resolved TRINIDAD-2101. --- Resolution: Fixed Fix Version/s: 2.0.1 Provide partial lifecycle hooks for UIXComponent implementations Key: TRINIDAD-2101 URL: https://issues.apache.org/jira/browse/TRINIDAD-2101 Project: MyFaces Trinidad Issue Type: Improvement Components: Components Affects Versions: 2.0.0 Reporter: Andrew Robinson Assignee: Andrew Robinson Fix For: 2.0.1 UIXSwitcher, UIXShowOne, and UIXShowDetailItem all short-circuit the lifecycle of their children, meaning that the partially decode, validate, update, visit, flatten, etc. their children components. Since it is a something that may be done in other components, I would like to enhance UIXComponentBase to provide a protected API to make this functionality common so that it is less error prone and easier to maintain going forward. The idea would be for the component to ask itself or its renderer (CoreRenderer support) to get the list of components to process for lifecycle methods. It would default to all the facets and the children. For the above components, they would override it to customize the list. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TRINIDAD-2101) Provide partial lifecycle hooks for UIXComponent implementations
Provide partial lifecycle hooks for UIXComponent implementations Key: TRINIDAD-2101 URL: https://issues.apache.org/jira/browse/TRINIDAD-2101 Project: MyFaces Trinidad Issue Type: Improvement Components: Components Affects Versions: 2.0.0 Reporter: Andrew Robinson Assignee: Andrew Robinson UIXSwitcher, UIXShowOne, and UIXShowDetailItem all short-circuit the lifecycle of their children, meaning that the partially decode, validate, update, visit, flatten, etc. their children components. Since it is a something that may be done in other components, I would like to enhance UIXComponentBase to provide a protected API to make this functionality common so that it is less error prone and easier to maintain going forward. The idea would be for the component to ask itself or its renderer (CoreRenderer support) to get the list of components to process for lifecycle methods. It would default to all the facets and the children. For the above components, they would override it to customize the list. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (TRINIDAD-2096) Change when the UIXCollection adds its component context change
[ https://issues.apache.org/jira/browse/TRINIDAD-2096?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Robinson resolved TRINIDAD-2096. --- Resolution: Fixed Fix Version/s: 2.0.1 Change when the UIXCollection adds its component context change --- Key: TRINIDAD-2096 URL: https://issues.apache.org/jira/browse/TRINIDAD-2096 Project: MyFaces Trinidad Issue Type: Improvement Components: Components Affects Versions: 2.0.0-beta-1 Reporter: Andrew Robinson Assignee: Andrew Robinson Fix For: 2.0.1 During my initial authoring of the UIXCollection component context change, it was possible for code that did not reset the row key back to its original value, to leave a context change dangling off of the stack. This causes issue with other components that use context changes. I am changing the code to only use the component context change when the component is being processed. This way it is sure to be cleaned up as a try/finally block would be feasible. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TRINIDAD-2096) Change when the UIXCollection adds its component context change
Change when the UIXCollection adds its component context change --- Key: TRINIDAD-2096 URL: https://issues.apache.org/jira/browse/TRINIDAD-2096 Project: MyFaces Trinidad Issue Type: Improvement Components: Components Affects Versions: 2.0.0-beta-1 Reporter: Andrew Robinson Assignee: Andrew Robinson During my initial authoring of the UIXCollection component context change, it was possible for code that did not reset the row key back to its original value, to leave a context change dangling off of the stack. This causes issue with other components that use context changes. I am changing the code to only use the component context change when the component is being processed. This way it is sure to be cleaned up as a try/finally block would be feasible. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Reopened] (TRINIDAD-2047) UIXCollection saves the stamp state when there is no stamp
[ https://issues.apache.org/jira/browse/TRINIDAD-2047?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Robinson reopened TRINIDAD-2047: --- The fix was an incorrect one. Due to my misunderstanding of the code due to a lack of comments, it seems that there is a valid reason why the non-stamped state is being saved as a stamped state. This is the only code that saves off the virgin state of the child components. My change is causing the nested state to not be cleared from the children components once the row key is set back to null (-1 row index). This is especially bad with nested collections, as the nested row stamp state object is not cleared and thus nested collections may end up sharing their stamp state across parent rows. UIXCollection saves the stamp state when there is no stamp -- Key: TRINIDAD-2047 URL: https://issues.apache.org/jira/browse/TRINIDAD-2047 Project: MyFaces Trinidad Issue Type: Bug Components: Components Affects Versions: 1.2.14-core , 2.0.0-beta-2 Reporter: Andrew Robinson Assignee: Andrew Robinson Fix For: 1.2.15-core , 2.0.0 UIXCollection in the preRowDataChange saves the current stamp state. The problem is that the code does not check to see if there is a current stamp. The result, is child components may not correctly function if they expect to be inside a valid stamp. What happens is that when the collection first sets its row key/index, the stamp state is saved for index -1 (row key null). Children components that assume that the collection is processing a stamp may error out. There should be no reason why the stamp state is being saved when there is no stamp. I have come across user's of our code where they are getting exceptions in their code as a result. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (TRINIDAD-2047) UIXCollection saves the stamp state when there is no stamp
[ https://issues.apache.org/jira/browse/TRINIDAD-2047?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Robinson resolved TRINIDAD-2047. --- Resolution: Fixed Fix Version/s: (was: 2.0.0) (was: 1.2.15-core ) 2.0.1 - backed out my previous change - added comments to the code to explain what it is actually doing - added a work-around to UIXTable to prevent the getCollectionModel() from being called during the saving of stamp state UIXCollection saves the stamp state when there is no stamp -- Key: TRINIDAD-2047 URL: https://issues.apache.org/jira/browse/TRINIDAD-2047 Project: MyFaces Trinidad Issue Type: Bug Components: Components Affects Versions: 1.2.14-core , 2.0.0-beta-2 Reporter: Andrew Robinson Assignee: Andrew Robinson Fix For: 2.0.1 UIXCollection in the preRowDataChange saves the current stamp state. The problem is that the code does not check to see if there is a current stamp. The result, is child components may not correctly function if they expect to be inside a valid stamp. What happens is that when the collection first sets its row key/index, the stamp state is saved for index -1 (row key null). Children components that assume that the collection is processing a stamp may error out. There should be no reason why the stamp state is being saved when there is no stamp. I have come across user's of our code where they are getting exceptions in their code as a result. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TRINIDAD-2092) panelTabbed does not switch to new tab
[ https://issues.apache.org/jira/browse/TRINIDAD-2092?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13025499#comment-13025499 ] Andrew Robinson commented on TRINIDAD-2092: --- You should not be using trh:head inside of tr:document. Just set tr:document's title attribute to set the title. You are probably getting duplicate CSS and JavaScript sent down and causing JS issues. panelTabbed does not switch to new tab -- Key: TRINIDAD-2092 URL: https://issues.apache.org/jira/browse/TRINIDAD-2092 Project: MyFaces Trinidad Issue Type: Bug Components: Facelets Affects Versions: 2.0.0-beta-2 Reporter: Ed Ruano The panelTabbed tag stops working when I use an h:outputText in the same page. The page below demonstrated this issues. If I remove or comment out the h:outputtext then everything starts working again. I am using glassfish 3.1 and trinidad 2.0.0 beta 2. I have seen this issue before when using facelets and could not resolve. This time I realized I had the panelTabbed working on a different project and started converging the projects until I found the item that made the difference. ?xml version='1.0' encoding='UTF-8' ? !DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Transitional//EN http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd; tr:document xmlns=http://www.w3.org/1999/xhtml; xmlns:tr=http://myfaces.apache.org/trinidad; xmlns:h=http://java.sun.com/jsf/html; xmlns:trh=http://myfaces.apache.org/trinidad/html; trh:head titleTab Test/title /trh:head tr:form h:outputText value=test/ tr:panelTabbed position=above tr:showDetailItem text=tab1 aa /tr:showDetailItem tr:showDetailItem text=tab2 bb /tr:showDetailItem tr:showDetailItem text=tab3 cc /tr:showDetailItem /tr:panelTabbed /tr:form /tr:document web.xml ?xml version=1.0 encoding=UTF-8? web-app version=3.0 xmlns=http://java.sun.com/xml/ns/javaee; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation=http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd; context-param param-namejavax.faces.PROJECT_STAGE/param-name param-valueDevelopment/param-value /context-param filter-mapping filter-nametrinidad/filter-name url-pattern*.xhtml/url-pattern /filter-mapping filter-mapping filter-nametrinidad/filter-name servlet-nameFaces Servlet/servlet-name /filter-mapping servlet servlet-nameFaces Servlet/servlet-name servlet-classjavax.faces.webapp.FacesServlet/servlet-class load-on-startup1/load-on-startup /servlet servlet-mapping servlet-nameFaces Servlet/servlet-name url-pattern*.xhtml/url-pattern url-pattern/faces/*/url-pattern url-pattern*.faces/url-pattern /servlet-mapping session-config session-timeout 30 /session-timeout /session-config welcome-file-list welcome-filefaces/index.xhtml/welcome-file /welcome-file-list context-param param-namejavax.faces.DEFAULT_SUFFIX/param-name param-value.xhtml/param-value /context-param context-param param-nameorg.apache.myfaces.trinidad.ENABLE_LIGHTWEIGHT_DIALOGS/param-name param-valuefalse/param-value /context-param !-- Temporary internal flag to set to enabled and test Optimized PPR -- context-param param-nameorg.apache.myfaces.trinidadinternal.ENABLE_PPR_OPTIMIZATION/param-name param-valuefalse/param-value /context-param context-param param-namejavax.faces.STATE_SAVING_METHOD/param-name param-valueclient/param-value !--param-valueserver/param-value-- /context-param !-- if you want to disable the behaviour completely -- context-param param-nameorg.apache.myfaces.ERROR_HANDLING/param-name param-valuefalse/param-value /context-param !-- if you are using myfaces + facelets don't forget to do this -- context-param param-namefacelets.DEVELOPMENT/param-name param-valuetrue/param-value /context-param context-param param-nameorg.apache.myfaces.trinidad.CACHE_VIEW_ROOT/param-name param-valuefalse/param-value /context-param !-- Temporarily disable partial state saving default until we make it work with Trinidad -- context-param param-namejavax.faces.PARTIAL_STATE_SAVING/param-name param-valuefalse/param-value /context-param !-- Facelets
Re: [VOTE] Release of Trinidad 2.0.0
Am I too late? +1 On Sat, Apr 16, 2011 at 12:10 PM, Bruno Aranda brunoara...@gmail.comwrote: +1 On 15 April 2011 09:51, Werner Punz werner.p...@gmail.com wrote: +1 Am 15.04.11 01:08, schrieb Scott O'Bryan: Hi Everyone, I was running the tasks needed to get the Trinidad 2.0.0 release out and now I need a vote as to whether everything looks good or not. I have committed the recent submitted patches available for this release and it has undergone some considerable testing. As per an email discussion [1], it was decided to take Trinidad out of beta and move it to an official release. Therefore, I would like to ask for a vote on this release. All of the following should be ready for review: * The generated repository and assembly artifacts [2] * The generated source archive [3] * The updated svn repository [4] Please review the artifacts and vote according to the following: [ ] +1 for community members who have reviewed the bits [ ] +0 [ ] -1 for fatal flaws that should cause these bits not to be released, and why.. This vote will remain open for at least 72 hours. Thanks, Scott O'Bryan [1] http://old.nabble.com/-Trinidad--Release-schedule-td31297285.html [2] https://repository.apache.org/content/repositories/orgapachemyfaces-094/ [3] https://repository.apache.org/content/repositories/orgapachemyfaces-094/org/apache/myfaces/trinidad/trinidad/2.0.0/trinidad-2.0.0-source-release.zip [4] https://svn.apache.org/repos/asf/myfaces/trinidad/tags/trinidad-2.0.0
Re: [Trinidad] Release schedule
I don't see that 2.0 is any less stable 1.2 at this point. I think we can probably remove the beta soon IMO. On Fri, Apr 1, 2011 at 11:02 AM, Scott O'Bryan darkar...@gmail.com wrote: Hey all, I think we're getting close to another release for Trinidad and I wanted to open up a discussion on how you think we're looking for a non-beta release. I know there is currently a lot of work on the trinidad code line right now so I was going to hold off on a release for another couple of weeks and I was hoping that, at that time, the Trinidad 2.0 code would be ready to move out of beta. If people still don't think it's ready, I can do another beta release after I check in some of the submitted patches but I think we're getting pretty close. Any opinions? Thanks, Scott O'Bryan
[jira] Created: (TRINIDAD-2053) UIXComponent's public static boolean visitChildren method swallows run time exceptions
UIXComponent's public static boolean visitChildren method swallows run time exceptions -- Key: TRINIDAD-2053 URL: https://issues.apache.org/jira/browse/TRINIDAD-2053 Project: MyFaces Trinidad Issue Type: Bug Components: Components Affects Versions: 2.0.0-beta-2 Reporter: Andrew Robinson Assignee: Andrew Robinson The public static boolean visitChildren method in UIXComponent catches run time exceptions, but forgets to re-throw them in the finally block, so that they are never reported. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (TRINIDAD-2053) UIXComponent's public static boolean visitChildren method swallows run time exceptions
[ https://issues.apache.org/jira/browse/TRINIDAD-2053?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Robinson resolved TRINIDAD-2053. --- Resolution: Fixed Fix Version/s: 2.0.0-beta-3 UIXComponent's public static boolean visitChildren method swallows run time exceptions -- Key: TRINIDAD-2053 URL: https://issues.apache.org/jira/browse/TRINIDAD-2053 Project: MyFaces Trinidad Issue Type: Bug Components: Components Affects Versions: 2.0.0-beta-2 Reporter: Andrew Robinson Assignee: Andrew Robinson Fix For: 2.0.0-beta-3 The public static boolean visitChildren method in UIXComponent catches run time exceptions, but forgets to re-throw them in the finally block, so that they are never reported. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (TRINIDAD-2047) UIXCollection saves the stamp state when there is no stamp
UIXCollection saves the stamp state when there is no stamp -- Key: TRINIDAD-2047 URL: https://issues.apache.org/jira/browse/TRINIDAD-2047 Project: MyFaces Trinidad Issue Type: Bug Components: Components Affects Versions: 2.0.0-beta-2, 1.2.14-core Reporter: Andrew Robinson Assignee: Andrew Robinson UIXCollection in the preRowDataChange saves the current stamp state. The problem is that the code does not check to see if there is a current stamp. The result, is child components may not correctly function if they expect to be inside a valid stamp. What happens is that when the collection first sets its row key/index, the stamp state is saved for index -1 (row key null). Children components that assume that the collection is processing a stamp may error out. There should be no reason why the stamp state is being saved when there is no stamp. I have come across user's of our code where they are getting exceptions in their code as a result. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (TRINIDAD-2047) UIXCollection saves the stamp state when there is no stamp
[ https://issues.apache.org/jira/browse/TRINIDAD-2047?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Robinson resolved TRINIDAD-2047. --- Resolution: Fixed Fix Version/s: 2.0.5-plugins 1.2.15-core UIXCollection saves the stamp state when there is no stamp -- Key: TRINIDAD-2047 URL: https://issues.apache.org/jira/browse/TRINIDAD-2047 Project: MyFaces Trinidad Issue Type: Bug Components: Components Affects Versions: 1.2.14-core , 2.0.0-beta-2 Reporter: Andrew Robinson Assignee: Andrew Robinson Fix For: 1.2.15-core , 2.0.5-plugins UIXCollection in the preRowDataChange saves the current stamp state. The problem is that the code does not check to see if there is a current stamp. The result, is child components may not correctly function if they expect to be inside a valid stamp. What happens is that when the collection first sets its row key/index, the stamp state is saved for index -1 (row key null). Children components that assume that the collection is processing a stamp may error out. There should be no reason why the stamp state is being saved when there is no stamp. I have come across user's of our code where they are getting exceptions in their code as a result. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (TRINIDAD-2039) Icons are created if the string for the resource is an empty string in Trinidad 1.2
Icons are created if the string for the resource is an empty string in Trinidad 1.2 --- Key: TRINIDAD-2039 URL: https://issues.apache.org/jira/browse/TRINIDAD-2039 Project: MyFaces Trinidad Issue Type: Bug Components: Components Affects Versions: 1.2.15-core Reporter: Andrew Robinson Assignee: Andrew Robinson The toResourceUri in CoreRenderer returns null for a value in Trinidad 2 but not in Trinidad 1.2. What happens is that icons that may evaluate to blank strings (like EL bound icon attributes) may end up rendering a img src= tag in Trinidad 1.2. This results in an extra call to the server in at least some browsers. We should backport the fix from Trinidad 2 to 1.2 to prevent this from happening. Issue can be reproduced easily with this code: tr:commandButton id=search text=Search icon= action=search/ -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (TRINIDAD-2039) Icons are created if the string for the resource is an empty string in Trinidad 1.2
[ https://issues.apache.org/jira/browse/TRINIDAD-2039?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Robinson resolved TRINIDAD-2039. --- Resolution: Fixed Fix Version/s: 1.2.15-core Icons are created if the string for the resource is an empty string in Trinidad 1.2 --- Key: TRINIDAD-2039 URL: https://issues.apache.org/jira/browse/TRINIDAD-2039 Project: MyFaces Trinidad Issue Type: Bug Components: Components Affects Versions: 1.2.15-core Reporter: Andrew Robinson Assignee: Andrew Robinson Priority: Minor Fix For: 1.2.15-core The toResourceUri in CoreRenderer returns null for a value in Trinidad 2 but not in Trinidad 1.2. What happens is that icons that may evaluate to blank strings (like EL bound icon attributes) may end up rendering a img src= tag in Trinidad 1.2. This results in an extra call to the server in at least some browsers. We should backport the fix from Trinidad 2 to 1.2 to prevent this from happening. Issue can be reproduced easily with this code: tr:commandButton id=search text=Search icon= action=search/ -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (TRINIDAD-2027) In facelets, pagination of tr:table is broken
[ https://issues.apache.org/jira/browse/TRINIDAD-2027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12991492#comment-12991492 ] Andrew Robinson commented on TRINIDAD-2027: --- Have you tried the latest code in the SVN trunk? (I believe this is already fixed by a change I made) Therefore I think this is a duplicate of TRINIDAD-2020 In facelets, pagination of tr:table is broken --- Key: TRINIDAD-2027 URL: https://issues.apache.org/jira/browse/TRINIDAD-2027 Project: MyFaces Trinidad Issue Type: Bug Components: Components Affects Versions: 2.0.0-beta-2 Environment: Any desktop browser Reporter: Mamallan Uthaman In a facelet page using Trinidad tags, table's prev and next links are broken. From a web inspector, I observed that the facelet page's httpRequest contains source/event parameter twice. And the first source/event parameter's value is always null, and the other seems to have a valid value. I'm guessing the source of the problem lies in the Trinidad's integration with JSF2.0 Ajax apis. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (TRINIDAD-2020) TableRenderer does not support JSF 2 source parameter for paging
TableRenderer does not support JSF 2 source parameter for paging Key: TRINIDAD-2020 URL: https://issues.apache.org/jira/browse/TRINIDAD-2020 Project: MyFaces Trinidad Issue Type: Bug Components: Components Affects Versions: 2.0.0-beta-2 Reporter: Andrew Robinson Assignee: Andrew Robinson Priority: Blocker The TableRenderer paging does not work as it does not support the PPR JSF2 source parameter (javax.faces.source) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (TRINIDAD-2020) TableRenderer does not support JSF 2 source parameter for paging
[ https://issues.apache.org/jira/browse/TRINIDAD-2020?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Robinson resolved TRINIDAD-2020. --- Resolution: Fixed Fix Version/s: 2.0.0-beta-2 TableRenderer does not support JSF 2 source parameter for paging Key: TRINIDAD-2020 URL: https://issues.apache.org/jira/browse/TRINIDAD-2020 Project: MyFaces Trinidad Issue Type: Bug Components: Components Affects Versions: 2.0.0-beta-2 Reporter: Andrew Robinson Assignee: Andrew Robinson Priority: Blocker Fix For: 2.0.0-beta-2 The TableRenderer paging does not work as it does not support the PPR JSF2 source parameter (javax.faces.source) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TRINIDAD-1999) It would be helpful to provide a constant on VisitTreeUtils for visit hints of non-transient and rendered as it is a common usage
It would be helpful to provide a constant on VisitTreeUtils for visit hints of non-transient and rendered as it is a common usage - Key: TRINIDAD-1999 URL: https://issues.apache.org/jira/browse/TRINIDAD-1999 Project: MyFaces Trinidad Issue Type: Improvement Affects Versions: 2.0.0.3-core Reporter: Andrew Robinson Assignee: Andrew Robinson It would be helpful to provide a constant on VisitTreeUtils for visit hints of non-transient and rendered as it is a common usage -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (TRINIDAD-1999) It would be helpful to provide a constant on VisitTreeUtils for visit hints of non-transient and rendered as it is a common usage
[ https://issues.apache.org/jira/browse/TRINIDAD-1999?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Robinson resolved TRINIDAD-1999. --- Resolution: Fixed Fix Version/s: 2.0.0.3-core It would be helpful to provide a constant on VisitTreeUtils for visit hints of non-transient and rendered as it is a common usage - Key: TRINIDAD-1999 URL: https://issues.apache.org/jira/browse/TRINIDAD-1999 Project: MyFaces Trinidad Issue Type: Improvement Affects Versions: 2.0.0.3-core Reporter: Andrew Robinson Assignee: Andrew Robinson Fix For: 2.0.0.3-core It would be helpful to provide a constant on VisitTreeUtils for visit hints of non-transient and rendered as it is a common usage -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
