Descriptive Terminology = "Semantic Intuitiveness"? (was: MODScripts?)

LOL... I was just thinking today that the most Eto-ish remaining thing is "snippets" and how much I’d LOVE to get rid of that.

I’m partial to includes for the reasons outlined in Adam’s post. Simple, direct and 100% dead on.

Now... that just leaves "Widgets" as the only cutesy sounding name. Maybe formatters?

Includes? Hmmm, I prefer Snippets. Why? I think it’s much nicer to say "MenuBuilder Snippets" than to say "MenuBuilder Includes" - Just me 2 cents.

Formatters? Hmmm, I prefer Widgets. Why widgets? The future is not limited to just formating the out but it will also include Interaction. Consider a button widget. You click on it to invoke some server-side action or event.

Module and Plugin usually refered to external source codes in file system in most CMS that I know. And Snippet remind me of the old FoxPro day which is a little "snippet" code imbeded in the table and compile with the database and executed when the database run.

So the only reference to Module and Plugin is the location of the files not the actual code and the snippet contain the exact code and logic in the database.

Correct me if I am wrong, in Modx all Module, Plugin, Snippet are all imbeded in the database. So if a user want to have a lot of funtionality the database size increase very quickly whether the actual Module, Plugin are being used or not. That will make Modx bloat very quickly.

I propose move Module, Plugin into file system. The only thing Modx care about Module and Plugin are the location of the file so it should have only one record per Module or Plugin. That should prevent the database from bloat. And if Module and Plug are external it would make the installer job easier to deal with. Case in point, QuickEdit when I did the upgrade it did not work out really well.

We might want to rethink how we do Module and Plugin! For that matters we should consider Snippet as well!

What do you think?

Thanks

Quote from: chanh at Aug 24, 2005, 08:34 AM

I propose move Module, Plugin into file system.  The only thing Modx care about Module and Plugin are the location of the file so it should have only one record per Module or Plugin.  That should prevent the database from bloat.  And if Module and Plug are external it would make the installer job easier to deal with.  Case in point, QuickEdit when I did the upgrade it did not work out really well.

Hmmm,

It seems that a few forum software and others are starting to store their codes inside the database. Any ideas as to why they are using this method as oppose to the file system?

IMO, it using the database storage makes backup easier and also makes it eaiser to support versioning in the future.

We just have to compare the pros and cons in doing so.

Versioning is a key consideration, but I’ve honestly never considered the implications of versioning snippets. That’s a great point (and probably a great idea). IMO, if we do versioning, we’re going to need to store versioned elements in the DB for ease of working and simplicity.

Then again, based on seeing Victor’s bootstrap installer (imagine only uploading a 3Kb file to perform an install...it’s really sweet with MD5 checks and .zip decompression of remotely retrieved latest file versions, etc.), I think we could accomplish something very similar with proper filesystem designs.

Furthermore, we could create a backup module that could trigger not only a DB dump but also a .zip archive and remote FTP transfer ... or email to your a gmail account for free remote backups.

As far as plugins and modules go, however, I would love to see them on the file system for no other reason than installing them could become a simple matter of dropping in a folder (like a Photoshop plug-in) and then telling the Manager to activate them. Whether that involves inserting the code into the DB is another thing entirely, but worth thinking about nonetheless.

In every design there is always something to gain and there is always something to lose

We just have to strike a balance between the two

We’re talking about two things here, persistence of code and delivery of code. Both of which, in the case of versioning, would be handled by a developer’s authoring tools and environment. We can not expect to manage this product as a complete CMS and development environment with versioning, but we can offer alternative publishing mechanisms to make it easier to use traditional authoring tools with it. WebDAV/DeltaV comes to mind immediately. This is the standard in web authoring using only the HTTP protocol. Then you have the choice of authoring your CMS resources in a local IDE and manually copying and pasting the code, or publishing using an IDE that supports WebDAV (e.g. DreamWeaver, Adobe GoLive, etc.). WebDAV also has further extensions, known as DeltaV, which I believe were used in architecting and defining Subversion (though I’m not real clear on this relationship), so versioning would be part of this publishing process as well.

Quote from: OpenGeek at Aug 24, 2005, 10:34 AM

We can not expect to manage this product as a complete CMS and development environment with versioning

Why not? Perhaps my definition of versioning is incorrect. Each page of content could have a drop-down for instance of each previously saved version. Simple little (visually, anyway) addition in the manager. No need to make it overly complex.

Because that is not focusing on our core competency, which is the CMS runtime. I do not want a product that tries to redefine the way I develop code. I personally could never stand systems where you entered code or markup via a web page; I would always prefer to author in my preferred IDE, then publish using standard mechanisms (FTP/WebDAV), regardless of how the code is persisted by the framework. So it’s not that we can’t, it’s that we should be focusing on the framework, and leaving the wheel reinvention exercises to the competitors. Just my opinion.

And I meant the development environment more than the versioning. Of course we’ll have the versioning implementation on the server, but why not provide an alternative protocol for working with it. WebDAV fits the bill, simple or complex versioning features withstanding.

And I meant the development environment more than the versioning. Of course we’ll have the versioning implementation on the server, but why not provide an alternative protocol for working with it. WebDAV fits the bill, simple or complex versioning features withstanding.

Now I agree 1000% with that. I don’t want to be an IDE, but I do want to support enterprise CMS features, of which versioning is key!