4 Replies Latest reply on Dec 20, 2005 7:45 PM by Werner Punz

    Seam Comments

    Werner Punz Newbie

      Hi I gave the CVS version of seam a final testrun yesterday (implemented a small blogger)

      Here are my comments:
      First of all, I like it, it took me two hours from cvs downloading to have a running blogger with master detail view up and running in seam noejb.
      But I found some problematic parts (see them as hints on improvement not critique)

      First, the annotations are very good and tight, but there is a structural problem in the way the whole data model/model index issue is handled.

      First of all the data model seems to be some collection, maybe seam could provide a model which can rely on paging as well, thus not the entire collection has to be loaded.
      (some kind of ejb3 jsf data model)

      Another thing is, you have a model counter, which is a cood thing, which can be automatically requested, after an action from the data table itself.
      But this is a problematic pattern, because data can change in between, thus passing the surrogate of the affected object or the object makes more sense in this case.

      Third, setup, programming and deployment. This is somewhat the biggest problem. Seam tries to target people who do not want to fight with the obstacles of J2EE, and yet it relies on 5 config files and a bunch of generated ones, which are partially caused by the dependencies into JSF, Hibernate, JBoss Embedded etc...
      Well, you cannot get rid of all this stuff, but you can make things easier.

      a) Some of the config files need documentation

      b) There should be some kind of well documented shell projects with structures suitable for WTP based Eclipse installations where programming can be possible, without having to go through the ant deployment cycle every time.

      c) Make those empty shell projects for some different project types (SEAM+Plain jsp based JSF, Seam with xhtml templates etc...)

      But besides that, the whole thing is excellent.

        • 1. Re: Seam Comments
          Gavin King Master


          First of all the data model seems to be some collection, maybe seam could provide a model which can rely on paging as well, thus not the entire collection has to be loaded. (some kind of ejb3 jsf data model)


          There is no problem here, pagination is easy to implement (the Hibernate Tools plugin actually generates code to do pagination). All you do is have a nextPage() action that re-runs the query with a diff setFirstResults()/setMaxResults(). Very, very simple.

          Another thing is, you have a model counter, which is a cood thing, which can be automatically requested, after an action from the data table itself. But this is a problematic pattern, because data can change in between, thus passing the surrogate of the affected object or the object makes more sense in this case.


          Huh?? I think you have misunderstood. This is a *stateful* session bean. The list is cached.

          Third, setup, programming and deployment. This is somewhat the biggest problem.


          Yes, this can be a bit tricky. For now, the best way is "follow the examples".

          Another way is to use Hibernate Tools to generate everything.

          Some of the config files need documentation


          I have tried to do this. Which files in particular are lacking?


          • 2. Re: Seam Comments
            Werner Punz Newbie

             


            There is no problem here, pagination is easy to implement (the Hibernate Tools plugin actually generates code to do pagination). All you do is have a nextPage() action that re-runs the query with a diff setFirstResults()/setMaxResults(). Very, very simple.


            Well I was thinking more along a different line. JSF has the generic data model mechanism, a mechanism rather rough to implement, but very generic.
            I was thinking about the line of a generic EJB3/Hibernate data model, which you only have to feed with a query.
            The advantage of such an approach to something like you propose is following. MyFaces and other component libs have semi automatic data scrollers which work on the data tables.
            They basically do automatically what you propopse by incrementation of
            the internal scroller index of the data model.
            In the end the result would be, that you only have to feed an initialized data model, and do not even have to care for the next and back paging.


            have tried to do this. Which files in particular are lacking?


            I have to apologize here, I overlooked the online docs to the config files somewhat.
            Typical case of RTFM on my side.
            I will check the docs out thoroughly on this issue to see if I can find something unclear.

            Anyway seams is an excellent framework, all it needs is better integration into different IDEs and you have a clear winner, once this thing can be deployed with some wizards and reverse engineering tools (like they exist for hibernate already) in an instant you have something amazing on your hands.


            • 3. Re: Seam Comments
              ryan dewell Novice

              werpu,

              I think something like your idea about the generic data model has been previously discussed. You might want to check out this thread:

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

              Gavin actually came up with some related code but didn't appear to offer clear advantages.

              Ryan

              • 4. Re: Seam Comments
                Werner Punz Newbie

                Ah thanks, yes it seems that I triggered this a while ago (cannot really remember that).
                Actually I see one clear advantage.
                With the paginators, of myfaces for instance (dont know if the RI also has one)
                you do not need the @page and nextPage() definition as in the examples
                the final example probably would look like this:


                @Name("bookingList")
                @NamedQuery(name="userBookingList",
                ejbql="from Booking b where b.user = :user order by b.checkinDate")

                @QueryFactory(variable="bookings",
                query="userBookingList",
                context="bookingDatabase")

                public class BookingListAction implements Serializable
                {

                @In @Parameter
                private User user;

                @PageSize
                private int pageSize = 100;
                @Page
                private int page = 0;

                @DataModelSelection
                private Booking booking;


                public String cancel()
                booking.cancel();
                return null;
                }

                You can omit the page holders and data model
                definitions in the seam backend bean /session bean entirely
                Also there is no explicit paging code
                since the paginators increment the internal data model
                positional counter automatically

                or differently:


                @Name("bookingList")
                public class BookingListAction implements Serializable
                {

                @In @Parameter
                private User user;

                @DataModelQuery("bookingmodel")
                private Query bookingQuery;

                @PageSize
                private int pageSize = 100;
                @Page
                private int page = 0;

                @DataModelSelection
                private Booking booking;

                private String queryParam;

                public dosearch() {
                //change the query here according to the query params
                }

                public String cancel()
                booking.cancel();
                return null;
                }
                ...
                setters and getters for the query params here



                Advantage in both cases, no navigational code,
                in the second case only the query has to be defined
                the counter position still can be injected.

                Advantage in all of those cases, you only keep one page
                of objects maximum in ram, which is a clear advantage to keeping
                an entire (and possibly huge) collection of proxy or non proxy objects in ram.