OT: IBM joins openjdk
Sorry for the off topic post, but this is big news: http://www.oracle.com/us/corporate/press/176988
[Trinidad - API] RowKeyPropertyModel and RowKeyPropertyTreeModel
Sending this again with the proper heading:
By default, when Java Lists/Arrays are used as models in Trinidad
table/tree/treeTable components, they are wrapped in a SortableModel
instance.
The problem with SortableModel is that it uses row indexes as row keys. This
makes SortableModel immutable and insert/delete operations in the underlying
List/array can cause problems. For example, indexes shift after
insert/delete operations and can cause problems if the component is holding
on to row keys in SelectedRowKey/DisclosedRowKey sets.
The proposal is to add row key based CollectionModel/TreeModels which avoid
using indexes as row keys. (See below).
One drawback with the implementation of setRowKey API in RowKeyPropertyModel
(below) is that it is inefficient for large Lists and does a linear search
through the model to find the row with the given row key.
1) Add a RowKeyPropertyModel which extends SortableModel and uses row keys
instead of indexes:
package org.apache.myfaces.trinidad.model;
/**
* Creates a CollectionModel whose row keys are defined by a unique data
property in the model.
*/
public class RowKeyPropertyModel extends SortableModel
{
/**
* Creates a RowKeyPropertyModel.
*
* @param model The underlying model. If necessary, this will be converted
into a {...@link DataModel}
* @param rowKeyProperty The property by which the row key can be
accessed. Row key value must be unique
*/
public RowKeyPropertyModel(Object model, String rowKeyProperty)
{
super(model);
_rowKeyProperty = rowKeyProperty;
}
/**
* No arg constructor for use as a managed-bean.
* Must call {...@link #setWrappedData} and {...@link #setRowKeyProperty}
before
using this instance.
*/
public RowKeyPropertyModel()
{
super();
}
/**
* Gets the row key for the current row
* @return row key or null if model is not on any row
*/
public Object getRowKey()
{
if (isRowAvailable())
{
Object rowKey = _getRowKey();
return rowKey;
}
else
{
return null;
}
}
public void setRowKey(Object key)
{
if (key == null)
{
setRowIndex(-1);
return;
}
if (getRowKey() != null getRowKey().equals(key))
return;
for (int i = 0; i getRowCount(); i++)
{
setRowIndex(i);
Object prop = getRowKey();
if (key.equals(prop))
{
return;
}
}
// if we didn't find an element with a matching key,
// then don't make any rows current
setRowIndex(-1);
}
/**
* Gets the row key property name for this model
* @return row key property name
*/
public String getRowKeyProperty()
{
return _rowKeyProperty;
}
/**
* Sets the row key property for this model
* @param rowKeyProperty row key property to set
*/
public void setRowKeyProperty(String rowKeyProperty)
{
_rowKeyProperty = rowKeyProperty;
}
/**
* gets the row key for the given row by resolving the _rowKeyProperty
* @param row row to retrieve the row key for
* @return row key value
*/
protected Object getRowKey(Object row)
{
return __resolveProperty(row, _rowKeyProperty);
}
/**
* gets the row key for current row by resolving the _rowKeyProperty
* @return
*/
private Object _getRowKey()
{
Object data = getRowData();
return __resolveProperty(data, _rowKeyProperty);
}
private String _rowKeyProperty;
}
2) Add a RowKeyPropertyTreeModel which extends ChildPropertyTreeModel and
wraps each child model with a RowKeyPropertyModel:
package org.apache.myfaces.trinidad.model;
/**
* A subclass of {...@link ChildPropertyTreeModel} that supports row keys by
creating
* {...@link RowKeyPropertyModel}(s) for its child models.
*
* Ooverrides the protected createChildModel method in {...@link
ChildPropertyTreeModel} so that it can instantiate
* RowKeyPropertyModels as it encounters child data.
*/
public class RowKeyPropertyTreeModel
extends ChildPropertyTreeModel
{
/**
* Creates a RowKeyPropertyTreeModel
*
* @param model The underlying model. This will be converted into a {...@link
DataModel}
* @param childProperty The property by which the child data can be
accessed.
* @param rowKeyProperty The property by which the row key can be
accessed.
*/
public RowKeyPropertyTreeModel(Object model, String childProperty,
String rowKeyProperty)
{
super (new RowKeyPropertyModel(model, rowKeyProperty), childProperty);
_rowKeyProperty = rowKeyProperty;
}
/**
* No-arg constructor for use with managed-beans.
* Must call the {...@link #setChildProperty},
* {...@link #setWrappedData} and {...@link #setRowKeyProperty} methods after
constructing this instance.
*/
public RowKeyPropertyTreeModel()
{
super();
}
/**
* Overrides ChildPropertyTreeModel.createChildModel().
* Converts childData into a RowKeyPropertyModel.
*
* @param childData the
Re: [VOTE] Release MyFaces Portlet Bridge 2.0.0-beta
what happened to this vote ? -Matthias On Fri, Jul 23, 2010 at 7:30 PM, Scott O'Bryan darkar...@gmail.com wrote: +1 On 07/22/2010 04:41 AM, Matthias Wessendorf wrote: +1 On Wed, Jul 21, 2010 at 10:18 PM, Michael Freedman michael.freed...@oracle.com wrote: +1 On 7/20/2010 2:09 PM, Michael Freedman wrote: Please vote on the proposed release of MyFaces Portlet Bridge 2.0.0-beta. This is the beta version of the JSR 329 RI: Portlet 2.0 Bridge for JavaServer Faces 1.2. It corresponds to that JSRs Public Review draft which is currently posted and underway. The signed bridge artifacts pass what exists of the 329 TCK (i.e. all its tests) and I have verified that the examples run. It can be inspected at http://people.apache.org/~mfreedman/portlet-bridge/2.0.0-beta/ [ ] +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.. Thanks, -Mike- -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
Re: Custom facelet tag handlers and ajax rendering problem
Hi,
Thanks a lot for your answer, i've got more questions below so that i
can follow your advice correctly.
On 9 October 2010 00:06, Leonardo Uribe lu4...@gmail.com wrote:
Note VariableMapper has build time scope, or in other words, it is set
and discarded when facelets builds the component tree. The most easy
example is try to set some variable and then try to retrieve it on
render response.
When that build time scope happens? On facelets 1.1.x happens when
1. A component tree is build from facelets abstract syntax tree (AST).
2. A component tree is refreshed (postback before render view).
At first view, the only way to make a VariableMapper that works on
all events is do something similar to tomahawk t:aliasBean. On JSF 1.2 and
JSF 1.1, this component only works fully for MyFaces but with JSF 2.0,
now it works for Mojarra (RI). It is possible to use it on
on 1.x and Mojarra, but with limitations (binding property assigment
will not be wrapped).
Unfortunately, this is no go for me unless i have a way to generate
automatically backing bean on demand: in theory there can be any
number of rendering of a given layout on the same page. Using the
VariableMapper to store my temporary objects was a good workaround
until now, as this is working ok in all cases except for ajax
interactions.
On facelets 1.1.x, when there is a postback the view is refreshed to
addd transient components (usually html markup) and handle c:if case
(that's a long story). It is expected existing components created
on RestoreView phase to be only updated, but in your case what you can
see is the component does not change (for more information see
com.sun.facelets.tag.jsf.ComponentHandler class method apply() ).
Well my tags are the one actually changing the component tree: i'm
generating and applying ComponentHandler instances according to custom
rules, so maybe i'm interested about the long story for the c:if case.
If this tag is allowed to change the component tree structure on an
ajax call, i was assuming that i could too, and i was not expecting
the components to hold references to the context when they were first
added to the tree. I guess i'm also a little confused because what you
are describing is a mere refresh of the view, whereas i thought ajax
was performing the whole JSF lifecycle on parts of the component tree
(and so was recreating components from scratch anyway).
As i'm a bit worried about breaking the facelets or JSF expectations
of what a tag handler is allowed to do, i'd like to know if the
ComponentHandler behaviour (trying to find existing components, not
settings their attributes again if found) is just this tag handler
contract, or if it needs to have that behaviour for other reasons that
i do not see: what's the harm in re-creating components from scratch
(or at least setting their attributes again), except performance
gained from using the cached objects?
In theory, #{widget.label} will be evaluated on render time, but
VariableMapper only is available on build time.
I think this is working in practice because the
UIInstructionTagHandler does re-create its associated component
instead of taking the one already in the component tree.
My solution would be use t:aliasBean or if this is required for a component
internally, mix t:aliasBean and the target component, so #{widget.label}
could
be resolved correctly.
Ok, so i'm thinking that i could make my tag tag handler create a JSF
component that will hold the values that i'm already exposing in the
VariableMapper. It could expose them again in the context in other JSF
phases after the build. I'll look into t:aliasBean to make other
components resolve their expressions by using this component.
Of course, i'll need to update the values held by this component on
ajax re-render, that's why i'd like to know if it's risky or unfit to
do so: if it's not, i will create it by hand instead of using the
standard ComponentHandler implementation.
Thanks again !
Regards,
anahide.
nesting cc:actionListener
Hi,
If my test page calls a composite component in level 1:
xmlns:level1=http://java.sun.com/jsf/composite/level1;
level1:button value=test1
f:actionListener for=button1 binding=#{myBean.action1} /
/level1:button
where level1 button passes the action listener on to level 2:
xmlns:level2=http://java.sun.com/jsf/composite/level2;
!-- INTERFACE --
composite:interface
composite:attribute name=value/
composite:actionSource name=button1 /
/composite:interface
!-- IMPLEMENTATION --
composite:implementation
level2:button id=button1 value=#{cc.attrs.value}/
/composite:implementation
and level 2 finally consumes the action:
!-- INTERFACE --
composite:interface
composite:attribute name=value/
composite:actionSource name=button2 /
/composite:interface
!-- IMPLEMENTATION --
composite:implementation
h:commandButton id=button2 value=#{cc.attrs.value} /
/composite:implementation
Shouldn't this call the ActionListener returned by getAction1()? In fact it
doesn't, if you agree that it should I will open an issue.
Best regards,
Ganesh
[jira] Updated: (TRINIDAD-1920) DateTimeRangevalidator fails across multiple timezones
[ https://issues.apache.org/jira/browse/TRINIDAD-1920?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yee-Wah Lee updated TRINIDAD-1920: -- Status: Patch Available (was: Open) DateTimeRangevalidator fails across multiple timezones -- Key: TRINIDAD-1920 URL: https://issues.apache.org/jira/browse/TRINIDAD-1920 Project: MyFaces Trinidad Issue Type: Bug Components: Components Affects Versions: 1.2.13-core Reporter: Yee-Wah Lee Priority: Minor Attachments: 12123_1920.diff, trin12_1920.diff This is a regression from TRINIDAD-1818 where the DateTimeRangeValidator was created with Date/ms. https://issues.apache.org/jira/browse/TRINIDAD-1818 Because the Javascript client is not able to correctly calculate timezone offsets for different timezones, it should take the min/max as a String and convert that into a Date. The converted value would have the same offset as the value, and validation would be all on objects with the same timezone offset. Fix is to revert to using Strings, but also pass the date as an ISO string when the converter pattern is insufficient. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: nesting cc:actionListener
Hi Ganesh,
This is a known problem of the JSF 2.0 spec, see [1]. Sadly it was
(re-)targeted for 2.2.
The problem is that when the ation listener is retargeted (from the
composite component to the inner (implementation) component), it
cannot be retargeted to another composite component, because this one
does not implement ActionSource2. IMO we could try to implement a
working solution already in MyFaces 2.0.x, but I don't know if this
stuff is tested by the TCK..
Regards,
Jakob
[1] https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=755
2010/10/12 Ganesh gan...@j4fry.org:
Hi,
If my test page calls a composite component in level 1:
xmlns:level1=http://java.sun.com/jsf/composite/level1;
level1:button value=test1
f:actionListener for=button1 binding=#{myBean.action1}
/
/level1:button
where level1 button passes the action listener on to level 2:
xmlns:level2=http://java.sun.com/jsf/composite/level2;
!-- INTERFACE --
composite:interface
composite:attribute name=value/
composite:actionSource name=button1 /
/composite:interface
!-- IMPLEMENTATION --
composite:implementation
level2:button id=button1 value=#{cc.attrs.value}/
/composite:implementation
and level 2 finally consumes the action:
!-- INTERFACE --
composite:interface
composite:attribute name=value/
composite:actionSource name=button2 /
/composite:interface
!-- IMPLEMENTATION --
composite:implementation
h:commandButton id=button2 value=#{cc.attrs.value} /
/composite:implementation
Shouldn't this call the ActionListener returned by getAction1()? In fact it
doesn't, if you agree that it should I will open an issue.
Best regards,
Ganesh
--
Jakob Korherr
blog: http://www.jakobk.com
twitter: http://twitter.com/jakobkorherr
work: http://www.irian.at
Re: nesting cc:actionListener
But anyhow, please open an issue for this. Thanks!
Regards,
Jakob
2010/10/12 Jakob Korherr jakob.korh...@gmail.com:
Hi Ganesh,
This is a known problem of the JSF 2.0 spec, see [1]. Sadly it was
(re-)targeted for 2.2.
The problem is that when the ation listener is retargeted (from the
composite component to the inner (implementation) component), it
cannot be retargeted to another composite component, because this one
does not implement ActionSource2. IMO we could try to implement a
working solution already in MyFaces 2.0.x, but I don't know if this
stuff is tested by the TCK..
Regards,
Jakob
[1]
https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=755
2010/10/12 Ganesh gan...@j4fry.org:
Hi,
If my test page calls a composite component in level 1:
xmlns:level1=http://java.sun.com/jsf/composite/level1;
level1:button value=test1
f:actionListener for=button1 binding=#{myBean.action1}
/
/level1:button
where level1 button passes the action listener on to level 2:
xmlns:level2=http://java.sun.com/jsf/composite/level2;
!-- INTERFACE --
composite:interface
composite:attribute name=value/
composite:actionSource name=button1 /
/composite:interface
!-- IMPLEMENTATION --
composite:implementation
level2:button id=button1 value=#{cc.attrs.value}/
/composite:implementation
and level 2 finally consumes the action:
!-- INTERFACE --
composite:interface
composite:attribute name=value/
composite:actionSource name=button2 /
/composite:interface
!-- IMPLEMENTATION --
composite:implementation
h:commandButton id=button2 value=#{cc.attrs.value} /
/composite:implementation
Shouldn't this call the ActionListener returned by getAction1()? In fact it
doesn't, if you agree that it should I will open an issue.
Best regards,
Ganesh
--
Jakob Korherr
blog: http://www.jakobk.com
twitter: http://twitter.com/jakobkorherr
work: http://www.irian.at
--
Jakob Korherr
blog: http://www.jakobk.com
twitter: http://twitter.com/jakobkorherr
work: http://www.irian.at
Re: nesting cc:actionListener
Hi
I remember this one. Fortunately, MyFaces has many, many tests for composite
components. It also has a test for this specific issue and it works well:
testCompositeActionSource.xhtml
h:form id=testForm1
testComposite:compositeActionSource
f:actionListener for=button2
binding=#{helloWorldBean.actionListener}/
/testComposite:compositeActionSource
/h:form
compositeActionSource.xhtml
composite:interface
composite:actionSource name=button2 targets=button3/
/composite:interface
composite:implementation
testComposite:simpleActionSource id=button3
f:actionListener for=button
binding=#{helloWorldBean.actionListener}/
/testComposite:simpleActionSource
/composite:implementation
simpleActionSource.xhtml
composite:interface
composite:actionSource name=button/
composite:actionSource name=button2 targets=button/
/composite:interface
composite:implementation
h:commandButton id=button value=Press me! /
/composite:implementation
The button finally should have two actionListener. Look the attribute
targets.
Try set it on your example. It should work without problem.
regards,
Leonardo Uribe
2010/10/12 Jakob Korherr jakob.korh...@gmail.com
But anyhow, please open an issue for this. Thanks!
Regards,
Jakob
2010/10/12 Jakob Korherr jakob.korh...@gmail.com:
Hi Ganesh,
This is a known problem of the JSF 2.0 spec, see [1]. Sadly it was
(re-)targeted for 2.2.
The problem is that when the ation listener is retargeted (from the
composite component to the inner (implementation) component), it
cannot be retargeted to another composite component, because this one
does not implement ActionSource2. IMO we could try to implement a
working solution already in MyFaces 2.0.x, but I don't know if this
stuff is tested by the TCK..
Regards,
Jakob
[1]
https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=755
2010/10/12 Ganesh gan...@j4fry.org:
Hi,
If my test page calls a composite component in level 1:
xmlns:level1=http://java.sun.com/jsf/composite/level1;
level1:button value=test1
f:actionListener for=button1
binding=#{myBean.action1}
/
/level1:button
where level1 button passes the action listener on to level 2:
xmlns:level2=http://java.sun.com/jsf/composite/level2;
!-- INTERFACE --
composite:interface
composite:attribute name=value/
composite:actionSource name=button1 /
/composite:interface
!-- IMPLEMENTATION --
composite:implementation
level2:button id=button1 value=#{cc.attrs.value}/
/composite:implementation
and level 2 finally consumes the action:
!-- INTERFACE --
composite:interface
composite:attribute name=value/
composite:actionSource name=button2 /
/composite:interface
!-- IMPLEMENTATION --
composite:implementation
h:commandButton id=button2 value=#{cc.attrs.value}
/
/composite:implementation
Shouldn't this call the ActionListener returned by getAction1()? In fact
it
doesn't, if you agree that it should I will open an issue.
Best regards,
Ganesh
--
Jakob Korherr
blog: http://www.jakobk.com
twitter: http://twitter.com/jakobkorherr
work: http://www.irian.at
--
Jakob Korherr
blog: http://www.jakobk.com
twitter: http://twitter.com/jakobkorherr
work: http://www.irian.at
Re: nesting cc:actionListener
Hi
I tried your example and work in this way:
test page calls a composite component in level 1:
xmlns:level1=http://java.sun.com/jsf/composite/level1;
level1:button value=test1
f:actionListener for=button1 binding=#{myBean.action1}
/
/level1:button
level1 button passes the action listener on to level 2:
xmlns:level2=http://java.sun.com/jsf/composite/level2;
!-- INTERFACE --
composite:interface
composite:attribute name=value/
composite:actionSource name=button1 targets=button1 /
!-- targets here is optional --
/composite:interface
!-- IMPLEMENTATION --
composite:implementation
level2:button id=button1 value=#{cc.attrs.value}/
/composite:implementation
level 2 finally consumes the action:
!-- INTERFACE --
composite:interface
composite:attribute name=value/
composite:actionSource name=button1 targets=button2 /
/composite:interface
!-- IMPLEMENTATION --
composite:implementation
h:commandButton id=button2 value=#{cc.attrs.value} /
/composite:implementation
regards,
Leonardo
2010/10/12 Leonardo Uribe lu4...@gmail.com
Hi
I remember this one. Fortunately, MyFaces has many, many tests for
composite
components. It also has a test for this specific issue and it works well:
testCompositeActionSource.xhtml
h:form id=testForm1
testComposite:compositeActionSource
f:actionListener for=button2
binding=#{helloWorldBean.actionListener}/
/testComposite:compositeActionSource
/h:form
compositeActionSource.xhtml
composite:interface
composite:actionSource name=button2 targets=button3/
/composite:interface
composite:implementation
testComposite:simpleActionSource id=button3
f:actionListener for=button
binding=#{helloWorldBean.actionListener}/
/testComposite:simpleActionSource
/composite:implementation
simpleActionSource.xhtml
composite:interface
composite:actionSource name=button/
composite:actionSource name=button2 targets=button/
/composite:interface
composite:implementation
h:commandButton id=button value=Press me! /
/composite:implementation
The button finally should have two actionListener. Look the attribute
targets.
Try set it on your example. It should work without problem.
regards,
Leonardo Uribe
2010/10/12 Jakob Korherr jakob.korh...@gmail.com
But anyhow, please open an issue for this. Thanks!
Regards,
Jakob
2010/10/12 Jakob Korherr jakob.korh...@gmail.com:
Hi Ganesh,
This is a known problem of the JSF 2.0 spec, see [1]. Sadly it was
(re-)targeted for 2.2.
The problem is that when the ation listener is retargeted (from the
composite component to the inner (implementation) component), it
cannot be retargeted to another composite component, because this one
does not implement ActionSource2. IMO we could try to implement a
working solution already in MyFaces 2.0.x, but I don't know if this
stuff is tested by the TCK..
Regards,
Jakob
[1]
https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=755
2010/10/12 Ganesh gan...@j4fry.org:
Hi,
If my test page calls a composite component in level 1:
xmlns:level1=http://java.sun.com/jsf/composite/level1;
level1:button value=test1
f:actionListener for=button1
binding=#{myBean.action1}
/
/level1:button
where level1 button passes the action listener on to level 2:
xmlns:level2=http://java.sun.com/jsf/composite/level2;
!-- INTERFACE --
composite:interface
composite:attribute name=value/
composite:actionSource name=button1 /
/composite:interface
!-- IMPLEMENTATION --
composite:implementation
level2:button id=button1 value=#{cc.attrs.value}/
/composite:implementation
and level 2 finally consumes the action:
!-- INTERFACE --
composite:interface
composite:attribute name=value/
composite:actionSource name=button2 /
/composite:interface
!-- IMPLEMENTATION --
composite:implementation
h:commandButton id=button2 value=#{cc.attrs.value}
/
/composite:implementation
Shouldn't this call the ActionListener returned by getAction1()? In
fact it
doesn't, if you agree that it should I will open an issue.
Best regards,
Ganesh
--
Jakob Korherr
blog: http://www.jakobk.com
twitter: http://twitter.com/jakobkorherr
work: http://www.irian.at
--
Jakob Korherr
blog: http://www.jakobk.com
twitter: http://twitter.com/jakobkorherr
work: http://www.irian.at
Re: [VOTE] Release MyFaces Portlet Bridge 2.0.0-beta
Actually, I had deferred sending the results message pending us actually doing/pushing the release which I thought was imminent. Alas I am still awaiting getting some free time from the developer tasked to do this but that slot never seems to open up -- so its now 2+ months since this was done and still it hasn't been published. If you would prefer I am happy to send a message concerning the vote result -- but I still don't have a time estimate for when the release/push will actually happen. Let me know whether I should wait until the push is ready to go or I should just send this message to get it off the stack. -Mike- On 10/12/2010 9:23 AM, Scott O'Bryan wrote: Mike Freedman sent out the announcement. It looks like I forgot the results email. Sorry Matthias. Sent from my iPhone On Oct 12, 2010, at 2:47 AM, Matthias Wessendorfmat...@apache.org wrote: what happened to this vote ? -Matthias On Fri, Jul 23, 2010 at 7:30 PM, Scott O'Bryandarkar...@gmail.com wrote: +1 On 07/22/2010 04:41 AM, Matthias Wessendorf wrote: +1 On Wed, Jul 21, 2010 at 10:18 PM, Michael Freedman michael.freed...@oracle.com wrote: +1 On 7/20/2010 2:09 PM, Michael Freedman wrote: Please vote on the proposed release of MyFaces Portlet Bridge 2.0.0-beta. This is the beta version of the JSR 329 RI: Portlet 2.0 Bridge for JavaServer Faces 1.2. It corresponds to that JSRs Public Review draft which is currently posted and underway. The signed bridge artifacts pass what exists of the 329 TCK (i.e. all its tests) and I have verified that the examples run. It can be inspected at http://people.apache.org/~mfreedman/portlet-bridge/2.0.0-beta/ [ ] +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.. Thanks, -Mike- -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
[jira] Resolved: (TRINIDAD-1919) var and varStatus of the UIXCollection stay around during a visit tree call
[ https://issues.apache.org/jira/browse/TRINIDAD-1919?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Robinson resolved TRINIDAD-1919. --- Resolution: Fixed Fix Version/s: 2.0.0.3-core var and varStatus of the UIXCollection stay around during a visit tree call --- Key: TRINIDAD-1919 URL: https://issues.apache.org/jira/browse/TRINIDAD-1919 Project: MyFaces Trinidad Issue Type: Bug Components: Components Affects Versions: 2.0.0.3-core Reporter: Andrew Robinson Assignee: Andrew Robinson Fix For: 2.0.0.3-core Attachments: faces-config.diff, test-case.tar.bz2, TRINIDAD-1919.patch A short-coming of JSF is that there is no provision for resetting the component environment when the context changes during an invokeOnComponent or visitTree call. For example, the collection family components in trinidad inject a var and varStatus variable into the request scope when they are iterating. These variables are left on the request scope if a visit tree or invoke on component call is made while the collection is in scope. I propose to make a change to Trinidad to introduce a new API that components may interact with that is basically a stack. The idea is that components that make context sensitive changes would push an object onto a change stack. During an invoke on component call, or a visit tree call, the stack of changes would be suspended. Once the invoke on component or visit tree call is complete, the changes could be resumed. This way, in the table example, the var varStatus could be removed during an IOC/VT call and restored after it is complete. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TRINIDAD-1933) Handling Windows Mobile 6.5 browser
[ https://issues.apache.org/jira/browse/TRINIDAD-1933?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12920401#action_12920401 ] Tadashi Enomori commented on TRINIDAD-1933: --- I reviewed the patches and they look good. Handling Windows Mobile 6.5 browser --- Key: TRINIDAD-1933 URL: https://issues.apache.org/jira/browse/TRINIDAD-1933 Project: MyFaces Trinidad Issue Type: Bug Components: Components Affects Versions: 1.2.13-core Environment: Windows Mobile 6.5 Reporter: Mamallan Uthaman Priority: Minor Attachments: TRINIDAD-1933-1.2.12.3-branch.patch, TRINIDAD-1933.patch The format of WM 6.5's user-agent string has been changed, so we need to include a parsing logic to handle this new user-agent. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [VOTE] Release MyFaces Portlet Bridge 2.0.0-beta
Hi Mike, you should send out the result vote roughly 72hrs after the vote has started. When you do the release based on the vote - is your timing thingy ;) best regards, Martin On 10/12/10, Michael Freedman michael.freed...@oracle.com wrote: Actually, I had deferred sending the results message pending us actually doing/pushing the release which I thought was imminent. Alas I am still awaiting getting some free time from the developer tasked to do this but that slot never seems to open up -- so its now 2+ months since this was done and still it hasn't been published. If you would prefer I am happy to send a message concerning the vote result -- but I still don't have a time estimate for when the release/push will actually happen. Let me know whether I should wait until the push is ready to go or I should just send this message to get it off the stack. -Mike- On 10/12/2010 9:23 AM, Scott O'Bryan wrote: Mike Freedman sent out the announcement. It looks like I forgot the results email. Sorry Matthias. Sent from my iPhone On Oct 12, 2010, at 2:47 AM, Matthias Wessendorfmat...@apache.org wrote: what happened to this vote ? -Matthias On Fri, Jul 23, 2010 at 7:30 PM, Scott O'Bryandarkar...@gmail.com wrote: +1 On 07/22/2010 04:41 AM, Matthias Wessendorf wrote: +1 On Wed, Jul 21, 2010 at 10:18 PM, Michael Freedman michael.freed...@oracle.com wrote: +1 On 7/20/2010 2:09 PM, Michael Freedman wrote: Please vote on the proposed release of MyFaces Portlet Bridge 2.0.0-beta. This is the beta version of the JSR 329 RI: Portlet 2.0 Bridge for JavaServer Faces 1.2. It corresponds to that JSRs Public Review draft which is currently posted and underway. The signed bridge artifacts pass what exists of the 329 TCK (i.e. all its tests) and I have verified that the examples run. It can be inspected at http://people.apache.org/~mfreedman/portlet-bridge/2.0.0-beta/ [ ] +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.. Thanks, -Mike- -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
