On March 26, 2019 we launched new MODX Forums. Please join us at the new MODX Community Forums.
Subscribe: RSS
  • But isn’t it ordering and navigating documents, not snippets, templates or chunks? I’m not trying to be obtuse, but it really seems to me that all Wayfinder does with elements is include them by name.
    • It also determines if the viewer has permission to see them. If the resources are published, marked for deletion, or marked to show in the menu. There are also various ways to order the items, as well as a selection of fields to choose from for the link text and various <a> element attributes. And it handles weblinks. It does a great deal more than just list items.
        Studying MODX in the desert - http://sottwell.com
        Tips and Tricks from the MODX Forums and Slack Channels - http://modxcookbook.com
        Join the Slack Community - http://modx.org
      • Quote from: slikts at Sep 10, 2010, 09:18 AM

        @BobRay: Does Wayfinder really do anything with elements, not documents, that it couldn’t with a filesystem? That would be strange.
        No, and that’s a good point. However, having elements in the DB allows them to have default properties and also allows other snippet to run them, get their code, or get their default properties via xPDO. It also allows MODx to see if the user has the correct permissions to run them.
          Did I help you? Buy me a beer
          Get my Book: MODX:The Official Guide
          MODX info for everyone: http://bobsguides.com/modx.html
          My MODX Extras
          Bob's Guides is now hosted at A2 MODX Hosting
        • @sottwell: You tell me to pay more attention, but you haven’t noticed that I’m explicitly not arguing for moving documents to the filesystem, but just elements. You know, snippets, chunks and templates. They don’t have indexes, and they’re not sorted at all, because they’re never listed for the user (manager aside). Did you think that I was arguing to move everything, including content, to flat files? That’s some uncharitable interpretation.
          • Quote from: slikts at Sep 11, 2010, 09:30 AM

            @sottwell: You tell me to pay more attention, but you haven’t noticed that I’m explicitly not arguing for moving documents to the filesystem, but just elements. You know, snippets, chunks and templates. They don’t have indexes, and they’re not sorted at all, because they’re never listed for the user (manager aside). Did you think that I was arguing to move everything, including content, to flat files? That’s some uncharitable interpretation.

            You can already move ypour snippets, chunks & templates.
            Most of my chunks and snippets are flat files with the possibility to override them with a DB Chunk.

            You can easily build a class with a method to retreive your chunks from the filesystem too. I don’t really like DB editing, but it can be really useful. It really depends on the code involded (size).
            • I wish I knew how to make real ordered lists here, because it would make the text more readable. I’ve summarized the discussion into lists of arguments and counter-arguments. Sorry that there’s so much text, I tried to make it as short and clear as possible.

              Arguments in favor of database storage for templates, chunks and snippets:
              1. Databases are more flexible because they have more sorting and searching features.
              2. Databases perform better because they cache data in memory.
              3. Databases are more secure because you can handle permissions at a higher level.
              4. Storing metadata in the database is more elegant than in file comments.
              5. Databases are better at versioning data.
              6. Databases offer more reliable automatic code deployment, especially to multiple servers.
              7. Using a database prevents editing conflicts.

              Counter-arguments for all but the 6th point:
              1. The flexibility databases offer is real, but it’s just not required for templates, chunks and snippets. These elements are just retrieved by identifiers and parsed or written to, everything a file system can do. The naming limitations of file systems are acceptable, because only the developers should see template, chunk and snippet names, categories and descriptions.
              2. Caching in memory only starts to matter with high loads, and sites with high loads probably won’t be running in a shared hosting environment without access to solutions like opcode caching. Writing to memory instead of a disk makes no real difference, because templates, chunks and snippets are for the business logic and structure layers of the system and their development and deployment shouldn’t be very write-intensive unless you’re abusing templates, snippets or chunks for storing content.
              3. Data in a database is more vulnerable, because database users are more likely to have write permissions for all tables by default, while the HTTP server user is less likely to have write permissions for all files by default, especially in production environments. This is because PHP files are unlikely to contain editable content, while databases are almost guaranteed to. Storing code in a database means a SQL injection vulnerability can give away control over more than just the content layer, and SQL injection vulnerabilities are common, because SQL is often generated dynamically based on user input.
              4. The template, chunk and snippet metadata is only a development aid and it would be a side-effect if it made a difference in the site. Template, chunk and snippet identifiers, categories and descriptions for flat files would simply be file names, locations and comments.
              5. Evolution doesn’t store version history for templates, chunks and snippets, and its "undelete" function only applies to documents, and even if it did version templates, chunks and snippets, it still would be a substandard VCS.
              6. I agree that databases could be more reliable for code deployment than other tools.
              7. Using a database prevents editing conflicts by simply preventing concurrent editing. A real VCS would instead allow you to resolve editing conflicts while still supporting concurrent editing.

              Arguments for using file storage for templates, chunks and snippets:
              1. The best development tools only support editing code on file systems, but because MODx stores templates, chunks and snippets in the database, you’re either locked to using MODx as a substandard IDE or using a workaround, and both times the cost of increased complexity will be less time to spend on tasks that could create more visible added value, because attention is a limited resource for humans.
              2. It’s harder to make your code read-only by default if it’s mixed with editable content in the database, and coupled with SQL injections being common, this makes MODx sites generally less secure.

              I think that MODx would benefit from moving templates, chunks and snippets to the file system, because the benefits of database storage for these elements don’t stand up to closer scrutiny well, while the advantages like productivity and security of being able to use a real IDE and separate the code layer of the content layer are very clear. MODx could at least support WebDAV for templates, chunks and snippets, so that they could be accessed as files from a mounted drive. I could implement it myself using a library like SabreDAV, but I’m already using time I don’t really have just to post this.
              • Admirable. But for every counter point exists a counter-counter point. For instance, you continually mention DAV as an alternative to database-managed elements. But DAV adds an additional layer of complexity and hosting requirements for end-users, which (I’m assuming) the vast majority of end-users simply don’t want to hassle with.

                MODx is flexible enough to allow you (as a developer) to break it down into whatever complex workflow that works for you, or as easy and convenient to use as editing small snippets within the browsing environment. Sure it may take some ingenuity, but if you peruse our forums you’ll see that it happens all the time.

                Rather than putting so much effort into justifying your disdain for it as a substandard IDE, why not use the same effort into ’opening the box’ and see what you can do to make it work the way you want?
                  lo9on.com

                  MODx Evolution/Revolution | Remote Desktop Training | Development
                • Thank you, but the only server requirement for WebDAV is normal PHP, since it’s just HTTP with additional headers. It would also work in parallel and nobody would be forced to use it. I’m sure I didn’t say it should replace any other editing method.

                  I don’t think working with the source code would be a better way to understand why MODx is designed to use database storage for templates, chunks and snippets. It would just be a laborious way to understand low-level details.
                  • I read the whole topic. Maybe with some misunderstoods because i’m french.
                    It seems that the "benefits" for database storage approach is mainly from modx point of view (how it is internnaly coded, for example fetching snippet or chunks datas with xpdo) rather that developpers who are using modx to build websites.

                    I can’t say that this approach is wrong since i’m inexperienced with modx revolution, but i’m surely agree that working with files in a IDE has much more benefits for my daily work that open the manager (even if the UI is awesome, but still less efficient than just navigate in folders with a good IDE).

                    The include snippet seems to be the best way, but i think that this is an (acceptable i guess) work around.

                    I don’t think modx revolution will change because this is just how it is design since the beginning, but i do understand that a for php developper , it’s hard to see why storing code in database is something great, in his daily work.

                      [url=http://www.savepoint.fr/index.php?id=38] -petits tuyaux pour les d
                    • I just would like to say another thing :
                      working with svn or git is not an option on big projects. it is the only way to work with 6 or 7 or more people without having to worry about loosing datas or override accidentally someone else work.

                      That’s why it is so important to me that i can store templates etc... in files.

                      It seems that the only way to work with svn or git with modx is to create an include snippets, and then only using chunks, snippets and templats as containers / metadata for a file’s include.
                        [url=http://www.savepoint.fr/index.php?id=38] -petits tuyaux pour les d