6 Replies Latest reply on May 2, 2009 4:25 PM by Arbi Sookazian

    best way to design my beans

    willie slepecki Newbie

      ive got an application where the first dozen or so pages are collecting information.  im trying to figure out the best way to handle the data on the back end.


      ive read from many different articles to use injection sparingly, so i don't want have 70 or so properties in a class and bi-injection on all of them.  seems bit bad to me.


      one thing that i thought about doing was create an entity bean, then just pass that entity bean back and forth while filling in all the data fields.  but whats different with my app is there is no database, at the end of the conversation the app rolls the data fields into an xml file and sends it to a web service on another machine.  can i create an entity bean without binding it to a database table?


      any suggestions on how to put this together the best?

        • 1. Re: best way to design my beans
          Arbi Sookazian Master

          willie slepecki wrote on May 02, 2009 01:19:


          ive got an application where the first dozen or so pages are collecting information.  im trying to figure out the best way to handle the data on the back end.

          ive read from many different articles to use injection sparingly, so i don't want have 70 or so properties in a class and bi-injection on all of them.  seems bit bad to me.

          one thing that i thought about doing was create an entity bean, then just pass that entity bean back and forth while filling in all the data fields.  but whats different with my app is there is no database, at the end of the conversation the app rolls the data fields into an xml file and sends it to a web service on another machine.  can i create an entity bean without binding it to a database table?

          any suggestions on how to put this together the best?


          I've never even thought of this scenario before.  AFAIK, JPA and Hibernate both don't support writing to XML files, you must map your entities to relational tables in a database.  And I don't know what technology or framework you'd use to accomplish this even if you didn't use entity classes.  But it's an interesting question.

          • 2. Re: best way to design my beans
            Nikos Paraskevopoulos Novice

            Hi,


            Some thoughts, though I havent actually implemented something similar:


            You cant use a JPA Entity for the reasons mentioned by Arbi. You can write your model beans and manage them with SEAM/JSF and in the final action method of the conversation serialize your model beans to XML with a framework like XStream, Castor or Java Bean serialization something.


            Or you can provide the EL implementation with a custom javax.el.ELResolver, so that binding may happen directly on the XML Document.

            • 3. Re: best way to design my beans
              Hugo Pragt Newbie

              Maybe not the answer you where looking for, but have you considered Cocoon?

              You can undoubtedly do this in Seam, but is it the most appropriate tool for the problem?

              • 4. Re: best way to design my beans
                willie slepecki Newbie

                doing an entity was just an idea, i don't need to.  if i scope a pojo to the conversation, can i use that to fill in my fields during the conversation?


                generating the xml at the end isn't a problem, ive got a series of classes that ive already written that will handle that.  i just need to figure out the best way to collect and store the data during the conversation.

                • 5. Re: best way to design my beans
                  willie slepecki Newbie

                  part of my requirements is this is a client app for a larger system.  but for security reasons im not allowed to install a database of any kind on the client. thats what makes this a bit interesting to write.

                  • 6. Re: best way to design my beans
                    Arbi Sookazian Master

                    willie slepecki wrote on May 02, 2009 15:48:


                    doing an entity was just an idea, i don't need to.  if i scope a pojo to the conversation, can i use that to fill in my fields during the conversation?

                    generating the xml at the end isn't a problem, ive got a series of classes that ive already written that will handle that.  i just need to figure out the best way to collect and store the data during the conversation.


                    Ok. So it sounds like you have several JSF views (most likely xhtml templates) with HtmlForm components.  You can simply model your conversations the standard Seam way using conversation-scoped JavaBeans or SFSBs (default conversation-scoped) using properties, setters, getters.  Use @Begin and @End to demarcate the beginning and ending of a LRC.


                    The only difference is that in your case, there will be no need to inject a persistence context (typically SMPC).  Which is fine, there was no concept of PC prior to EJB3 in J2EE 1.4.


                    So in the @End submit() method, invoke the appropriate method(s) on your util/helper (XAO - XML Access Object?) component to write the form data to the XML file(s).  The good news is that using CMT (or BMT if required) with EJB3 components, you can enforce transactional integrity (ACID) for any business method in your SFSB/SLSB, for example.


                    Basically this use case is using Seam conversational components minus JPA.  As long as you have a way to write the data to XML, it's not very complicated really.  I'm assuming you're only persisting, not reading, btw.  And even if you need to do full CRUD, that should not be too bad as long as your XAO layer supports all those operations for your XML files.


                    Understand, however, in the case of a multi-page wizard with LRC, that without JPA/Hibernate you are losing the benefits of a first-level cache: write-behind, automatic dirty checking, etc.  But you don't have much choice in that regards for your scenario...