stereotype

[gonorrhea]

I noticed that Spring has had the stereotype verbage as well.  interesting...

[nickarls]

When dealing with similar contexts (no pun intended), it's hard not to end up with shared/overlapping terminology. What would the alternatives have been? Pigeonhole?

[gavin.king]

299 had it first, however :-)

Seriously, Spring have been adding a bunch of things modeled on 299 of late.

[gonorrhea]

Gavin King wrote on May 12, 2009 09:47:


299 had it first, however :-)

Seriously, Spring have been adding a bunch of things modeled on 299 of late.

Anyways, it seems like a good idea.

Didn't you at least partially base the dynamic injection portion of Seam bijection on Spring's static DI pattern and/or implementation?

What about seam-gen concept?  Similar to ideas from RoR and/or Grails for generating a project skeleton to boost developer productivity?

It seems to me that ideas get floated around in the mindscape all the time regarding JEE frameworks...  Which is likely a good thing.

[gavin.king]

Didn't you at least partially base the dynamic injection portion of Seam bijection on Spring's static DI pattern and/or implementation?

Well, Seam was much more influenced by XWork, but sure, there are certainly some Spring-like things in there.

It seems to me that ideas get floated around in the mindscape all the time regarding JEE frameworks... Which is likely a good thing.

Of course, I didn't say it was a bad thing :-)

[gonorrhea]

This is off topic, but oh well...

I have a .NET dev co-worker that I'm getting up-and-running using the JBoss dev stack and I was explaining to him the basic ideas behind conversations in Seam and he noted that it's overly complicated and we can achieve similar functionality more easily in .NET even though ASP.NET does not provide conversation support per se (apparently they use view state to transfer state between pages) and even more laughably has just recently added MVC architecture.  Which I retorted how will your ASP.NET app know when to begin and end a LRC given the fact that the same LRC can be promoted from temp conversation to LRC via more than one business method in your Seam component, and likewise the same LRC may be ended (demoted to temp conversation) by more than one business method.  He responded that in a 3 page wizard use case, for example, the submission of the form in page 1 would start the conversation and the submission of the form on page 3 would end the conversation.

He even asked me can you just use the session scope rather than conversations in Seam? which I replied yes b/c you can but not necessarily recommended.  And then you lose (or risk session memory management problems with) functionality like multi-tab use case execution in one session/browser.  He said that conversation management is the responsibility of the developer and thus in cases where the user wishes to compare resultsets, etc. they should be able to do it in one page/tab, not requiring multiple tabs per browser to achieve the same effect.

I would say that the nested conversation model may be overkill in most cases and increases ramp up time for Seam devs.  but nested conversations are not required for all use cases, so don't use it if you don't need it I guess.

How does the conversation model tie into the Java Contexts portion of 299 if at all?  Or is that going to still be Seam-specific core functionality in Seam 3?

(read the spec, yeah I know)

[nickarls]

Read the spec ;-)

The conversation is just the act of passing along a token (conversation id) in one way of another so that the conversation context isn't emptied between each request.