impossible usecase?

[obfuscator]

Hi

I have a problem that I've tried to solve for quite some time with seam. I'll give you a simple example that shows the conceptual problem. Any guidance on how to solve this problem would be greatly appriciated.

Let's say that I'm developing an application for displaying post-its. Users can add new post-its with custom text, and they are persisted until next login.

A post-it has a view (postit.jsp) and a backing bean (SFSB, PostIt.java). Now, I want
to be able to create several post-its, sharing the same view and backing-bean, just initiated with different texts.

I find this being a huge problem with seam. How can i have several instances of the same components coexisting, with just different initialization?

What I've done is a hack. The postIt.jsp page calls a hack function, setting
a variable in the backing bean (postItId=3) or something. Now I can diffrentiate between postIts in my factory method, and set the text accordingly, but there is one huge problem still: All post-its share the same backing-bean instance.

Now, since I don't want all post-its showing the same text, how can I let them have different backing beans instances? Well, there is conversations,
but I cannot start more than one per request, so I cannot start one
conversation per post it when the user logs in. The crux is that the
conversations need to be started before the first page is shown, so triggering conversations through user actions is not an option.
Using component roles could maybe work, but they are very static in
nature, and would not provide a good solution as far as I can see.

It would be nice if there could be some mechanism that would identify
the requesting view, so that several
identical views could coexist within the same context, with separate
backing bean instances. A candidate for such an identifier could be the
position of the component in the JSF tree or similar.

Anyway, even though this is a simple example, i believe that this might
become a big problem. I mean, not being able to keep separate instances
of views is sort of a big problem, and feels very non-OO.

I've probably overlooked the obvious solution, so I'm asking people here
how they would solve this problem.



Best Regards

[ellenzhao]

"obfuscator" wrote:
Well, there is conversations,
but I cannot start more than one per request, so I cannot start one
conversation per post it when the user logs in.

I guess you can start as many conversations as you want per user-action. In your backing bean, you can say:

Conversation.instance.begin();

or

Conversation.instance.beginNested();

better yet, say like this:

if (Conversation.isLongRunning){
 Conversation.instance.beginNested();
 Conversation.instance.setDescription("readFooRedirectedFromReadBar");
 }
else {
 Conversation.instance.begin();
 Conversation.instance.setDescription("readFooFromSiteRoot");
}

I am doing this in my own application and the multi-conversation-spawning works like charm. (I have a problem with the pop()/end()/leave() now, not quite sure the exact semantics of these three methods, need to investigate this part of Seam source code)

The crux is that the
conversations need to be started before the first page is shown,

You may want to try page action. There is description of page action in Seam documentation.


Regards,
Ellen

[obfuscator]

Oh! This sounds like good news! What version are you using? I've been trying, but not been able to start multiple converations (got wierd behaviour).

Then i read this:

http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3959566

Conversations begin and end at request boundaries. You cannot create two new conversations during a single request.

So is this changed now? Starting several conversations per request is fine?
And can i run several conversations per page? (my doubts come from http://lists.jboss.org/pipermail/jboss-user/2007-May/060440.html).

I just haven't got it to work, so I'm still a bit sceptical, since I've tried so many things, but maybe I've been doing it wrong?

Lastly, it seems to me like conversations might be heavyweight. Is the pattern "one conversation per instance" considered good (if it works at all :D )?

[matt.drees]

No, you can't start multiple conversations in one request. And I'm pretty sure you wouldn't want to; that's not what they're designed for.

As far as the post-it scenario, I don't think you want a separate backing bean for each post-it. Wouldn't it make more sense to have a single PostItController that contains a list of PostIt objects?

[ellenzhao]

sorry that I expressed wrong in my previous post. It worked when I said things like this:

public void someUserAction(){
 Conversations.instance().beginNested();
 if (someCondition)
 Conversations.instance().beginNested();
 ....
}

It should be multi-level-nested-conversations. You can only have one Conversation instance at a time tough.

[obfuscator]

"matt.drees" wrote:
No, you can't start multiple conversations in one request. And I'm pretty sure you wouldn't want to; that's not what they're designed for.

As far as the post-it scenario, I don't think you want a separate backing bean for each post-it. Wouldn't it make more sense to have a single PostItController that contains a list of PostIt objects?

@Matt: thanks for your suggestions. I actually didn't think of that solution,
but while a list seems to be a good solutions in most usecases, I'm dealing with
setting up a portal-like environment. Users can select from many different
cells, mixing and matching. This means that the different
post-its can be spread out over several different fragments of the page.
I guess I could have a cell-local variable that identifies the post-it and
then all post-its share the same controller, having a list of post-its.

This has one major drawback as I see it. I must always plan for
having several components, making all my backing beans contain collections.
This is not very productive, and forces another layer upon the design.

All I want to acheive is a contextual separation of cells, so that several
instances of the same cell can coexist, with the same business logic, but
with different state. Is the "one common backing bean" pattern the only
viable solution?

Thanks

PS. Thanks ellen for the tips. I appriciate your effort and I'm sure that
I'll use your tips in a later stage. DS.