6 Replies Latest reply on May 15, 2009 7:45 AM by Nicklas Karlsson

    stereotype

    Arbi Sookazian Master

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

        • 1. Re: stereotype
          Nicklas Karlsson Master

          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?

          • 2. Re: stereotype
            Gavin King Master

            299 had it first, however :-)


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

            • 3. Re: stereotype
              Arbi Sookazian Master

              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.

              • 4. Re: stereotype
                Gavin King Master

                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 :-)

                • 5. Re: stereotype
                  Arbi Sookazian Master

                  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)

                  • 6. Re: stereotype
                    Nicklas Karlsson Master

                    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.