Why Not Files instead of a database?

if what folks want is a more powerful editor, with syntax highlighting, a larger workspace, code-completion, function library etc, then give them that.

i’ve seen more than one modx tutorial advise people to do their editing outside of modx, which i think may point to a weakness in modx.

changing the way modx is structured (file-based rather than db-based) seems a rather drastic and indirect way to achieve a better editing interface.

although, perhaps in the short term, at least it gives people more freedom to edit using their preferred editor, rather than having to cut and paste. but it still then requires people to use two different site-building tools, which seems less than ideal.

would it be possible to integrate any/all existing code editors into modx, with plugins? wouldn’t that be a more direct solution? wouldn’t that also be more consistent with the plugin architecture?

Codemirror is a nice basic code editor for Revo

As @einsteinsboi says you can use codemirror as a code editor

With MODX there are plenty of choices

Use firefox with ’its all text’ addon and use any editor of your choice.

Use an ’include’ snippet and use file system and any editor till ready to go live then transfer files to Templates chunks and snippets this is the way I choose to work it allows me to version my files with git easy to go back and undo my many mistakes when I forget what I had before. There is really no right or wrong way. I would not use files on a live system on the internet but might on a secure intranet.

If site is live I use codemirror for quick edits.

MODX is about choice. What suits you.

Static Elements (templates, chunks, etc. are on the filesystem) are on the roadmap for 2.2.

Quote from: allanb at May 05, 2011, 04:35 PM

use file system and any editor till ready to go live then transfer files to Templates chunks and snippets this is the way I choose to work it allows me to version my files with git
...
MODX is about choice. What suits you.

if a user has to go to git to get versioning, does this indicate another missing feature in MODx? Versioning should be do-able in a database environment, no?

Not sure its accurate to say modx is about "choice", when you mean you can choose to use some other piece of software to get the job done.

Use an ’include’ snippet and use file system and any editor till ready to go live then transfer files to Templates chunks and snippets

ouch, sounds like a huge amount of work, isn’t modx supposed to make life easier?

Quote from: rthrash at May 05, 2011, 05:14 PM

Static Elements (templates, chunks, etc. are on the filesystem) are on the roadmap for 2.2.

if so, then why not throw out the database entirely? security is one good item mentioned here, any other advantages of db over file-system?

Quote from: rthrash at May 05, 2011, 05:14 PM

Static Elements (templates, chunks, etc. are on the filesystem) are on the roadmap for 2.2.

I think this is an important step, because it can reduce the query in a database that becomes a problem on shared hosting (Mysql service is down). Alternative to storing static elements may be stored in the second database using SQLite

so, if all features are available with both configs, then during install the user could select "Db" or "File" based install? is that the plan?

thanks for listening to a newb

Quote from: johnywhy at May 05, 2011, 08:17 PM

so, if all features are available with both configs, then during install the user could select "Db" or "File" based install? is that the plan?

thanks for listening to a newb

I suspect it will default to db with the option to save chunks, templates, etc as static elements

Hi johnwhy, thanks for showing interest. There are literally years of architecture work and planning not to mention the actual development that have gone into Revo, which is by a very deliberate architectural choice a database-driven CMS. The reason we did it that way was to allow for very dynamic and fluid sites to be built and managed from within a web browser. MODX will never get rid of the database.

We get it that there are other approaches to doing things that we certainly see the merit in, like chunks and templates being stored on the filesystem (Static Elements coming in 2.2), Versioning (also on the roadmap), etc. We’ll get there in a way that works with all the other moving parts, and maintains a clean migration path between releases. This is no small task. There’s a ton of things behind the scenes and a lot of history you can read in the forums to help get you up to speed with why we’ve done why we’ve done.

There’s also a lot of talented developers like Mark who’s done a Versioning Add-on for Revo and the dudes at Butter which have an Add-on that automagically mirrors the file system to the database via a clever plugin for chunks and templates. MODX really does give you the API and the power to do whatever you can imagine.