2 Replies Latest reply on Mar 6, 2006 7:00 PM by Magnus Sandberg

    Related Entitys and @Page context

    Magnus Sandberg Novice

      I have several Entitys that are related with many-to-one as well as many-to-many. I need to use entitys that have relations as @Page-components (actually I use client-side state for the complete app).

      What I don't want to do is to serialize the complete "entity-tree" to the client. So the quiestion is:

      * How and what is serialized to the client in Seam/JSF/Facelets using client-side state?
      * Is it possible to use transient on the instance variables that I don't want to serialize to the client?
      * Is there a better design-pattern to use for situations like this?

      Thanks,
      /Magnus

        • 1. Re: Related Entitys and @Page context
          Gavin King Master

          Only associations that are already fetched are serialized.

          This stuff is well-defined in the EJB3 spec.

          • 2. Re: Related Entitys and @Page context
            Magnus Sandberg Novice

            Yes but sooner or later (sooner in this case) more then I want to send to the client is going to be fetched from the database.

            From what I currently understand the only way to avoid this problem is not to use the same class as the Entity and the Seam-Component, and that doesn't feel to good since I probably will need to write all data-classes twice.

            I'm working on an app that will have a lot of users. So I cannot affort to store lots of data in the session and I really don't want to send to much data to the client either.

            I think that what I'm trying to say is that I trying to make a design that stores the "state" on the client not the "data" - the "data" can be recreated on the server using the "state" from the next request, even as early as in the RESTORE_VIEW phase. Using JSF-rendered currently forces me to store the data somewhere to be able to recreate the view on the next request.

            Sorry Gavin - just ramblin' on here - but any comments or design pointers are welcome
            /Magnus