We launched new forums in March 2019—join us there. In a hurry for help with your website? Get Help Now!
    • 39932
    • 483 Posts
    You are absolutely correct. smiley However, Element Category Access provides access to an entire Element Category. If you categorize in a manner similar to name-spacing (which many do), you can't lock down individual components of the same code. Of course, like anything else... how it is used will determine its usefulness.

    An aside, changing Element ACLs via the front-end seems to me that it would introduce a bunch of security holes.

    I haven't been able to break down the code into individual parts without writing a ton of support snippets. The code to merge all child files into one run-able file is exactly 45 lines (and that it with very liberal comments). Under Snippets, I was not able to do this reliably. I got to approx. 9 individual backend snippets (and I'm estimating...) and 350 lines of code before I quit.

    I generally feel that resource groups are much more flexible than ACLs. A lot of time and energy was put into the resource and template parsers and it seems to me that is where the best optimizations in ModX occur.

    So, for me, the big deal was for debugging (searchability) and security. I wanted a front-end editor that supported features similar to intellisense for your own code and some great tooltips over the individual parts. And, as I said, I'm an Object Oriented Programmer, so there are other neat perks that I must have.

    So, really, this whole thing was about my ability to code and debug super fast. Since I teach other programmers, I needed them to be able to do the same thing. I just finished the bulk of the front-end editor last night, so when I do the screencast for that, we'll see how it turned out.

    Thanks so much for the active comments, by the way! They help a lot! I feel, at this point, that I must say: "I'm not knocking ModX or its capabilities at all." I chose ModX over Drupal and the others specifically because of its philosophy on how it contains, manages and parses Elements and Resources. It's cleaner, faster and easier to develop in by a long shot. And there are no complicated libraries to learn. Most important, it encourages its developers to do the same thing. Think concisely, code precisely, and reap the rewards. I'm trying to accomplish the same thing, but add to the environment in my own way. I feel like this accomplishes this while adding even more to the incredible flexibility of the platform as a whole. [ed. note: fuzzicallogic last edited this post 11 years, 9 months ago.]
      Website: Extended Dialog Development Blog: on Extended Dialog
      Add-ons: AJAX Revolution, RO.IDEs Editor & Framework (in works) Utilities: Plugin Compatibility List
      Tutorials: Create Cross-Context Resources, Cross-Context AJAX Login, Template-Based Actions, Remove Extensions from URLs

      Failure is just another word for saying you didn't want to try. "It can't be done" means "I don't know how".
    • It sounds like you're really digging into MODX and having a blast in OOP and leveraging the parser and caching. That's super cool and I'd love to speak with you in further detail about this.

      I still feel like I am missing something. I watched the video and don't get why you would use this and for what purpose. I see what you're doing and get the IDE bit but don't relate it to an end product. It seems like a very interesting use of MODX and seriously would encourage you to keep going but in the first sentence of the first post I'd like to see the answer to "What does this do? What you would use this for"

      Picture this: "a set of bristles affixed to a wooden block with a 4' handle attached at an angle that you hold in your hands and move back to forth. You can also move it fore to back."

      Without my naming it you can't see the purpose or the use of the thing. It's a push broom and it's purpose is to clean and move debris from a floor or flat surface. It was accurately described but doesn't tell me it's purpose or how it can be used? In marketing we often as the question: "What problem does it solve?" but sometimes basic utility is sufficient. Why you would use something is paramount to how you use it.

        Author of zero books. Formerly of many strange things. Pairs well with meats. Conversations are magical experiences. He's dangerous around code but a markup magician. BlogTwitterLinkedInGitHub
        • 3749
        • 24,544 Posts
        Quote from: fuzzicallogic at Jul 06, 2012, 08:12 PM
        You are absolutely correct. smiley However, Element Category Access provides access to an entire Element Category. If you categorize in a manner similar to name-spacing (which many do), you can't lock down individual components of the same code. Of course, like anything else... how it is used will determine its usefulness.

        Excellent point.



        ------------------------------------------------------------------------------------------
        PLEASE, PLEASE specify the version of MODX you are using.
        MODX info for everyone: http://bobsguides.com/modx.html
          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
          • 39932
          • 483 Posts
          ... I'd like to see the answer to "What does this do? What you would use this for"

          I kind of figured that IDE would implicitly define all of that, but thinking on all of the IDEs... none of them really do things in the way that I'm trying to do it. So... Let me respond, and I will edit my post later with a more succinct response.

          RO.IDEs is to be an actually fast web based IDE. The key to this is load times and arbitrary organization/categorization. For instance, in ModX, every time you save a Resource, the entire page reloads. More importantly the "file tree" reloads very slowly. Now, its way better than back in 2000, but still slow.

          Additionally, over 65% of programming is scrolling and reading. Trying to find where you're going to type often takes more time than typing it. With small succinct resources, each having a name you can identify with a tooltip that will help you when you can't, you limit scrolling and reading significantly. Often times we have to spend time messing with Ctrl-F just to get to where we want to get to... And we keep clicking "Find Again" or some other such nonsense. Searchability will help you find your code even faster (especially because it is in succinct parts).

          Finally, code is often not well organized. Often this is out of necessity or development flow. If you can organize your code without affecting the structure of the program, then you've just saved yourself a lot of scrolling and reading. It's like automatic bookmarking for code, but better.

          So, what does this do? It saves time... Load times, scroll time, reading time. You just work the way you want to work. And it doesn't matter how you organize it as long as it is organized well enough for you to find.

          Thanks for asking that question. I just assumed others would get that.
            Website: Extended Dialog Development Blog: on Extended Dialog
            Add-ons: AJAX Revolution, RO.IDEs Editor & Framework (in works) Utilities: Plugin Compatibility List
            Tutorials: Create Cross-Context Resources, Cross-Context AJAX Login, Template-Based Actions, Remove Extensions from URLs

            Failure is just another word for saying you didn't want to try. "It can't be done" means "I don't know how".
            • 39932
            • 483 Posts
            Empasizing on my previous answer: ModX is the first environment that I've been in that utilizes a great combination of arbitrary organization with consequential organization. It is literally the fastest I have ever developed. But when I noticed that I didn't have the same power for all of my ModX code (too much arbitrary for Snippets, too much Consequential for Resources) I realized I could get the best of both for both.

            RO.IDEs is more ModX for more ModX Elements.
              Website: Extended Dialog Development Blog: on Extended Dialog
              Add-ons: AJAX Revolution, RO.IDEs Editor & Framework (in works) Utilities: Plugin Compatibility List
              Tutorials: Create Cross-Context Resources, Cross-Context AJAX Login, Template-Based Actions, Remove Extensions from URLs

              Failure is just another word for saying you didn't want to try. "It can't be done" means "I don't know how".
              • 39932
              • 483 Posts
              Editor Update



              All Editors are nearly complete. The system retrieves and saves data correctly. Simply have to style and add "New XXX..." functions. I'm almost inclined to turn it into a full solution allowing Chunks, Resources and Templates, as well, but they already fit with most of these philosophies and there are plenty of ways to create/edit these files from the front end.. Previews will begin later this evening and I will get to work on the Packaging.
              [ed. note: fuzzicallogic last edited this post 11 years, 9 months ago.]
                Website: Extended Dialog Development Blog: on Extended Dialog
                Add-ons: AJAX Revolution, RO.IDEs Editor & Framework (in works) Utilities: Plugin Compatibility List
                Tutorials: Create Cross-Context Resources, Cross-Context AJAX Login, Template-Based Actions, Remove Extensions from URLs

                Failure is just another word for saying you didn't want to try. "It can't be done" means "I don't know how".
                • 39932
                • 483 Posts
                New Screencasts on the Way!

                Now that Extended Dialog is in Beta, I can focus on creating more adequate screencasts, including showing the RO.IDEs front-end. RO.IDEs is now fully capable for Snippets, Plugins, CSS, and JS. I'm trying to decide whether or not to develop for Resources and Chunks in the front-end, but this is a tough decision.

                On the one hand: these are more than adequately handled by the MODx Manager. ACLs for Resource Groups are what I desired for the code it currently handles. I also wanted to reduce load specifically for editing CSS and JS. Given these parameters, it is not needed for Resources and Chunks.

                On the other hand: RO.IDEs does not feel like a complete solution for secure Front-End development, and large scale project management without it. The purpose of this was to allow for fast editing and debugging, but also to lock code that did not need to be adjusted. There by reducing reintroduction of bugs due to conflicting checkouts/merges. Note: While RO.IDEs does not specifically handle versioning yet, this is a goal for large-scale projects.

                P.S. If you are interested in trying out Extended Dialog for your dev blog, send me a private message or e-mail or via my profile. [ed. note: fuzzicallogic last edited this post 11 years, 7 months ago.]
                  Website: Extended Dialog Development Blog: on Extended Dialog
                  Add-ons: AJAX Revolution, RO.IDEs Editor & Framework (in works) Utilities: Plugin Compatibility List
                  Tutorials: Create Cross-Context Resources, Cross-Context AJAX Login, Template-Based Actions, Remove Extensions from URLs

                  Failure is just another word for saying you didn't want to try. "It can't be done" means "I don't know how".