[JBoss Seam] - conversation pattern
by codelion
Been working on this for a while, so this isn't an aimless question.
Face to face I'd ask: "What do you want to hear first, the purpose, or the question(s)?" Let's have the question(s) first.
Questions:
In "6.3. Starting conversations with GET requests" it says "There is also an <end-conversation> element."
>From sources or reading I believe to understand end-conversation causes an isLongRunningConversation flag to be set to false. That flag will be acted upon at the end of the render response phase to destroy the conversation context, which then will be considered temporary. Q1: Is that correct?
Now, further and as I hope is right, if on that page I have some link, button, navigation or whatever that has a (why not named s:propagation?) s:conversationPropagaion type="begin" or a propagation="begin" then that begin causes the same isLongRunningConversation flag to be set to true. That flag will be acted upon at the end of the render response phase to store the conversation context, which then will be considered long running. Q2: Is that correct?
If Q1 and Q2 were correct, then if I get into the habit of for each my.xhtml into its my.page.xml to put
<page>
| <end-conversation/>
| ...
then I'll have an application where conversations in general are ending, except if I am choosing to being one for a link, button, navigation or whatever, which would then only last until the next page, unless I again choose to being one. Q3: That should work?
Q4: There isn't a way of having an application default by
<pages>
| <end-conversation/>
| ...
or something like it, is there?
The purpose is that I feel more comfortable with ending conversation as default when there are many options to leave a page. E.g. menus in sidebars.
Q5: Will there be a significant difference in how such an application works with the back button?
Q6: If the conversation context gets destroyed, then a page you back button to won't be fully functional, or will it?
I might be willing to live with that side effect.
As an alternative, I'd like a
<page>
| <dont-propagate-conversation/>
| ...
or a
<pages>
| <dont-propagate-conversation/>
| ...
which would be different from end-conversation in that it doesn't destroy but keeps around that conversation context, in case one comes back with a back-button. Q7: Any chance we'll get that?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4024672#4024672
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4024672
17Â years, 11Â months
[JBoss Seam] - @In(create = true) @Out works fine in 1.1.5.GA and not in 1.
by msystems
| @Stateful
| @Name("accountBean")
| public class AccountBean implements AccountLocal {
| @PersistenceContext
| private EntityManager em;
|
| @In(create = true) @Out
| private User userDomain;
|
| @In(required = false)
| private Locale localeDomain;
|
| @Out(required = false)
| private Account accountDomain;
|
| @Begin
| public String begin() {
| return "accountCreateAgreement";
| }
|
| public String acceptDisclaimer() {
| userDomain.setDisclaimerAcceptDate(new Date());
|
| return "accountCreateForm";
| }
|
| public String validatePageRequest() {
| if ((userDomain != null) && (userDomain.isDisclaimerAccepted())) {
| return null;
| } else {
| return cancel();
| }
| }
|
| @End
| public String create() {
| if (!userDomain.isDisclaimerAccepted()) {
| return cancel();
| }
|
| try {
| em.createNamedQuery("user.findByUsername")
| .setParameter("username", userDomain.getUsername())
| .getSingleResult();
|
| // User exists
| FacesMessages.instance().addFromResourceBundle("username", FacesMessage.SEVERITY_ERROR, "usernameExists");
| return null;
| } catch (NoResultException e) { // Ignore
| } catch (NonUniqueResultException e) { } // Ignore - can never occur
|
| User user = UserType.MEMBER.getUserWithDependencies(this.userDomain);
| user.getUserSettings().setLocale(localeDomain);
|
| GregorianCalendar validToDate = new GregorianCalendar(localeDomain.getJavaLocale());
| validToDate.setTimeZone(TimeZone.getTimeZone(localeDomain.getTimeZone()));
| validToDate.set(GregorianCalendar.AM_PM, GregorianCalendar.AM);
| validToDate.set(GregorianCalendar.HOUR, 0);
| validToDate.set(GregorianCalendar.HOUR_OF_DAY, 0);
| validToDate.set(GregorianCalendar.MINUTE, 0);
| validToDate.set(GregorianCalendar.SECOND, 0);
| validToDate.set(GregorianCalendar.MILLISECOND, 0);
| validToDate.add(GregorianCalendar.DAY_OF_MONTH, 31);
|
| accountDomain = user.getAccount();
| accountDomain.setValidTo(validToDate.getTime());
|
| em.persist(user);
|
| // Encode password
| Md5PasswordEncoder passwordEncoder = new Md5PasswordEncoder();
| user.setPassword(passwordEncoder.encodePassword(user.getPassword(), user.getId()));
|
| return "accountCreateWelcome";
| }
|
| @End
| public String cancel() {
| return "accountCreateCancel";
| }
|
| @Remove @Destroy
| public void destroy() {
| }
| }
|
1.1.5.GA
Seam creates one instance of userDomain and for each method call
Seam injects the same instance of userDomain.
1.2.0.PATCH1
For each method call Seam creates a new instance of userDomain.
Can anybody here tell me what's going on?
Thanks,
/Kenneth
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4024669#4024669
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4024669
17Â years, 11Â months
[JBoss Seam] - Re: Argh! Attribute access
by pbrewer_uk
For anyone else that runs into this problem - it occurs because it is not permitted to call a method of a List implementation - you can only access its index. The following example will fail with the error mentioned previously.
E.g. SummingList.java
| public class SummingList extends ArrayList<Integer> {
| ...
| public Long getSum() {
| Long sum = 0L ;
| for (Integer value : this) {
| if (value != null) {
| sum += value ;
| }
| }
| return sum ;
| }
| ...
| }
|
SummingList.xhtml
| ...
| <h:outputText value ="#{summingList.sum}" />
| ...
|
The workaround is to move the extra functionality to outside the list, e.g.
| public class SummingList {
|
| public void setList(List<Integer> list) {...}
| public List<Integer> getList() {...}
|
| public Long getSum() {...}
|
| }
|
This looks like a facelets bug/ strange implementation choice to me:
LegacyELContext.java extract:
| /* Line 137*/ if((base instanceof List) || base.getClass().isArray())
| /* Line 138*/ return getPropertyResolver().getValue(base, Integer.parseInt(property.toString()));
|
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4024664#4024664
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4024664
17Â years, 11Â months