RO.IDEs Editor and Framework for ModX® Revolution 2.2+

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 12 years, 6 months ago.]

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?

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

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 12 years, 6 months ago.]

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!

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

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

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 12 years, 6 months ago.]

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.

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