Re: [Jira] adding new category/component for Portlet ?
hi scot I can't find that portlet component in jira: https://issues.apache.org/jira/browse/ADFFACES can you tell me where should I look for it? On 10/7/06, Scott O'Bryan [EMAIL PROTECTED] wrote: Arash, I'll get some JIRA tasks loaded up for this and you can have at it. We're going to need to make some enhancements to the bridge as well and we might need to have a Trinidad bridge which derives off the Generic Bridge in MyFaces to handle some of the special cases that we can't handle until the JSR-286 is release. There are, however, tons of housekeeping things we need to do as well in order to get things ready. Any help you can give would be much appreciated. I would be interested in understanding how you solved PPR and Filter issue in Tomahawk as well. Scott Adam Winer wrote: That'd be excellent. I know there's also some internal work at Oracle on ADF Faces that should apply to Trinidad - I'll ping the developer about that. -- Adam On 10/6/06, Arash Rajaeeyan [EMAIL PROTECTED] wrote: I was volunteer to work on tomahawk portal which looks shinsuke has solved it (at least for my test on liferay) now if you open some thing for trinidad I am volunteer to start working on it. On 10/6/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: Hi Can we open up a component for Portal in the JIRA for Trinidad? (I have no access to that, Martin? Craig?) Thx, Matthias -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com -- Arash Rajaeeyan -- Arash Rajaeeyan
isPostback patch for Trinidad 1.2 state manager
Hi,
I'm porting a Trinidad webapp over to 1.2 (with the help of Adam's great
new 1.2 build- thnx!), and was having trouble using Shale remoting.
Specifically, a Shale remoting request with parameters was causing
Trinidad 1.2 to bomb out, throw an NPE when finding the ViewRoot. I
tracked down the source of the issue: Trinidad's
CoreResponseStateManager was telling RestoreView that the request was a
postback, and then when it looked for the state parameter
(org.apache.myfaces.trinidad.faces.STATE), it couldn't find it. The
ViewRoot is then NULL.
(I actually tried to pass the state along as a param in the Remoting
request, but it didn't quite work- the restored viewId corresponds to
the base page URL, so the Shale PhaseListener passes, doesn't realize
it's supposed to take it.)
Anyway, looking into the code, I found that CoreResponseStateManger
doesn't implement .isPostback(FacesContext); it just lets its parent's
implementation stand- a default implementation that just returns TRUE if
the request has any parameters at all, meant for old applications.
Here's how the spec says this method should be implemented:
The implementation if this method for the Standard HTML RenderKit must
consult the javax.faces.context.ExternalContext's requestParameterMap
and return true if and only if there is a key equal to the value of the
symbolic constant VIEW_STATE_PARAM.
Which is easy enough to do. I just grabbed the implementation from RI's
ResponseStateManagerImpl, tweaked the constant, dropped it into
CoreReponseStateManager, and rebuilt. + this code:
@Override
public boolean isPostback(FacesContext context) {
return context.getExternalContext().getRequestParameterMap().
containsKey(_STATE_FIELD_NAME);
}
Not sure what the other effects of implementing this function will be,
but as it seems to agree with the spec, I thought I'd pass it along.
Rogers
Re: isPostback patch for Trinidad 1.2 state manager
Thanks! I'll get that in ASAP. And I also need to change
our state parameter from org.apache.myfaces.trinidad.faces.STATE
to the spec-standardized parameter.
-- Adam
On 10/9/06, Rogers Reilly [EMAIL PROTECTED] wrote:
Hi,
I'm porting a Trinidad webapp over to 1.2 (with the help of Adam's great
new 1.2 build- thnx!), and was having trouble using Shale remoting.
Specifically, a Shale remoting request with parameters was causing
Trinidad 1.2 to bomb out, throw an NPE when finding the ViewRoot. I
tracked down the source of the issue: Trinidad's
CoreResponseStateManager was telling RestoreView that the request was a
postback, and then when it looked for the state parameter
(org.apache.myfaces.trinidad.faces.STATE), it couldn't find it. The
ViewRoot is then NULL.
(I actually tried to pass the state along as a param in the Remoting
request, but it didn't quite work- the restored viewId corresponds to
the base page URL, so the Shale PhaseListener passes, doesn't realize
it's supposed to take it.)
Anyway, looking into the code, I found that CoreResponseStateManger
doesn't implement .isPostback(FacesContext); it just lets its parent's
implementation stand- a default implementation that just returns TRUE if
the request has any parameters at all, meant for old applications.
Here's how the spec says this method should be implemented:
The implementation if this method for the Standard HTML RenderKit must
consult the javax.faces.context.ExternalContext's requestParameterMap
and return true if and only if there is a key equal to the value of the
symbolic constant VIEW_STATE_PARAM.
Which is easy enough to do. I just grabbed the implementation from RI's
ResponseStateManagerImpl, tweaked the constant, dropped it into
CoreReponseStateManager, and rebuilt. + this code:
@Override
public boolean isPostback(FacesContext context) {
return context.getExternalContext().getRequestParameterMap().
containsKey(_STATE_FIELD_NAME);
}
Not sure what the other effects of implementing this function will be,
but as it seems to agree with the spec, I thought I'd pass it along.
Rogers
Re: move token map from UIXCollection to corresponding renderer
I was trying to implement this, and immediately ran into the following issue: The new Renderer was storing the clientRowKey-ServerRowKey cache as a private attribute on the component. but this fails when the component is inside a stamping container (ie: nested table case). The rowkey cache must be considered special stamp state, so that it is properly managed by a stamping container. therefore, it has to be managed by the component and must be serializable. So the renderer cannot implement the ClientRowKeyManager interface. Instead, the Renderer implements a ClientRowKeyManagerProducer interface. so to summarize, ClientRowKeyManagerProducer has a method public ClientRowKeyManager getClientRowKeyManager(FacesContext,UIComponent) ClientRowKeyManager has public String getClientRowKey(FacesContext, UIComponent table, Object rowKey); public Object getRowKey(FacesContext, UIComponent table, String clientRowKey); and UIXCollection has: public String getClientRowKey() public void setClientRowKey(String clientKey) protected final ClientRowKeyManager getClientRowKeyManager() Let me know your thoughts and I can start on this implementation. --arjuna On 10/7/06, Arjuna Wijeyekoon [EMAIL PROTECTED] wrote: I decided to call this ClientRowKeyManager: public String getClientRowKey(FacesContext, UIComponent table, Object rowKey); public Object getRowKey(FacesContext, UIComponent table, String clientRowKey); what d'ya think? On 10/4/06, Arjuna Wijeyekoon [EMAIL PROTECTED] wrote: If you're having doubts about having the text Renderer be in the interface name, can we go back to RowKeyStringManager ? I like having the work String in there, since this is going to manage mapping RowKeys to Strings. The interface would have two methods: public String getRowKeyString(FacesContext, UIComponent table, Object rowKey); public Object getRowKey(FacesContext, UIComponent table, String rowKeyStr); or do you prefer public String getStringKey(FacesContext, UIComponent table, Object rowKey); public Object getRowKey(FacesContext, UIComponent table, String rowKeyStr); ? On 10/4/06, Arjuna Wijeyekoon [EMAIL PROTECTED] wrote: Adam, In the absence, we should have a default implementation that is exactly the current implementation, and table/tree/treeTable can all use it. Maybe a protected getRowKeyManagingRenderer() hook up on UIXCollection that provides this? the current implementation clears the cache at the start of encode. So if the default implementation is not the renderer, then how will it get called at the start of encode, so that it can clear the cache? I suppose I could add some secret hook. But after reading that second paragraph, I'm starting to doubt my first - maybe renderers won't always be the only way to hook this in, so it shouldn't have Renderer in the name? perhaps. Although it is difficult to see how this cache can be properly managed without the intimate cooperation of the renderer. --arjuna On 10/1/06, Adam Winer [EMAIL PROTECTED] wrote: I'd like to have the name of the interface end in Renderer, so it's obvious that Renderers are supposed to implement it. So, maybe RowKeyManagingRenderer? In the absence, we should have a default implementation that is exactly the current implementation, and table/tree/treeTable can all use it. Maybe a protected getRowKeyManagingRenderer() hook up on UIXCollection that provides this? But after reading that second paragraph, I'm starting to doubt my first - maybe renderers won't always be the only way to hook this in, so it shouldn't have Renderer in the name? -- Adam On 9/29/06, Arjuna Wijeyekoon [EMAIL PROTECTED] wrote: What would you like to call this new Renderer interface? Is RowKeyStringManager ok? Also, in the absence of a RowKeyStringManager what should the table/tree/treeTable do when get/setCurrencyString() is called? 1. throw an exception 2. return the index as the string key (this will work for table, but not for trees). 3. return the base64 encoded, serialized key. 4. do #2 for tables, and #3 for trees/treeTables. My vote is for #3, and second preference for #1. Note that returning the index as the rowkey string (#2 and #4) will break if rows have been inserted/deleted from the underlying model. which do you think we should do? --arjuna On 9/29/06, Arjuna Wijeyekoon [EMAIL PROTECTED] wrote: http://issues.apache.org/jira/browse/ADFFACES-210 On 9/26/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: sorry for the delay. Not sure if I
MyFaces 1.1.4
anyone mind to use myfaces 1.1.4 instead of 1.1.2? -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com
Re: Re: [Jira] adding new category/component for Portlet ?
You'll see it when you file a new bug. It doesn't show up on the home page because nothing is open against it yet. -- Adam On 10/9/06, Arash Rajaeeyan [EMAIL PROTECTED] wrote: hi scot I can't find that portlet component in jira: https://issues.apache.org/jira/browse/ADFFACES can you tell me where should I look for it? On 10/7/06, Scott O'Bryan [EMAIL PROTECTED] wrote: Arash, I'll get some JIRA tasks loaded up for this and you can have at it. We're going to need to make some enhancements to the bridge as well and we might need to have a Trinidad bridge which derives off the Generic Bridge in MyFaces to handle some of the special cases that we can't handle until the JSR-286 is release. There are, however, tons of housekeeping things we need to do as well in order to get things ready. Any help you can give would be much appreciated. I would be interested in understanding how you solved PPR and Filter issue in Tomahawk as well. Scott Adam Winer wrote: That'd be excellent. I know there's also some internal work at Oracle on ADF Faces that should apply to Trinidad - I'll ping the developer about that. -- Adam On 10/6/06, Arash Rajaeeyan [EMAIL PROTECTED] wrote: I was volunteer to work on tomahawk portal which looks shinsuke has solved it (at least for my test on liferay) now if you open some thing for trinidad I am volunteer to start working on it. On 10/6/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: Hi Can we open up a component for Portal in the JIRA for Trinidad? (I have no access to that, Martin? Craig?) Thx, Matthias -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com -- Arash Rajaeeyan -- Arash Rajaeeyan
Re: move token map from UIXCollection to corresponding renderer
sorry, that last method has to be public (Renderer needs access to it during encodeBegin to do pruning). so UIXCollection has: public String getClientRowKey() public void setClientRowKey(String clientKey) public final ClientRowKeyManager getClientRowKeyManager() On 10/9/06, Arjuna Wijeyekoon [EMAIL PROTECTED] wrote: I was trying to implement this, and immediately ran into the following issue: The new Renderer was storing the clientRowKey-ServerRowKey cache as a private attribute on the component. but this fails when the component is inside a stamping container (ie: nested table case). The rowkey cache must be considered special stamp state, so that it is properly managed by a stamping container. therefore, it has to be managed by the component and must be serializable. So the renderer cannot implement the ClientRowKeyManager interface. Instead, the Renderer implements a ClientRowKeyManagerProducer interface. so to summarize, ClientRowKeyManagerProducer has a method public ClientRowKeyManager getClientRowKeyManager(FacesContext,UIComponent) ClientRowKeyManager has public String getClientRowKey(FacesContext, UIComponent table, Object rowKey); public Object getRowKey(FacesContext, UIComponent table, String clientRowKey); and UIXCollection has: public String getClientRowKey() public void setClientRowKey(String clientKey) protected final ClientRowKeyManager getClientRowKeyManager() Let me know your thoughts and I can start on this implementation. --arjuna On 10/7/06, Arjuna Wijeyekoon [EMAIL PROTECTED] wrote: I decided to call this ClientRowKeyManager: public String getClientRowKey(FacesContext, UIComponent table, Object rowKey); public Object getRowKey(FacesContext, UIComponent table, String clientRowKey); what d'ya think? On 10/4/06, Arjuna Wijeyekoon [EMAIL PROTECTED] wrote: If you're having doubts about having the text Renderer be in the interface name, can we go back to RowKeyStringManager ? I like having the work String in there, since this is going to manage mapping RowKeys to Strings. The interface would have two methods: public String getRowKeyString(FacesContext, UIComponent table, Object rowKey); public Object getRowKey(FacesContext, UIComponent table, String rowKeyStr); or do you prefer public String getStringKey(FacesContext, UIComponent table, Object rowKey); public Object getRowKey(FacesContext, UIComponent table, String rowKeyStr); ? On 10/4/06, Arjuna Wijeyekoon [EMAIL PROTECTED] wrote: Adam, In the absence, we should have a default implementation that is exactly the current implementation, and table/tree/treeTable can all use it. Maybe a protected getRowKeyManagingRenderer() hook up on UIXCollection that provides this? the current implementation clears the cache at the start of encode. So if the default implementation is not the renderer, then how will it get called at the start of encode, so that it can clear the cache? I suppose I could add some secret hook. But after reading that second paragraph, I'm starting to doubt my first - maybe renderers won't always be the only way to hook this in, so it shouldn't have Renderer in the name? perhaps. Although it is difficult to see how this cache can be properly managed without the intimate cooperation of the renderer. --arjuna On 10/1/06, Adam Winer [EMAIL PROTECTED] wrote: I'd like to have the name of the interface end in Renderer, so it's obvious that Renderers are supposed to implement it. So, maybe RowKeyManagingRenderer? In the absence, we should have a default implementation that is exactly the current implementation, and table/tree/treeTable can all use it. Maybe a protected getRowKeyManagingRenderer() hook up on UIXCollection that provides this? But after reading that second paragraph, I'm starting to doubt my first - maybe renderers won't always be the only way to hook this in, so it shouldn't have Renderer in the name? -- Adam On 9/29/06, Arjuna Wijeyekoon [EMAIL PROTECTED] wrote: What would you like to call this new Renderer interface? Is RowKeyStringManager ok? Also, in the absence of a RowKeyStringManager what should the table/tree/treeTable do when get/setCurrencyString() is called? 1. throw an exception 2. return the index as the string key (this will work for table, but not for trees). 3. return the base64 encoded, serialized key. 4. do #2 for tables, and #3 for trees/treeTables. My vote is for #3, and second preference for #1. Note that returning the index as the rowkey string
Re: MyFaces 1.1.4
+1. -- Adam On 10/9/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: anyone mind to use myfaces 1.1.4 instead of 1.1.2? -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com
