[JBoss Seam] - Re: Mixing and Matching ICEfaces/RichFaces/GWT etc
by TedGoddard
"neilac333" wrote :
| I figure I can try to write something myself; I can wait for Gavin's team to start upgrading the RF components as part of the new ecosystem; I can try to throw IF into the mix; or I can see what Trinidad has to offer.
|
| I figure I will try the last couple of choices for now.
|
To maximize the interoperability of ICEfaces with other component suites, you will want the following:
- use just-ice.jar rather than icefaces.jar. By doing this, the standard JSF components (i.e. <h:inputText>) will not be Ajax-enabled, but potential conflicts will be reduced as well. Be sure to use <ice:inputText> on intended ICEfaces pages.
- set the context parameter com.icesoft.faces.delegateNonIface to "true" so that the ICEfaces ViewHandler will insert JavaScript only on ICEfaces pages (those with a .iface extension).
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4086187#4086187
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4086187
18 years, 10 months
[JBoss Seam] - Re: Error in documentation, or my understanding?
by wschwendt
"matt.drees" wrote :
| I haven't tested this, but this strikes me as wrong. Conversations by default don't end until after a redirect, right?
you're right. I haven't tested this either, but I, too, would say this section in the Ref Docs is wrong.
I think that unless the beforeRedirect attribute of the "end-conversation" element is set to true, there's no need use the solution where the document id is explicitly passed as request parameter, no matter whether we navigate to "/viewDocument.xhtml" with a "redirect" or with a "render" element.
But the solution with the documentId request parameter can make sense if we want to avoid that view "/viewDocument.xhtml" can access any conversation-scoped context variables of the conversation we just ended after the update. But in order to do the latter we would in fact have to write "end-conversation" with redirect=true.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4086182#4086182
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4086182
18 years, 10 months
[JBoss Seam] - Re: Feature request regarding nested conversations
by jacob.orshalick
"wschwendt" wrote : This exactly is the motive why I opened this tread: to request a better (or more elegant) way to transfer state (an ending result) back to the parent conversation when the nested conversation ends.
I absolutely agree with you guys that this is a must if you could simply carry the required state changes (and maintain the snapshot of the original conversation for back-button purposes) the problem would be resolved. The issue is if you directly write into the parent conversation, the back-button is always going to cause problems in master-details scenarios unless a snapshot exists.
e.g. if Person has addresses added and this is updated to the parent conversation, backing up to the page that does not show the addresses will still persist the addresses on submit as they are a part of that conversation.
Spring Web Flow provides a very elegant solution to this through its continuation approach but warn of the potential for high-memory usage. This could be limited if you could specify ONLY the objects that need a snapshot (which is essentially what I've been doing by cloning).
"matt.drees" wrote : I wonder if you could create a new persistence context in the nested conversation, merge everything down to it from the parent context, do your editing, and then when you're done, either merge everything back, or flush the child persistence context and refresh the appropriate entities in the parent context.
This is definitely, interesting, will have to look into it. It would be nice if the @PerNestedConversation (which was mentioned before) or some other annotation indicated this type of snapshot behavior. Currently, it looks like it simply means the object is not visible to the nested conversation and is recreated if needed (the documentation also says don't use it). This would be an easy way to specify only which objects you wanted a snapshot of to limit memory usage in a continuation approach.
Any other thoughts?
...
By the way, thanks for the tip on the quotes Matt :)
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4086175#4086175
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4086175
18 years, 10 months