5 Replies Latest reply on Sep 29, 2005 12:25 AM by Jacob Hookom

    trace the origin of EL variables

    Gavin King Master

      Right. In terms of scalability, this is waaaay better than a single enormous faces-config.xml that contains all components.

        • 1. Re: trace the origin of EL variables
          Bing Ran Newbie

           

          "gavin.king@jboss.com" wrote:
          Right. In terms of scalability, this is waaaay better than a single enormous faces-config.xml that contains all components.


          You're not talking about runtime scalability, are you? With faces-config.xml as least I know where an EL variable is declared,e.g., hotelBooking. Now when I start to "reverse-engineer" the booking example from those xhtml files, I have difficulty figuring out where this "hotel" variable is defined, thanks to the "outjection". Faces-config.xml works as a catalog of all the managed beans. In Seam there is no such thing and one goes everywhere to trace things out. This is not "development-time" scalability we talk about.

          • 2. Re: trace the origin of EL variables
            Gavin King Master

            Huh?? "hotel" is defined in an @Name annotation on a Java class. In my IDE it is incredibly trivial to do ctrl-shift-G and get a list of all @Name annotations in the project. Of course, an even more faster way is a text search on @Name("hotel"). This is every bit as easy as scanning a thousand-line XML file for name="hotel" or whatever.

            I'm sorry, but any approach which involves throwing information about all components in a system into one enormous XML file is extremely unscalable in a team development environment. This is why Hibernate, for example, says that you have a seperate XML file for each component. I remember the pain of struts-config.xml back in the day, and when I saw JSF for the first time, one of the things that truly disappointed me was that jsf-config.xml had preserved that broken design. Most developers I have discussed this wit *hate* the single-monolithic-xml-file design, so you represent a definite minority view here.

            • 3. Re: trace the origin of EL variables
              Bing Ran Newbie

               

              "gavin.king@jboss.com" wrote:
              Huh?? "hotel" is defined in an @Name annotation on a Java class. In my IDE it is incredibly trivial to do ctrl-shift-G and get a list of all @Name annotations in the project. Of course, an even more faster way is a text search on @Name("hotel"). This is every bit as easy as scanning a thousand-line XML file for name="hotel" or whatever.

              I'm sorry, but any approach which involves throwing information about all components in a system into one enormous XML file is extremely unscalable in a team development environment. This is why Hibernate, for example, says that you have a seperate XML file for each component. I remember the pain of struts-config.xml back in the day, and when I saw JSF for the first time, one of the things that truly disappointed me was that jsf-config.xml had preserved that broken design. Most developers I have discussed this wit *hate* the single-monolithic-xml-file design, so you represent a definite minority view here.



              well, you haven't seen my view yet:)

              I agree, a global search will do. I was just sharing my first touch experience with Seam not knowing how those beans were defined initially.

              Generic JSF allows for multiple configuration files BTW? For me a total centralized mangement model is as bad as a annotation-based total "distributed" model.

              What I'm doing now with jacn (http://jacn.sf.net) does away with XML and unifies the bean mangement model of JSF and Spring in simple Java, something Seam seems to have achieved to some extent with annotations. So I'm looking at Seam with great interest.



              • 4. Re: trace the origin of EL variables
                Bing Ran Newbie

                 

                "gavin.king@jboss.com" wrote:
                Huh?? "hotel" is defined in an @Name annotation on a Java class. In my IDE it is incredibly trivial to do ctrl-shift-G and get a list of all @Name annotations in the project. Of course, an even more faster way is a text search on @Name("hotel"). This is every bit as easy as scanning a thousand-line XML file for name="hotel" or whatever.



                The "hotel" varaible is an outjected variable and does not have @Name annotation. I guess I can search for @Out

                • 5. Re: trace the origin of EL variables
                  Jacob Hookom Newbie

                   

                  "bran" wrote:
                  Maybe this is the way annotation does things. I'm lost when I try to trace the origin of the EL variables; they're not in the faces-config.xml, nor are they implicit objects. I end up doing a gloabal search in the java files to find out where they're defined: either managed beans or outjected variables. The definitions scatter everywhere. I'm worried that this could hurt the maintainability of larger projects.



                  Tracability is a big concern with EL, you have that separation between Java code and document definitions (XML-HTML). Annotations actually increase maintainability IMHO, because you are able to direct your search, directly to the context of state and behavior on the object itself.

                  FWIW, Facelets does help with EL maintainability since any time an EL expression is the cause of an exception, it will produce views like:

                  https://facelets.dev.java.net/nonav/docs/dev/error.html

                  Letting you know what file and where in that file the exception occurred.