7 Replies Latest reply on Oct 22, 2013 11:54 AM by

    [forge-dev]  Wondering about coding convention #philosophy

      Hi all,

       

      I love Forge because it generates code. And that's why my customers start

      to love it too. Basically, they look at Forge as the "way to write

      Java EEcode" or if you like "if those guys write code like this, then

      we should".

       

      I am digging into some details of the generated code (I am writing a blog

      about several architectural styles starting with Forge) and I feel coding

      convention should be homogenized. I know extensions are written by

      different individuals, but some basic coding conventions should be applied.

      For example, when you generate a web app with REST and Faces scaffolding,

      you get some difference :

       

         - Faces Backing Bean use query builder (e.g getAll method is

         entityManager.createQuery(criteria.select(criteria.from(Book.class))).getResultList();

         and

         - REST Endpoint use dynamic queries (the list all method is "SELECT

         DISTINCT b FROM Book b ORDER BY b.id"))

       

      Method names are different and do the same :

       

         - JSF : getAll

         - REST : listAll

       

       

      Attributes

       

         -    private EntityManager em;

         -    private EntityManager entityManager;  // em would be better

       

      Or the use of this keyword (JSF beans use this.entityManager instead

      of directly em in REST)

       

      And there are several examples like this. If Forge is seen as "the way of

      writing code" maybe something should be created to get homogenized code.

      PMD, Checkstyle, human review and so one.....

       

      Just wondering....

       

       

      --

      Antonio Goncalves

      Software architect and Java Champion

       

      Web site <http://www.antoniogoncalves.org/> |

      Twitter<http://twitter.com/agoncal>

      | LinkedIn <http://www.linkedin.com/in/agoncal> | Paris

      JUG<http://www.parisjug.org/>

      | Devoxx France <http://www.devoxx.fr/>

       

        • 1. Re: [forge-dev] Wondering about coding convention #philosophy
          George Gastaldi Master

          Hi Antonio!

           

          Thanks for your feedback! We'll consider your suggestions for the Forge 2 REST code generation and the scaffold. In the meanwhile could you file a JIRA feature request so we don't lose track of this?

           

          Thank you very much!

           

          George Gastaldi

           

          Em 20/10/2013, às 14:51, Antonio Goncalves <antonio.mailing@gmail.com> escreveu:

           

          Hi all,

           

          I love Forge because it generates code. And that's why my customers start to love it too. Basically, they look at Forge as the "way to write Java EE code" or if you like "if those guys write code like this, then we should".

           

          I am digging into some details of the generated code (I am writing a blog about several architectural styles starting with Forge) and I feel coding convention should be homogenized. I know extensions are written by different individuals, but some basic coding conventions should be applied. For example, when you generate a web app with REST and Faces scaffolding, you get some difference :

          Faces Backing Bean use query builder (e.g getAll method is entityManager.createQuery(criteria.select(criteria.from(Book.class))).getResultList(); and

          REST Endpoint use dynamic queries (the list all method is "SELECT DISTINCT b FROM Book b ORDER BY b.id"))

          Method names are different and do the same :

          JSF : getAll

          REST : listAll

           

          Attributes

             private EntityManager em;

             private EntityManager entityManager;  // em would be better

          Or the use of this keyword (JSF beans use this.entityManager instead of directly em in REST)

           

          And there are several examples like this. If Forge is seen as "the way of writing code" maybe something should be created to get homogenized code. PMD, Checkstyle, human review and so one.....

           

          Just wondering....

           

           

          --

          Antonio Goncalves

          Software architect and Java Champion

           

          Web site | Twitter | LinkedIn | Paris JUG | Devoxx France

          _______________________________________________

          forge-dev mailing list

          forge-dev@lists.jboss.org

          https://lists.jboss.org/mailman/listinfo/forge-dev

           

          • 2. Re: [forge-dev] Wondering about coding convention #philosophy
            Lincoln Baxter III Master

            Hey Antonio!

             

            You are absolutely correct. We really need to standardize (and improve in

            general) most of the code that Forge generates. Really it works, but I

            think that we can do much better to set a good example.

             

            These are good issues to track

             

            ~Lincoln

             

             

            On Sun, Oct 20, 2013 at 10:29 PM, George Gastaldi <ggastald@redhat.com>wrote:

             

            Hi Antonio!

             

            Thanks for your feedback! We'll consider your suggestions for the Forge 2

            REST code generation and the scaffold. In the meanwhile could you file a

            JIRA feature request so we don't lose track of this?

             

            Thank you very much!

             

            George Gastaldi

             

            Em 20/10/2013, às 14:51, Antonio Goncalves <antonio.mailing@gmail.com>

            escreveu:

             

            Hi all,

             

            I love Forge because it generates code. And that's why my customers start

            to love it too. Basically, they look at Forge as the "way to write Java EEcode" or if you like "if those guys write code like this, then we should".

             

            I am digging into some details of the generated code (I am writing a blog

            about several architectural styles starting with Forge) and I feel coding

            convention should be homogenized. I know extensions are written by

            different individuals, but some basic coding conventions should be applied.

            For example, when you generate a web app with REST and Faces scaffolding,

            you get some difference :

             

               - Faces Backing Bean use query builder (e.g getAll method is

               entityManager.createQuery(criteria.select(criteria.from(Book.class))).getResultList();

               and

               - REST Endpoint use dynamic queries (the list all method is "SELECT

               DISTINCT b FROM Book b ORDER BY b.id"))

             

            Method names are different and do the same :

             

               - JSF : getAll

               - REST : listAll

             

            >

            Attributes

             

               -    private EntityManager em;

               -    private EntityManager entityManager;  // em would be better

             

            Or the use of this keyword (JSF beans use this.entityManager instead

            of directly em in REST)

             

            And there are several examples like this. If Forge is seen as "the way of

            writing code" maybe something should be created to get homogenized code.

            PMD, Checkstyle, human review and so one.....

             

            Just wondering....

             

            >

            --

            Antonio Goncalves

            Software architect and Java Champion

             

            Web site <http://www.antoniogoncalves.org/> | Twitter<http://twitter.com/agoncal>

            | LinkedIn <http://www.linkedin.com/in/agoncal> | Paris JUG<http://www.parisjug.org/>

            | Devoxx France <http://www.devoxx.fr/>

             

            _______________________________________________

            forge-dev mailing list

            forge-dev@lists.jboss.org

            https://lists.jboss.org/mailman/listinfo/forge-dev

             

            >

            _______________________________________________

            forge-dev mailing list

            forge-dev@lists.jboss.org

            https://lists.jboss.org/mailman/listinfo/forge-dev

             

             

             

             

            --

            Lincoln Baxter, III

            http://ocpsoft.org

            "Simpler is better."

             

            • 3. Re: [forge-dev] Wondering about coding convention #philosophy
              Lennart Jörelid Newbie

              While there are several ways to do this, I would prefer (and suggest)

              something a little more tangible than standardizing by convention (i.e.

              what is generated by Forge). It would be good to highlight the coding

              convention in a separate (maven) project, presumably residing inside the

              reactor.

               

              I would suggest something like:

               

               

               

              Hey Antonio!

               

              You are absolutely correct. We really need to standardize (and improve in

              general) most of the code that Forge generates. Really it works, but I

              think that we can do much better to set a good example.

               

              These are good issues to track

               

              ~Lincoln

               

              >

              On Sun, Oct 20, 2013 at 10:29 PM, George Gastaldi <ggastald@redhat.com>wrote:

               

              >> Hi Antonio!

              >>

              >> Thanks for your feedback! We'll consider your suggestions for the Forge 2

              >> REST code generation and the scaffold. In the meanwhile could you file a

              >> JIRA feature request so we don't lose track of this?

              >>

              >> Thank you very much!

              >>

              >> George Gastaldi

              >>

              >> Em 20/10/2013, às 14:51, Antonio Goncalves <antonio.mailing@gmail.com>

              >> escreveu:

              >>

              >> Hi all,

              >>

              >> I love Forge because it generates code. And that's why my customers start

              >> to love it too. Basically, they look at Forge as the "way to write Java

              >> EE code" or if you like "if those guys write code like this, then we

              >> should".

              >>

              >> I am digging into some details of the generated code (I am writing a blog

              >> about several architectural styles starting with Forge) and I feel coding

              >> convention should be homogenized. I know extensions are written by

              >> different individuals, but some basic coding conventions should be applied.

              >> For example, when you generate a web app with REST and Faces scaffolding,

              >> you get some difference :

              >>

              >>    - Faces Backing Bean use query builder (e.g getAll method is

              >>    entityManager.createQuery(criteria.select(criteria.from(Book.class))).getResultList();

              >>    and

              >>    - REST Endpoint use dynamic queries (the list all method is "SELECT

              >>    DISTINCT b FROM Book b ORDER BY b.id"))

              >>

              >> Method names are different and do the same :

              >>

              >>    - JSF : getAll

              >>    - REST : listAll

              >>

              >>

              >> Attributes

              >>

              >>    -    private EntityManager em;

              >>    -    private EntityManager entityManager;  // em would be better

              >>

              >> Or the use of this keyword (JSF beans use this.entityManager instead

              >> of directly em in REST)

              >>

              >> And there are several examples like this. If Forge is seen as "the way of

              >> writing code" maybe something should be created to get homogenized code.

              >> PMD, Checkstyle, human review and so one.....

              >>

              >> Just wondering....

              >>

              >>

              >> --

              >> Antonio Goncalves

              >> Software architect and Java Champion

              >>

              >> Web site <http://www.antoniogoncalves.org/> | Twitter<http://twitter.com/agoncal>

              >>  | LinkedIn <http://www.linkedin.com/in/agoncal> | Paris JUG<http://www.parisjug.org/>

              >>  | Devoxx France <http://www.devoxx.fr/>

              >>

              >> _______________________________________________

              >> forge-dev mailing list

              >> forge-dev@lists.jboss.org

              >> https://lists.jboss.org/mailman/listinfo/forge-dev

              >>

              >>

              >> _______________________________________________

              >> forge-dev mailing list

              >> forge-dev@lists.jboss.org

              >> https://lists.jboss.org/mailman/listinfo/forge-dev

              >>

              >

              >

              --

              Lincoln Baxter, III

              http://ocpsoft.org

              "Simpler is better."

               

              _______________________________________________

              forge-dev mailing list

              forge-dev@lists.jboss.org

              https://lists.jboss.org/mailman/listinfo/forge-dev

               

               

               

               

              --

               

              --

              ==============================

              | Bästa hälsningar,

              | [sw. "Best regards"]

              |

              | Lennart Jörelid

              | EAI Architect & Integrator

              |

              | jGuru Europe AB

              | Mölnlycke - Kista

              |

              | Email: lj@jguru.se

              | URL:   www.jguru.se

              | Phone

              | (skype):    jgurueurope

              | (intl):     +46 708 507 603

              | (domestic): 0708 - 507 603

              ==============================

               

              • 4. Re: [forge-dev] Wondering about coding convention #philosophy

                 

                -


                Original Message -


                From: "Antonio Goncalves" <antonio.mailing@gmail.com>

                To: "forge-dev List" <forge-dev@lists.jboss.org>

                Sent: Sunday, October 20, 2013 10:20:49 PM

                Subject:   Wondering about coding convention #philosophy

                 

                Hi all,

                 

                I love Forge because it generates code. And that's why my customers start to

                love it too. Basically, they look at Forge as the "way to write Java EE

                code" or if you like "if those guys write code like this, then we should".

                 

                I am digging into some details of the generated code (I am writing a blog

                about several architectural styles starting with Forge) and I feel coding

                convention should be homogenized . I know extensions are written by

                different individuals, but some basic coding conventions should be applied.

                 

                +1.

                 

                I would consider these architectural styles more than coding conventions,

                and I believe it would be wise to 'standardize' some of these for Java EE 6+.

                 

                For example, when you generate a web app with REST and Faces scaffolding,

                you get some difference :

                 

                 

                   

                • Faces Backing Bean use query builder (e.g getAll method is

                    entityManager.createQuery(criteria.select(criteria.from(Book.class))).getResultList();

                    and

                   

                • REST Endpoint use dynamic queries (the list all method is "SELECT

                    DISTINCT b FROM Book b ORDER BY b.id "))

                Method names are different and do the same :

                 

                 

                   

                • JSF : getAll

                   

                • REST : listAll

                 

                 

                They do look similar, but they're not the same in all respects.

                The one in REST will contain JOIN FETCH expressions when relationships (@OneToMany, @ManyToMany etc.) are found in the class.

                This was done to ensure that serialization would not emit incomplete object graphs.

                There are various factors that would be at work here in determining what JPQL queries should be generated.

                Obviously in this context, exposing JPA entities directly is bad idea and projections/views of the entities should be used instead.

                 

                IMHO we should not be putting persistence concerns in either the JSF beans or the REST resources.

                They should go into a service or a repository or whatever data access pattern is suitable for the context.

                This is where we lack any standardization at the moment, and it would be better to not limit this exercise to improving the conventions alone, but also the architecture.

                 

                I don't believe in packing in persistence concerns however small, into these beans for

                 

                • we run the risk of generating God classes, and

                 

                • we'd leave users with the task of creating/extracting the persistence layer (which should have been done by Forge in the first place).

                 

                 

                Attributes

                 

                 

                   

                • private EntityManager em;

                   

                • private EntityManager entityManager; // em would be better

                Or the use of this keyword (JSF beans use this.entityManager instead of

                directly em in REST)

                 

                And there are several examples like this. If Forge is seen as "the way of

                writing code" maybe something should be created to get homogenized code.

                PMD, Checkstyle, human review and so one.....

                 

                Just wondering....

                 

                 

                --

                Antonio Goncalves

                Software architect and Java Champion

                 

                Web site | Twitter | LinkedIn | Paris JUG | Devoxx France

                 

                _______________________________________________

                forge-dev mailing list

                forge-dev@lists.jboss.org

                https://lists.jboss.org/mailman/listinfo/forge-dev

                _______________________________________________

                forge-dev mailing list

                forge-dev@lists.jboss.org

                https://lists.jboss.org/mailman/listinfo/forge-dev

                 

                • 5. Re: [forge-dev] Wondering about coding convention #philosophy

                  So we don't forget : https://issues.jboss.org/browse/FORGE-1271

                   

                   

                  2013/10/21 George Gastaldi <ggastald@redhat.com>

                   

                  Hi Antonio!

                   

                  Thanks for your feedback! We'll consider your suggestions for the Forge 2

                  REST code generation and the scaffold. In the meanwhile could you file a

                  JIRA feature request so we don't lose track of this?

                   

                  Thank you very much!

                   

                  George Gastaldi

                   

                  Em 20/10/2013, às 14:51, Antonio Goncalves <antonio.mailing@gmail.com>

                  escreveu:

                   

                  Hi all,

                   

                  I love Forge because it generates code. And that's why my customers start

                  to love it too. Basically, they look at Forge as the "way to write Java EEcode" or if you like "if those guys write code like this, then we should".

                   

                  I am digging into some details of the generated code (I am writing a blog

                  about several architectural styles starting with Forge) and I feel coding

                  convention should be homogenized. I know extensions are written by

                  different individuals, but some basic coding conventions should be applied.

                  For example, when you generate a web app with REST and Faces scaffolding,

                  you get some difference :

                   

                     - Faces Backing Bean use query builder (e.g getAll method is

                     entityManager.createQuery(criteria.select(criteria.from(Book.class))).getResultList();

                     and

                     - REST Endpoint use dynamic queries (the list all method is "SELECT

                     DISTINCT b FROM Book b ORDER BY b.id"))

                   

                  Method names are different and do the same :

                   

                     - JSF : getAll

                     - REST : listAll

                   

                  >

                  Attributes

                   

                     -    private EntityManager em;

                     -    private EntityManager entityManager;  // em would be better

                   

                  Or the use of this keyword (JSF beans use this.entityManager instead

                  of directly em in REST)

                   

                  And there are several examples like this. If Forge is seen as "the way of

                  writing code" maybe something should be created to get homogenized code.

                  PMD, Checkstyle, human review and so one.....

                   

                  Just wondering....

                   

                  >

                  --

                  Antonio Goncalves

                  Software architect and Java Champion

                   

                  Web site <http://www.antoniogoncalves.org/> | Twitter<http://twitter.com/agoncal>

                  | LinkedIn <http://www.linkedin.com/in/agoncal> | Paris JUG<http://www.parisjug.org/>

                  | Devoxx France <http://www.devoxx.fr/>

                   

                  _______________________________________________

                  forge-dev mailing list

                  forge-dev@lists.jboss.org

                  https://lists.jboss.org/mailman/listinfo/forge-dev

                   

                  >

                  _______________________________________________

                  forge-dev mailing list

                  forge-dev@lists.jboss.org

                  https://lists.jboss.org/mailman/listinfo/forge-dev

                   

                   

                   

                   

                  --

                  Antonio Goncalves

                  Software architect and Java Champion

                   

                  Web site <http://www.antoniogoncalves.org/> |

                  Twitter<http://twitter.com/agoncal>

                  | LinkedIn <http://www.linkedin.com/in/agoncal> | Paris

                  JUG<http://www.parisjug.org/>

                  | Devoxx France <http://www.devoxx.fr/>

                   

                  • 6. Re: [forge-dev] Wondering about coding convention #philosophy

                    >>     * JSF : getAll

                    >>     * REST : listAll

                     

                    They do look similar, but they're not the same in all respects.

                    The one in REST will contain JOIN FETCH expressions when relationships

                    (@OneToMany, @ManyToMany etc.) are found in the class.

                    This was done to ensure that serialization would not emit incomplete

                    object graphs.

                     

                    When you have too many @OneToMany or @ManyToMany relationships, you end up

                    with several queries that JOIN FETCH several/different relationships. So

                    what I usually do when things are complex is :

                     

                    findAll

                    findAllWithRelations (meaning all relations are FETCH)

                     

                    or more specific (when things are really really complex)

                     

                    findAllWithBooks

                    findAllWithAuthors

                    findAllWithBooksAndAuthors

                     

                    Antonio

                     

                    2013/10/21 Vineet Reynolds Pereira <vpereira@redhat.com>

                     

                    >

                    ----- Original Message -----

                    From: "Antonio Goncalves" <antonio.mailing@gmail.com>

                    To: "forge-dev List" <forge-dev@lists.jboss.org>

                    Sent: Sunday, October 20, 2013 10:20:49 PM

                    Subject:   Wondering about coding convention #philosophy

                     

                    Hi all,

                     

                    I love Forge because it generates code. And that's why my customers

                    start to

                    love it too. Basically, they look at Forge as the "way to write Java EE

                    code" or if you like "if those guys write code like this, then we

                    should".

                     

                    I am digging into some details of the generated code (I am writing a blog

                    about several architectural styles starting with Forge) and I feel coding

                    convention should be homogenized . I know extensions are written by

                    different individuals, but some basic coding conventions should be

                    applied.

                     

                    +1.

                     

                    I would consider these architectural styles more than coding conventions,

                    and I believe it would be wise to 'standardize' some of these for Java EE

                    6+.

                     

                    For example, when you generate a web app with REST and Faces scaffolding,

                    you get some difference :

                     

                     

                       

                    • Faces Backing Bean use query builder (e.g getAll method is

                     

                    entityManager.createQuery(criteria.select(criteria.from(Book.class))).getResultList();

                        and

                       

                    • REST Endpoint use dynamic queries (the list all method is "SELECT

                        DISTINCT b FROM Book b ORDER BY b.id "))

                    Method names are different and do the same :

                     

                     

                       

                    • JSF : getAll

                       

                    • REST : listAll

                     

                     

                    They do look similar, but they're not the same in all respects.

                    The one in REST will contain JOIN FETCH expressions when relationships

                    (@OneToMany, @ManyToMany etc.) are found in the class.

                    This was done to ensure that serialization would not emit incomplete

                    object graphs.

                    There are various factors that would be at work here in determining what

                    JPQL queries should be generated.

                    Obviously in this context, exposing JPA entities directly is bad idea and

                    projections/views of the entities should be used instead.

                     

                    IMHO we should not be putting persistence concerns in either the JSF beans

                    or the REST resources.

                    They should go into a service or a repository or whatever data access

                    pattern is suitable for the context.

                    This is where we lack any standardization at the moment, and it would be

                    better to not limit this exercise to improving the conventions alone, but

                    also the architecture.

                     

                    I don't believe in packing in persistence concerns however small, into

                    these beans for

                     

                    • we run the risk of generating God classes, and

                     

                    • we'd leave users with the task of creating/extracting the persistence

                    layer (which should have been done by Forge in the first place).

                     

                     

                    Attributes

                     

                     

                       

                    • private EntityManager em;

                       

                    • private EntityManager entityManager; // em would be better

                    Or the use of this keyword (JSF beans use this.entityManager instead of

                    directly em in REST)

                     

                    And there are several examples like this. If Forge is seen as "the way of

                    writing code" maybe something should be created to get homogenized code.

                    PMD, Checkstyle, human review and so one.....

                     

                    Just wondering....

                     

                     

                    --

                    Antonio Goncalves

                    Software architect and Java Champion

                     

                    Web site | Twitter | LinkedIn | Paris JUG | Devoxx France

                     

                    _______________________________________________

                    forge-dev mailing list

                    forge-dev@lists.jboss.org

                    https://lists.jboss.org/mailman/listinfo/forge-dev

                    _______________________________________________

                    forge-dev mailing list

                    forge-dev@lists.jboss.org

                    https://lists.jboss.org/mailman/listinfo/forge-dev

                     

                     

                     

                     

                    --

                    Antonio Goncalves

                    Software architect and Java Champion

                     

                    Web site <http://www.antoniogoncalves.org/> |

                    Twitter<http://twitter.com/agoncal>

                    | LinkedIn <http://www.linkedin.com/in/agoncal> | Paris

                    JUG<http://www.parisjug.org/>

                    | Devoxx France <http://www.devoxx.fr/>

                     

                    • 7. Re: [forge-dev] Wondering about coding convention #philosophy

                       

                      -


                      Original Message -


                      From: "Antonio Goncalves" <antonio.mailing@gmail.com>

                      To: "forge-dev List" <forge-dev@lists.jboss.org>

                      Sent: Tuesday, October 22, 2013 3:06:12 PM

                      Subject: Re: Wondering about coding convention #philosophy

                       

                      >> * JSF : getAll

                      >> * REST : listAll

                       

                      They do look similar, but they're not the same in all respects.

                      The one in REST will contain JOIN FETCH expressions when relationships

                      (@OneToMany, @ManyToMany etc.) are found in the class.

                      This was done to ensure that serialization would not emit incomplete object

                      graphs.

                       

                      When you have too many @OneToMany or @ManyToMany relationships, you end up

                      with several queries that JOIN FETCH several/different relationships. So

                      what I usually do when things are complex is :

                       

                      findAll

                      findAllWithRelations (meaning all relations are FETCH)

                       

                      or more specific (when things are really really complex)

                       

                      findAllWithBooks

                      findAllWithAuthors

                      findAllWithBooksAndAuthors

                       

                      Tracking as FORGE-1277 <https://issues.jboss.org/browse/FORGE-1277>.

                       

                      I'll just reproduce my comments posted there to carry on the thread:

                       

                      In my opinion, this is a good addition to have. We should however handle the scenario (or the equivalent ):

                       

                      If a client issues a GET with a filter parameter (like filterAllWithBooks), then the resource representation should not be used in a subsequent PUT request to update the entity. The resource representation used in such a PUT request would lack certain relationships, and thus such requests would result in incorrect updates.

                       

                      I believe this could be done via documentation - clients should not be using filtered representations to represent updates in entities. Also we do not support HTTP PATCH (yet), so we should accept resource representations in whole and not in bits. It may also be necessary to ensure that the relationships are eagerly fetched by default (debatable on whether we should require clients to take the additional step of using the filter parameter to request the complete entity representation).

                       

                       

                      Antonio

                       

                      2013/10/21 Vineet Reynolds Pereira < vpereira@redhat.com >

                       

                       

                       

                       

                       

                      ----- Original Message -----

                      From: "Antonio Goncalves" < antonio.mailing@gmail.com >

                      To: "forge-dev List" < forge-dev@lists.jboss.org >

                      Sent: Sunday, October 20, 2013 10:20:49 PM

                      Subject: Wondering about coding convention #philosophy

                       

                      Hi all,

                       

                      I love Forge because it generates code. And that's why my customers start

                      to

                      love it too. Basically, they look at Forge as the "way to write Java EE

                      code" or if you like "if those guys write code like this, then we should".

                       

                      I am digging into some details of the generated code (I am writing a blog

                      about several architectural styles starting with Forge) and I feel coding

                      convention should be homogenized . I know extensions are written by

                      different individuals, but some basic coding conventions should be applied.

                       

                      +1.

                       

                      I would consider these architectural styles more than coding conventions,

                      and I believe it would be wise to 'standardize' some of these for Java EE 6+.

                       

                      For example, when you generate a web app with REST and Faces scaffolding,

                      you get some difference :

                       

                       

                      • Faces Backing Bean use query builder (e.g getAll method is

                      entityManager.createQuery(criteria.select(criteria.from(Book.class))).getResultList();

                      and

                      • REST Endpoint use dynamic queries (the list all method is "SELECT

                      DISTINCT b FROM Book b ORDER BY b.id "))

                      Method names are different and do the same :

                       

                       

                      • JSF : getAll

                      • REST : listAll

                       

                       

                      They do look similar, but they're not the same in all respects.

                      The one in REST will contain JOIN FETCH expressions when relationships

                      (@OneToMany, @ManyToMany etc.) are found in the class.

                      This was done to ensure that serialization would not emit incomplete object

                      graphs.

                      There are various factors that would be at work here in determining what JPQL

                      queries should be generated.

                      Obviously in this context, exposing JPA entities directly is bad idea and

                      projections/views of the entities should be used instead.

                       

                      IMHO we should not be putting persistence concerns in either the JSF beans or

                      the REST resources.

                      They should go into a service or a repository or whatever data access pattern

                      is suitable for the context.

                      This is where we lack any standardization at the moment, and it would be

                      better to not limit this exercise to improving the conventions alone, but

                      also the architecture.

                       

                      I don't believe in packing in persistence concerns however small, into these

                      beans for

                      • we run the risk of generating God classes, and

                      • we'd leave users with the task of creating/extracting the persistence layer

                      (which should have been done by Forge in the first place).

                       

                       

                      Attributes

                       

                       

                      • private EntityManager em;

                      • private EntityManager entityManager; // em would be better

                      Or the use of this keyword (JSF beans use this.entityManager instead of

                      directly em in REST)

                       

                      And there are several examples like this. If Forge is seen as "the way of

                      writing code" maybe something should be created to get homogenized code.

                      PMD, Checkstyle, human review and so one.....

                       

                      Just wondering....

                       

                       

                      --

                      Antonio Goncalves

                      Software architect and Java Champion

                       

                      Web site | Twitter | LinkedIn | Paris JUG | Devoxx France

                       

                      _______________________________________________

                      forge-dev mailing list

                      forge-dev@lists.jboss.org

                      https://lists.jboss.org/mailman/listinfo/forge-dev

                      _______________________________________________

                      forge-dev mailing list

                      forge-dev@lists.jboss.org

                      https://lists.jboss.org/mailman/listinfo/forge-dev

                       

                       

                       

                      --

                      Antonio Goncalves

                      Software architect and Java Champion

                       

                      Web site | Twitter | LinkedIn | Paris JUG | Devoxx France

                       

                      _______________________________________________

                      forge-dev mailing list

                      forge-dev@lists.jboss.org

                      https://lists.jboss.org/mailman/listinfo/forge-dev

                      _______________________________________________

                      forge-dev mailing list

                      forge-dev@lists.jboss.org

                      https://lists.jboss.org/mailman/listinfo/forge-dev