4 Replies Latest reply on Apr 21, 2004 10:24 AM by joehobson

    How does Nukes evalute statements like $ {config:siteName}?

    dphiggs

      Just starting to use Nukes. I downloaded the souce and had a Site running in a matter of hours! Thanks for the Code.

      I was greping through the code looking at how things work but could not see how Nukes evalutes statements like the following:

      $ {user.WelcomeTo} $ {config:siteName} $ {user.Registration}
      $ {user.MustBe_1} $ {config:minAge} $ {user.MustBe_2}

      This code comes from .../user/module.html file

      Can someone tell me how this code gets parsed? Or give me a hint as to what part of the source I should be looking at.

      I can see that $ {user.MustBe_2} gets values from a resouce.properties file and I think $ {config:siteName} gets its value from the MBean attribute SiteName.

      Any Help Would be appreciated

      Thanks

        • 1. Re: How does Nukes evalute statements like $ {config:siteNam

          The code for that is in :

          nukes/nukes/src/main/org/jboss/nukes/io/NukesWriter.java

          it configures a stack of filter, the one taking care of the properties is WriterParser.java (in the same package).

          it use a map of KeyHandler :

          public interface KeyHandler
          {
           /**
           * Returns the value for the specified key.
           * If the key does not match a value, it must return
           * the null value.
           * @param key the specified key.
           * @return the matched value, can be null.
           */
           String forKey(String key);
          }
          


          the map binds the namespaces and the KeyHandler implementations.

          for instance : ${A:B} will lookup the KeyHandler under the key "A" and will call : forKey("B"). The returned value is replaced in the stream.

          it is possible to register a key handler implementation on the core module

          julien


          • 2. Re: How does Nukes evalute statements like $ {config:siteNam

            Some data is kept in the nukes database. MySql users can use the following commands the to Site Name and Slogan.

            update nuke_services_attributes set pn_value = 'Your Web Portal' where pn_aid = 'SiteName';

            update nuke_services_attributes set pn_value = 'Slogan' where pn_aid = 'Nukes on JBoss';

            • 3. Re: How does Nukes evalute statements like $ {config:siteNam
              hxp

               

              "porterrickabaugh" wrote:
              Some data is kept in the nukes database. MySql users can use the following commands the to Site Name and Slogan.

              update nuke_services_attributes set pn_value = 'Your Web Portal' where pn_aid = 'SiteName';

              update nuke_services_attributes set pn_value = 'Slogan' where pn_aid = 'Nukes on JBoss';




              Sorry, but in today's context -- J2EE, JBoss, Nukes -- that's just plain _bad_ advice.


              Don't use naked SQL to meddle with your Nukes database.

              It bypasses any interceptors (security, transactionality, etc) or application code (logic, filters, constraints, rules, etc.) that may be imposed by the module or the core.

              It's database-brand dependent (as you say, your code is only supposed to work on MySQL).

              It's error prone (yup, your 2 lines of SQL code above won't even work on MySQL -- re-read it closely ;-> ).

              It's a bad habit to get into.

              Worse yet, it undermines the very good and very important design assumption that Nukes "owns" the database -- and that the Nukes Entity EJBs are the only way in and out of the tables.


              If you want to stay in the stone age, then you might as well just edit MySQL's datafiles directly with a hexadecimal editor, or even better, bang bits directly to your disks by track and sector.

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


              Now, here's how you do it right: use the jmx-console ..... go to the "core module" ....

              http://localhost:8080/jmx-console/HtmlAdaptor?action=inspectMBean&name=nukes.modules%3Aname%3Dcore

              .... find the "SiteName" and "Slogan" Attribute Names, and edit the Attribute Values strings to your liking. Scroll down ~40% of the way down the page and click the "Apply Changes" button.

              Much more civilized ;-)

              -- Howard


              • 4. 3817336

                 

                "hxp" wrote:

                Don't use naked SQL to meddle with your Nukes database.

                It bypasses any interceptors (security, transactionality, etc) or application code (logic, filters, constraints, rules, etc.) that may be imposed by the module or the core.


                Howard, great advice. But for those of us that are used to tinkering with the backend to get it to work, it doesn't come naturally at first. I didn't realize that the JMX console could be used to update this variable, probably the same as this guy. Truth be told, there's so much stuff in the JMX console that it seems confusing and intimidating to newbies.

                But that's not why i posted this message. I'd like to build my own module, or at least play for awhile, but i'm new to world of CMP and EJB and all that stuff. For those of us that are used to writing straight db-dependent SQL queries in our code, what sort of resources can you point us towards to help learn the right way to do it? Books? Code? Wiki? Is there a module in Nukes that does an excellent job of separating the database from the logic the way you describe that it should be? I know that there are many ways to do it and I've seen a few examples in the Nukes code.

                And I'm fine with book learning as well so if you have a particularly helpful resource to get started, mention of that would be appreciated as well. thanks... .joe