4 Replies Latest reply on Sep 26, 2012 6:25 PM by brieweb

    Forge generated code differs from seam-examples, a lot...

    erkinbaba

      I'm experimenting with Forge (1.0.7) for a few days and I can say its quite impressing tool.

      But, today I downloaded the seam-examples (seam-examples-3.1.0.Final-7) and compare sources with my forge-generated sources. Wow, looks like sources written by programmers from different universes, red blooded vs green blooded . All class structures, methods, beans, pages... everything is different.

       

      I was using Seam 2.2.1.Final to generate samples and then jumped to Forge train, maybe thats it, maybe missed some stuff between.

      I'm noob and I'm trying to find a path for my development. I know that things can be done by different approches but this... I'm lost, confused...

       

      Can some one explain me why these sources are so different ? Both are written by same team for "seam" right ?

        • 1. Re: Forge generated code differs from seam-examples, a lot...
          gastaldi

          Hi Erkin,

           

          Actually no, Forge-generated apps are designed to be plain Java EE 6 applications, with no dependencies at all besides the Java EE apis.  Seam examples depends on Seam modules, which may lead to less code.and better componentization.

           

          I would advise you to have a look on the tutorials provided by JBoss Developer Framework  (http://jboss.org/jdf) to gain some experience.

           

          The magic behind Forge lies not on the code generated itself, but on what it can do (you can write plugins very easily). Forge's extensibility is the key for productivity.

          • 2. Re: Forge generated code differs from seam-examples, a lot...
            erkinbaba

            Now I do remember a local saying  after your post, "you need to eat 40 bakeries's bread to make a good bread".

            But, who wants to write more code and less ( bad, complex... ? ) componentization ? Writing plugins and extensibility are not my interests for now, so I'll stick with seam and have fun, no nightmares at all   For the moment at least. I'm gonna dig more about EE 6, CDI... thx for the heads up.

             

            <me zip="Forge codes" clean="Eclipse_ws" mode="relax" id="Jack Daniels"/>

            • 3. Re: Forge generated code differs from seam-examples, a lot...
              lincolnthree

              Well, it certainly wasn't our choice to make Forge spit out plain Java EE code, but Seam 3 wasn't ready yet (and has been cancelled in favor of Apache DeltaSpike,) and our "power at be" didn't know if we were going to continue supporting Seam 2, which is why Forge generates the code you see now.

               

              It actually uses Metawidget behind ithe scenes. There is certainly a lot of work to be done on the Scaffold in Forge, but it's not what we really like to focus right now due to the amount of code generation required to make plain applications.

               

              What we have is the simplest set of features and the smallest amount of code the we could come up with, without using any 3rd party libraries whatsoever. Just a plain application that should run on any EE appserver And you can generate it from your database objects, so... if you want more than that, you can add in extra libraries yourself. That is what other Forge plugins are for, like adding RichFaces, etc. But more plugins are coming down the pipe for technology integration, so there will be a lot more coming.

               

              In short - We'd love to hear your ideas for what you'd like to see.

               

              ~Lincoln

              • 4. Re: Forge generated code differs from seam-examples, a lot...
                brieweb

                I liked the way seam-gen had its automatic login. I did fork the jboss-as-quickstarts and changed some to use a security domain that uses LDAP and form based login. https://github.com/brieweb/jboss-as-quickstart/tree/master/servlet-security . The readme.md still needs to be updated. Part of this depends upon the security domain being created in JBoss though.