We launched new forums in March 2019—join us there. In a hurry for help with your website? Get Help Now!
    • 32963
    • 1,732 Posts
    Hi Everyone,

    Welcome Operation MODx - Revolutionizing the CMS World

    In the mailing list we were on the Topic of an advance Template Variable System (TVS) which was aliased Template Objects (or Template Variable Objects - TVO). These object would use classes, etc, correct? And could be used from inside snippets, etc.

    While thinking about I came up with a simple idea. How about being able to call create a TV that inherited it's properties from another TV? Or being able to call a function on a TV?

    You see, all TVs would now be object oriented which would be based on a simple class.

    For example:

    [*pagetitle::toUpperCase()*] - this would call toUpperCase() function on the pagetitle TV object thus causing it to be rendered as uppercase text

    [*pagetitle::length*] - this property would return the length of the pagetitle variable

    There is virtually no limit to what you can do:

    [*myTVO::changeFormat("jello")*] - this TVO is be based on a custom class that inherits from the base class

    These functions and properties only could operate on the outputed value of the TV. So you could still use [*myTVO*] as normal but if you need to execute a function then use [myTVO::functionName(param1,param2,paramN)*]


    What do you think?
      xWisdom
      www.xwisdomhtml.com
      The fear of the Lord is the beginning of wisdom:
      MODx Co-Founder - Create and do more with less.
      • 22303 MODX Staff
      • 10,725 Posts
      You got it Ryan. This is exactly what I was getting to. As a matter of fact, there is an expression language already available to describe and access the taxonomy objects and functions. It's called OGNL, or Object Graph Navigation Language, and it provides a wonderful way to access your objects with simple expressions. Check it out at http://ognl.org ... I had forgotten about all this for a couple of years, and when I saw the opportunity to contribute to a CMS project that I love so much already, I couldn't resist bringing this up. As you can see, they use their WebOGNL to bind UI components with controllers (if you are familiar with MVC patterns) in much the same way as we are considering it, though I think in the context of MODx, this is even cooler.

      So just refine your syntax a little, and I think anyone could be able to understand and use these tags in a very short time; to build wonderful, custom web applications, of course.
        • 6661
        • 119 Posts
        Hi Everyone,
        While thinking about I came up with a simple idea. How about being able to call create a TV that inherited it's properties from another TV? Or being able to call a function on a TV?

        For example:

        [*pagetitle::toUpperCase()*] - this would call toUpperCase() function on the pagetitle TV object thus causing it to be rendered as uppercase text

        What do you think?

        This is great and reminds me very much of a system I used to work with for handling stock data and displaying it. The fornat for that was similar, something like ##LastSalePrice(decimalFormat)##. But it does seem like existing functionality that something like Smarty offers via filters and modifiers. I'm not suggesting Smarty be bolted on top of the templating because I have heard it would cost too much in terms of performance but it might be worth looking at how they handle this on the front-end. I think anytime you are running TV through functions you will have some sort of performance hit. That said, this is a GREAT idea and feature. I'm curious, we would the functions be stored? Would MODx ship with some common ones such as for toUpperCase() and date formatting functions? These are the most popular in my experience, especially if I maybe want to display a press release date as: May 10, 2005 but on the homepage where I list the last 3 press releases maybe I want to display it differently, like 5/10/2005, etc.

        Dave
          • 32963
          • 1,732 Posts
          ...As a matter of fact, there is an expression language already available to describe and access the taxonomy objects and functions. It's called OGNL, or Object Graph Navigation Language, and it provides a wonderful way to access your objects with simple expressions. Check it out at http://ognl.org ...

          So just refine your syntax a little, and I think anyone could be able to understand and use these tags in a very short time; to build wonderful, custom web applications, of course.

          I'm not so sure I understand the ognl syntax. Is that the syntax you want me to use?

          I would think that [*pagetitle::toDate()*] would be ok and easy to understand? Or maybe something like [*pagetitle->toDate()*]?

          So which syntax should we work with ?

          1) [*pagetitle::toDate()*] - my favorite smiley

          2) [*pagetitle->toDate()*]

          3) [*pagetitle#toDate()*]

          4) [*pagetitle?toDate()*]
            xWisdom
            www.xwisdomhtml.com
            The fear of the Lord is the beginning of wisdom:
            MODx Co-Founder - Create and do more with less.
            • 32963
            • 1,732 Posts

            ...I think anytime you are running TV through functions you will have some sort of performance hit.

            I think it should be just as fast as running pure php smiley

            I'm curious, we would the functions be stored?

            I'm thinking they could be stored inside the database or a folder inside the manager called tvclasses. The database is cool but makes it difficult to edit and distribute shared classes. I like the idea of having a folder called vclasses where you can copy your classes to the folder and it they will be automatically registered and available for use inside the template system.

            What do you think (folder or database)? I'm all for the automatic registration tvclasses folder


            Would MODx ship with some common ones such as for toUpperCase() and date formatting functions?

            Yes there will be a built-in base class called TVClass (or similar) will some common functions such as toDate, toInt, toFloat, toCapitalize, toSentence, toUpper and toLower. Got any more functions you would like to see as default?

            From this base class you can then create custom classes similar to how you would create a php class object:

            #@Name:MyTVO
            #@Description: My TVO Class Object
            class MyTVO extends TVClass {
            // code here
            function sayHello($name){
            // code here -
            }
            }

            You then save the file (e.g. mytvo.class.php) and store it inside the manager/tvclasses/ folder. When you log into the manager you will then be able to modify or create a new TV to use your "My TVO Class Object" class.

            On you page you could then use [*greetings::sayHello("MODx User")*]

            It's very simple indeed. You don't have to worry about the behind the backend binding stuff. All you will see is a drop down list showing the Registed TV Objects and you can just select one for your TV smiley

            PS. It's kina like changing channels on your TV - premium channels - lol
              xWisdom
              www.xwisdomhtml.com
              The fear of the Lord is the beginning of wisdom:
              MODx Co-Founder - Create and do more with less.
              • 22303 MODX Staff
              • 10,725 Posts
              Wasn't necessarily saying the syntax was bad, just look at some of the advantages of the shorthand when you start talking about deep hierarchical attributes on a single object. The actual punctuation in OGNL is dot notation; very standard object oriented reference, and I was simply implying we would need something similar to make the model work effectively. I have no problem with any of the symbols we might use to get there. I'm originally a java guy, and the dots just make more sense to me. ;-)

              And with caching similar to the snippet caching mechanisms, I think performance will be less of an issue that we think... I really think this would revolutionize CMS and allow average CMS users to be able to create real web applications.

              As for default objects to ship with the product, you would of course have the classes for strings and all the standard types of primitive objects, maybe a set of web form classes, a user profile taxonomy, and whatever else we decide is important for core CMS functionality. I'm still love how small and concise my sites are since using this product, and no matter what we add, that would be my number two goal (behind performance).
                • 22303 MODX Staff
                • 10,725 Posts
                Almost forgot, we could also provide the core taxonomy definition in XML, and then control upgrade paths by using XSLT to transform it. I've used this technique before, and it works very well.
                  • 32963
                  • 1,732 Posts
                  Wasn't necessarily saying the syntax was bad, just look at some of the advantages of the shorthand when you start talking about deep hierarchical attributes on a single object. The actual punctuation in OGNL is dot notation; very standard object oriented reference, and I was simply implying we would need something similar to make the model work effectively. I have no problem with any of the symbols we might use to get there. I'm originally a java guy, and the dots just make more sense to me. ;-)

                  The reason why I use "::" is because it seems more visible than "." and it's kinda unique.

                  [*pagetitle::toUpper()*] is more readable than [*pagetitle.toUpper()*]

                  By looking at the two I can easily identity the variable and the function is the case of "::" but I would have to take a second glance to note the difference in the case of the "."

                  I'm a Javascript and VB guy so I can understand the case of using dots but "::" seemed much easier to read in this case smiley
                    xWisdom
                    www.xwisdomhtml.com
                    The fear of the Lord is the beginning of wisdom:
                    MODx Co-Founder - Create and do more with less.
                    • 32963
                    • 1,732 Posts
                    Almost forgot, we could also provide the core taxonomy definition in XML, and then control upgrade paths by using XSLT to transform it. I've used this technique before, and it works very well.

                    Hi I was thinking about using pure php classes with automatic class object registration. See [ur=http://vertexworks.com/forums/viewtopic.php?p=34#34l]my post here[/url][/url]
                      xWisdom
                      www.xwisdomhtml.com
                      The fear of the Lord is the beginning of wisdom:
                      MODx Co-Founder - Create and do more with less.
                      • 34162
                      • 1 Posts
                      But why not just borrow the syntax from Smarty?

                      [*pageTitle|upper*]
                      [*pageTitle|truncate:40:"..."*]

                      Using date_format to format the date:
                      [*published|date_format:"%Y/%m/%d"*]

                      I think you'd want to be able to stack them, too:
                      [*pagetitle|upper|truncate:40:"..."*]

                      Maybe it's just me, but if viewed from a non-geek perspective, I think those examples would be a lot less scary than all the x->y() methods -- looks too much like math. ;-)

                      Of course, last month I went and spent a couple of days with the folks developing ModernBill. Their new system uses Smarty for templating, XML to pass all data, and a system of overloadable objects and it is easily the slickest framework I have ever seen. The entire application is written against their own API so there are truly no limits to what it can be made to do. Reading the business logic or even their display templates is like beholding a work of art...

                      I only say that to say that I left heavily biased towards some of their methods and would like to eventually sneak some of them into our little project-- especially some of the ways they deal with allowing the system to be upgraded despite end user customizations. smiley