We launched new forums in March 2019—join us there. In a hurry for help with your website? Get Help Now!
    • 39932
    • 483 Posts
    The RO.IDEs Framework and Editor are designed to take the headache out of coding and debugging. One of the snazziest things about ModX is the ability to split your HTML (and dynamic components) so they may be created, reused, and tweaked at will. It makes ModX more flexible and powerful than CMSes like WordPress, MediaWiki, etc. It also makes development generally faster and easier.

    RO.IDEs is a Resource-Oriented Integrated Development Environment. It expands all of the power of functional fragmenting to nearly every element of the web development experience. View what you want to view. Edit what you want to edit. Code how you want to code, and let RO.IDEs manage the file structure for you. Coding with RO.IDEs is faster, debugging is easier, functionality is more social, and presentation is more dynamic.



    How RO.IDEs Works

    RO.IDEs leverages the power of ModX's document management system, a pre-renderer, and post-parser to allow Resources to become dynamic CSS, JS or PHP. It allows you to move functional Assets (CSS and JS) and Elements (Snippets and Plugins) into ModX Resources. While non-intuitive, at first, this gives a significant number of benefits to all of these. Among these are:


    • Code Parenting - Any Function, Class, or Block is automatically included into its parent file when run.
    • Code Transclusion - Include code from any other RO.IDEs object. Choice of implementation is much more flexible.
    • Arbitrary Categorization - Make groups of Classes, Functions and Statements to find what you need faster and more easily.
    • Code/Namespace Aliasing - By creating a functional alias, others may use your functions and variables without having to know them.
    • Pass-Through Data and Functionality - RO.IDEs runSnippet gives other Snippets (at their choice) functions for debugging and transclusion.

    How to use RO.IDEs (Manager)

    In the back-end, RO.IDEs is quite easily utilized. Simply create a document of the appropriate Template, and code. You may separate your code by taking it out of the parent and placing it in a child document with the correct Template. RO.IDEs will handle the merging when a request is made to that URL. If you are making a RO.IDEs Snippet, just be sure to call [[runSnippet]] with your snippet's name and its parameters; they will be passed to your Snippet.

    How to use RO.IDEs (Editor)

    The Editor is supplied to you in your web-site's Resources. Simply set the Template Variables to dictate what you want to manage and where. You may make multiple copies of the Editor setting different parameters each time. Security: While RO.IDEs does its best to utilize ModX's security, be sure to set the Resource Group or place it in a Context where you can correctly manage access to it. The Editor can create/modify/delete Resources very quickly.

    Once you set your Template Variables, just navigate to your site, log-in and browse over to your Editor. The RO.IDEs Editor was created using the RO.IDEs Editor and you may customize any part of it. It is best to be careful of such changes, however, as they could lead to breakage. Note: If you have URL modifying Plugins, be sure to either a) account for RO.IDEs or b) set the RO.IDEs Ajax Plugin to a higher priority.



    RO.IDEs Packages

    RO.IDEs will be released in two packages. One for the ModX Manager and another for the front-end Editor. The RO.IDEs for ModX Manager package requires only some simple configuration, and comes with 12 Templates, 2 Snippets, and 4 Chunks. The RO.IDEs Editor comes with 9 Resources, 1 RO.IDEs Plugin, 1 ModX Plugin, 8 RO.IDEs Snippets. Thanks to BobRay for pointing me in the right direction.



    Demos and Screencasts

    Although, these were originally made to demonstrate theory and practice, they are still useful until I have time to make better ones. Each one demonstrates a RO.IDEs different language and will have a Front-End and Manager Demo.

    RO.IDEs CSS ModX Manager Screencast Demo

    This 11 minute video demonstrates how RO.IDEs improves your CSS development in the ModX Manager. Through demonstrating this without a dedicated IDE, I hope to demonstrate how much easier it would be with an IDE.

    YouTube: http://youtu.be/Yz1TwkD5ne4



    RO.IDEs PHP ModX Manager Screencast Demo

    This two part series demonstrates how RO.IDEs improves your PHP development in the ModX Manager. This essentially turns ModX into a miniature IDE allowing fully functional PHP projects to be developed directly within ModX. This demonstration explains the RO.IDEs Snippet process and walks through how to do many things directly on a live server. At a later date, this will be edited and revised for size and time.

    Topics covered are: a) how to convert a popular ModX Snippet to RO.IDEs Snippet and why; b) split php code; c) utilize passthrough functionality; and d) include code from other sources.

    YouTube: (Part 1) http://youtu.be/Cj6sno0rKOE

    YouTube: (Part 2) http://youtu.be/-6RYUHO7XJc [ed. note: fuzzicallogic last edited this post 11 years, 8 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".
    • This sounds interesting. I am a rather thick front end dev type and I am not 100% what this does. Is there any way you could show me via a short screencast?
        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
        fuzzicallogic, that all sounds really interesting (especially the editors part), but I'm having a really hard time making sense out of some of it. This, for example:

        Supports ModX Elements as Resources for:
        Plugins
        Snippets

        made my head spin.

        MODX plugins and snippets are already elements and Resources are something else entirely (essentially rows in the modx_site_content table), so this seems to say that the package supports elements as non-elements for elements. And since Resources can't contain any PHP code, as normally used, and snippets can, how would a Resource be used as an element for a snippet (which is already an element)?

        In addition, MODX Resources come with a long list of built-in fields (e.g., longtitle, summary, pub_date, unpub_date, uri, freeze_uri, class_key, isfolder, richtext, etc.), many of which would seem to be unwanted overhead for snippets and plugins. See the full list of fields here: http://bobsguides.com/modx-object-quick-reference.html#modResource


        I'm not trying to be contrary or discouraging here, because your package sounds pretty amazing. I'm just trying to figure out what it is and does and, like Jay, feeling a little thick.


        As for creating a package, the PackMan extra will create some kinds of packages, but you may want to look at a doing a more traditional Transport Package, which is more amenable to being modified over time.

        This extra (MyComponent) might help get you started: http://bobsguides.com/mycomponent-tutorial.html. I'm slowly working on refactoring it to be way better about automating the mundane tasks involved in creating a package. I have semi-working utilities to export objects from the Manager to build files, check and create lexicon and property files, etc, and a bootstrap program that will create the directory structure and some of the standard files for a package and fill in placeholders with the package name, your name, etc. It won't be out for a while, but hopefully the new version will be presentable enough to put up in the development branch on GitHub before too long: https://github.com/BobRay/MyComponent.


        For lots of good examples of how packages are put together and what the optimum directory structure is for creating a package, browse Shaun's (spliittingred) repository at GitHub: https://github.com/splittingred.


        ------------------------------------------------------------------------------------------
        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
          Well, it's YOUR fault, BobRay!! If you hadn't provided the awesome tutorials and cheatsheets on your website, I wouldn't have been able to do this. (The whole dev team is to blame, but I like having a scapegoat)

          I've been attempting to explain techniques like these for quite some time, but have not in the past been able to do so adequately. Since most of my past projects have been confidential in nature, demonstration has never been an option. This is the first public package I've made that quickly and correctly demonstrates some of these techniques. It's all based on two key concepts.

          The one thing that programmers seem to regularly forget is that the data is what the agent wants it to be. For instance, FFFFFFFF is a string in a text editor, a color in an image editor, the number 4,000,000,000+ (I can't do math right now), etc. So... I simply told ModX that Resources are whatever I want them to be. And I told ModX (using ModX) how to "render" the new data.

          The second thing is that "data" vs. "instruction" vs. "content" is all decided by whomever and whatever is reading it. To a computer, instructions are content. To us, not so much... If another agent is able to read the instructions in a quantifiable context, then those instructions are "data". Basically the same as a manual for building a bookshelf.

          Fear not!! I made my first ScreenCast. The link is provided above in the original post (at the bottom). This should give more context to some of what the above post says. I will make others over the next couple of days... One for Plugins Backend, One for JS Backend and One for Snippets Backend. Then I shall make one for each of the Front End editors.

          (Hint regarding Snippets/Plugins: You'll see it in the ScreenCast anyway. eval() can run the code from a resource. All you have to do is make sure that the code is not marked up.) [ed. note: fuzzicallogic last edited this post 11 years, 8 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
            Regarding the Package Tutorials

            Thanks for all of the links!! One of the issues that I'm having is that my addon has no connectors, classes, custom resource types or anything of the things that require files in the components directory. (At least, not yet...)

            I'm not even sure (based on these links) which directories would be pertinent to the addon. Which parts of the tutorials would be pertinent to just adding Templates, Snippets, Plugins and Resources? Can this even be done without a connector or class? All of the tutorials seem to require one... Maybe I'm simply not understanding the process.

            Thanks again for your help!
              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".
              • 3749
              • 24,544 Posts
              There's very little in a package build script that's strictly required. In theory, it could be just a single build file with all the component code as strings inside it, but usually you want to have some actual files laying around after the install for use as a reference. And if you're going to internationalize it, you'll need a lexicon file or two.

              For a non-trivial snippet or plugin, it's sometimes helpful to move things into a class file, but it's not required. Similarly, connectors and processors can be useful, but also not required.

              My components tend to be sparser than Shaun's in terms of structural complexity and I'd say Jason's are generally sparser yet. Mine a mostly made up of elements and resources.



              ------------------------------------------------------------------------------------------
              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
                • 3749
                • 24,544 Posts
                You're right about Resources, you can use them for anything within fairly loose limits. My point was that when you already have lightweight code elements (plugins and snippets + code in files), why would you want to use a Resource for code and carry all the extra baggage of a resource? What advantages outweigh the costs?


                ------------------------------------------------------------------------------------------
                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
                  This is discussed in the second part of the snippets demo. Three features which I didn't discuss are highlighted there. If you haven't watched the Snippets video, then you'll be missing some. Here are a few features which are not mentioned in the original post:


                  • You may split your code into either functions, or even just a logical group of statements.
                  • Description field can become supporting documentation for any of the below rather than a simple overview of the entire snippet.
                  • You may include code from other packages without copying the code. This can include functions, classes and whole libraries.
                  • Your code is now Indexed. You can use Search to find Comments, Variables, Function calls, etc.
                  • Snippets can now be protected and locked from other users (via whatever security measures you need). If you have a large development department, you can break the code into parts and appropriate it to only those who need access.

                  These capabilities alone make coding more social, faster to edit, easier to read. The ability to report your error without inflating your own code OR breaking the web-page is an added plus. So, in short: stability, readability, editability, searchability and co-operability.

                  Here's another example: You can manage access to your snippets based on context or user group. You could even have multiple versions and choose which to load based on the above parameters. This can make your own code incredibly more simple leading to fewer bugs and holes.
                  [ed. note: fuzzicallogic last edited this post 11 years, 8 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
                    Expanding from RO.IDEs

                    Some further thinking ideas that are not discussed in the original post. The reason this is a separate post is this is not functionality inherent to RO.IDEs but now made possible without having to modify the ModX source.

                    Version Control: Modifications may happen to blocks, rather than the whole snippet. Checkouts and merges happen on whatever level your team needs.
                    Support Documents: Can be removed to a different resource (possibly with their own template). This can create highly dynamic supportive documentation.
                    Code Tracking: Your code can now know (via $snippet, $function, etc) exactly where it is at all times.
                    Which can be used for better debugging and logging of errors.

                      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".
                      • 3749
                      • 24,544 Posts
                      Very interesting stuff. Just one note -- you can also control access to snippet and plugin code in Revo with Element Category Access ACL entries.


                      ------------------------------------------------------------------------------------------
                      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