December 2007 - jboss-user - Jboss List Archives

[JBoss Seam] - Re: Injecting a stateful bean into a stateful bean in glassf

by pete.muir＠jboss.org

Can you create a JIRA issue for this that summarises what you understand the problem to be, I think we may need a small fix here. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4115521#4115521 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4115521

18 years, 3 months

1
0
0 / 0

[JBoss Seam] - Re: Seam 2.0.CR1, jBPM and custom entity process variables

by pete.muir＠jboss.org

Do you still need help with this? Sorry, I lost track of the issue. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4115520#4115520 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4115520

18 years, 3 months

1
0
0 / 0

[JBoss Seam] - Re: XHTML Performance

by pete.muir＠jboss.org

JBoss QA is going to be looking at performance testing and benchmarking for Seam over the next few months. We should be able to take the results from this to both publish a tutorial on performance and make improvements to Seam as possible. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4115519#4115519 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4115519

18 years, 3 months

1
0
0 / 0

[JBoss Seam] - best practices with Seam and presentation logic

by asookazian

So I have a use case where I need to reset the selected value of the h:selectOneMenu. I am using the following code to tracke the old and new values: <h:form id="peerForm"> | <h:selectOneMenu id="selectPeer" value="#{peerAction.employeeId}" valueChangeListener="#{peerAction.processValueChange}"> | <a4j:support event="onchange" | onchange="Richfaces.showModalPanel('mpChangePeer',{width:450, top:200})"/> | <f:selectItems value="#{peerAction.peers}" /> | </h:selectOneMenu> | </h:form> SFSB: private String selectedValue; | | private String oldValue; | | public void processValueChange(ValueChangeEvent value) { | selectedValue = (String)value.getNewValue(); | oldValue = (String)value.getOldValue(); | } I know from previous post that Pete had stated it's bad practice to handle presentation logic in a session bean (which I won't argue with although it does get confusing when SFSB's are essentially backing bean for JSF's). The two options are: 1) to use Seam remoting to access the old value from client side and reset selected value via javascript. 2) reconstruct the HtmlSelectOneMenu component in a POJO/SFSB. What is the recommended best practice according to Seam framework regarding this situation??? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4115518#4115518 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4115518

18 years, 3 months

1
0
0 / 0

[JBoss Seam] - Re: jbpm timer transaction issues

by pete.muir＠jboss.org

Pete, did you solve this problem? Sorry, I lost track of it til now. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4115517#4115517 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4115517

18 years, 3 months

1
0
0 / 0

[JBoss Seam] - Re: how to 'stay in conversation' with rich suggestionbox?

by pete.muir＠jboss.org

Brad, I lost track of this one, sorry about that. Where have you got to with this? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4115515#4115515 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4115515

18 years, 3 months

1
0
0 / 0

[JBoss Seam] - Very strange conversation behavior

by trouby

Hey, I'm having a very very strange conversation behavior, Following is the scenario: I have the following stateful bean: | @Stateful | @Name("personActions") | public class PersonActionsBean implements PersonActions{ | Set<Attr> attrs = new LinkedHashSet<Attr>(); | //getAttrs() | //setAttrs() | | public void prepareCreatePerson() { | //init the attrs set with some elements | //init 4 elements! | } | | public void createPreson() { | //this result 0! | log.debug("Attrs size:" + attrs.size()); | } | I invoke 'prepareCreateUser' with the following link: | <s:button id="createPerson" value="Create Person" action="/createPersonFirstPage.xhtml" propagation="begin"/> | and I have 'createPersonFirstPage.page.xml' with: | <action execute="#{personActions.prepareCreatePerson}"/> | this action inits te 'attrs' list with few elements. In 'createPersonFirstPage.xhtml I have a form which modifies the some of the 'personActions.attrs' and a button such as: | <h:commandButton id="secondPage" value="Continue" action="/createPersonSecondPage.xhtml" /> | createPersonSecondPage.xhtml has a button such as: | <h:commandButton id="save" value="Save" action="#{personActions.createPreson}" | In 'createPersonSecondPage.page.xml' I have: | <navigation from-action="#{personActions.createPerson}"> | <end-conversation/> | <redirect view-id="/Home.xhtml"/> | </navigation> | The strange is that when 'personActions.createPerson' is invoked 'attrs' list has NO elements. so even though the conversation has started at the first button the data is not available anymore (the conversation Id keeps being the same for all pages) What makes is extremely strange is if I access the 'attrs' list in the second page (createPersonSecondPage.xhtml) (even like: <h:outputText value="#{personActions.attrs}/> I can see the elements and when the 'Save' button is pressed the elements are available! What causes the data not to be kept? and why accessing the 'attrs' list in the second page makes seam to keep the elements within the list? Thanks, Asaf. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4115514#4115514 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4115514

18 years, 3 months

1
0
0 / 0

[JBoss Seam] - Re: resetting/clearing a session scoped SFSB

by pete.muir＠jboss.org

"asookazian" wrote : hmm. when the user selects another manager in the h:selectOneMenu, it's like they're started another session (similar to logging in as another user). So, then invalidate the session. anonymous wrote : the reason the injected NoteAction is session scoped is because it needs to handle all the note data that is entered in the main form dataTable (other SFSB) prior to submission (i.e. user may enter notes for multiple rows/employees prior to saving the first one). | | if the scope of the NoteAction was conversation I would not be able to meet the functional requirement UNLESS I forced the user to enter and save one row at a time by disabling all inactive rows... | | so if this is the case, i don't understand why the context/scope of the two SFSB's is incorrect.... I don't quite see why this means it must be Session scoped, only data/actions which should be used over the time the user has their browser should be session scoped. Anyway, this is application design, which you have to decide on ;) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4115512#4115512 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4115512

18 years, 3 months

1
0
0 / 0

[JBoss Seam] - Re: How to control end of conversations/state of stateful be

by pete.muir＠jboss.org

"gus888" wrote : My previous suggestion is that as long as system run a @Begin, system should put current foreground conversation to background (let system timeout clean) and start a new foreground conversation (if the conversation id is automatically created by system). Currently, in the Seam, this functionality only works on the SAME foreground conversation bean, for example, I start a conversation A from Conversation Bean A by clicking @Begin from A, then if I go back to click @Begin from the same Conversation Bean A, Seam will create a new conversation, BUT instead, if I go back to click @Begin from Conversation B, the whole system will throw exception (need @Begin (join=true)) and the system will be down. This is critical problem in a production project. Please correct me if I am wrong. Not really. Clicking back *does not* propagate the conversation. It just takes you back to the page as it was when you were on it before (read about how the back button works). So if you aren't in a conversation on your "start" page, you go into conversation A, then click the back button, you won't be in a conversation, and can start another one. Seam doesn't differentiate between conversations based on what method they are started from. anonymous wrote : I like to create a JIRA if Seam team think it is necessary. Thank you and have a good holiday. I really don't think this is necessary, and would just be (another) thing to learn about Seam. So I'm -1. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4115511#4115511 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4115511

18 years, 3 months

1
0
0 / 0

[JBoss Seam] - Re: How to control end of conversations/state of stateful be

by pete.muir＠jboss.org

"gus888" wrote : For "How to control end of conversations": | I have the same problem. I think that it is critical issue for the core (conversation) of Seam. The Seam forum here suggested that you use "propagation=none" to all other buttons and links which users can reach and propagate away from the current conversation. I think, maybe I am wrong, that this way is not practicable in a production project. One reason is that maybe there are a couple of dozens links and buttons on screen, So this is just laziness? anonymous wrote : the second is that maybe there are other conversation begin buttons and links on screen. This is application design. If you *have* to start other conversations from that screen look at ending the conversation before redirect. Its perfectly possible to use conversations in an application, you just need to consider the paths the user will take through the application. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4115510#4115510 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4115510

18 years, 3 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-user December 2007