We launched new forums in March 2019—join us there. In a hurry for help with your website? Get Help Now!
    • 29791
    • 2 Posts
    I found Modx very interesting on the surface. I can appreciate all the work that goes into building tools like this (having built a few myself), but I must comment on something.

    I was just perusing the code, and the second file I opened disappointed me. It reminded me why I quit using Mambo and Joomla.

    User interface code does not belong in PHP files. Period.

    When will "professional" software stop repeating amatuer mistakes? I mean come on. All the buzzword compliance you mention on your site, you failed to mention (imho) the most important one. MVC - Seperate your PHP code from your presentation code. Specifically:

    HTML/Javascript/Language text (the last being the hardest I admit) should not be contained in your php files that drive the functionality of your system. This makes it very hard to internationalize and customize the management side of the application.

    Just my .02

    Cheers and kudos for a nice app.

    Mark
      • 25663 MODX Staff
      • 12,272 Posts
      We didn’t mention MVC because it’s not a reality right now. You’re looking at a starting point and our eto legacy. wink
        Ryan Thrash, MODX Co-Founder
        Follow me on Twitter at @rthrash or catch my occasional unofficial thoughts at thrash.me
        • 22303 MODX Staff
        • 10,725 Posts
        Quote from: thetazzbot at Sep 27, 2006, 11:48 AM

        I found Modx very interesting on the surface. I can appreciate all the work that goes into building tools like this (having built a few myself), but I must comment on something.

        I was just perusing the code, and the second file I opened disappointed me. It reminded me why I quit using Mambo and Joomla.

        User interface code does not belong in PHP files. Period.

        When will "professional" software stop repeating amatuer mistakes? I mean come on. All the buzzword compliance you mention on your site, you failed to mention (imho) the most important one. MVC - Seperate your PHP code from your presentation code. Specifically:

        HTML/Javascript/Language text (the last being the hardest I admit) should not be contained in your php files that drive the functionality of your system. This makes it very hard to internationalize and customize the management side of the application.
        @thetazzbot:First, which file was the second you opened, just out of curiosity?

        Next, I just want to say that I agree almost 100% with all of your observations here, and as a founder of MODx, my goal is to address every one of them with the 1.0 release of MODx. I’ve spent the last year researching and testing out various PHP MVC solutions, as well as various OR/M tools, in my own effort to design a proper, object-oriented version of MODx that completely separates design from logic in the core code, is designed to the strengths of PHP, and works on widely available hosting configurations (i.e. PHP 4.3/MySQL 3/4) while still taking advantage of the latest PHP advancements and hosting technologies when available. Ultimately, I believe this effort will bring the product one-step closer to what I think is going to be an evolutionary approach to the traditional MVC pattern, and a much more professional product.

        That said, and though you are very correct in your observation that there is presentation code mixed with PHP, especially in the management interfaces, you can already use MODx to build websites where the presentation and logic is completely separated, despite the poor manager architecture and wildly procedural code in the current core. The important part of MODx, and the reason I have decided to invest so much time into this community, after similar experiences with many PHP CMS systems, including MD-Pro, PHP and PostNuke, Mambo, and others, is that the approach to templating and template parsing is uniquely simple, and IMO, represents the most flexible CMS engine I’ve encountered. Combine this usability and flexibilty with a proper architecture and core framework, and I see a great future for MODx ahead.
          • 29791
          • 2 Posts
          Although there are arguments for and against it, and I personally am on the fence, I use the Smarty template engine for our current product. This has its ups and downs. During a recent discussion with our template designers and webmasters, I proposed removing Smarty and using PHP templates for the presentation logic. They replied that they prefer the smarty syntax as its less wordy and less likely to cause harm.

          Im not proposing that you alter your development roadmap, but as a developer I was a bit surprised by their response.

          btw the file i was referring to was snippets/weblogin/webchangepwd.inc.php

          I hope you do not take this as negative criticism because it is not my intent. Only constructive criticism. Im my own work, there are plenty of things wrong that I did not "intend" to do. We all code ourselves into a corner once in a while.
            • 25663 MODX Staff
            • 12,272 Posts
            It’s highly unlikely there will ever be anything but the current template methods distributed with MODx, and it’s a virtual certainty it will never be Smarty. Smarty is great, but pretty much antithetical to the MODx philosophy. If you can code a sample HTML file, you can use MODx templates.

            You definitely picked one of the biggest offenders in webchangepwd.inc.php ... lol ... a better example of how MODx is working and will continue to progress can be seen in Ditto, Wayfinder and Jot I think.

            Keep the feedback coming, definitely no offense taken, and look for very cool things soon. wink
              Ryan Thrash, MODX Co-Founder
              Follow me on Twitter at @rthrash or catch my occasional unofficial thoughts at thrash.me
              • 22815
              • 1,097 Posts
              Snippets are not part of the MODx core, and indeed many are contributed by "amateurs". In many cases, separating out presentation from logic in snippets like that is just going to bloat the code. You don’t always want to have a template, a language file and a script for some very basic function.

              As different snippets can be used, true customisation and internationalisation is possible without needing MVC. One of the points of MODx is that it is modular. Whilst many snippets have configuration options, and many allow you to specify a template, at some levels those choices will be made by using a different snippet.

              Thus, MODx is flexible in many different ways. You can get something up and working quickly with a dirty snippet. But if it works, who really cares? Website visitors are more important than people poking around your source.

              What we have with MODx is something that allows for the most appropriate approach at each stage.
                No, I don't know what OpenGeek's saying half the time either.
                MODx Documentation: The Wiki | My Wiki contributions | Main MODx Documentation
                Forum: Where to post threads about add-ons | Forum Rules
                Like MODx? donate (and/or share your resources)
                Like me? See my Amazon wishlist
                MODx "Most Promising CMS" - so appropriate!