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

I just want to offer a little insight regarding Mambo trend. Mambo currently has Components, Modules, Mambots, and Templates. The current installer handle them separately.

In the future version of Mambo there were discussion to merge Components, Modules, Mambots as just plain "Plugins" so the installer will just handle "Plugins" and template.

Components: Full application with frontend and custom backend admin interface
Modules: An application run with Mambo framework and using Mambo admin interface
Mambots: A little inline code that can be inject into anywhere of any content and using Mambo admin interface.
Templates: A set of files including php and CSS to show how the site look.
(Note: all of the above are in the file system, there are only database record that show where these files are located)

Perhaps we should consider along the same line when we furture develop Modx.

What do you think?

That’s exactly where we’re going with this, but I think a little more descriptive seperation than everything as a plugin is in order. The Mambo terminology just isn’t intuitive enough for my taste, but you can’t argue with the fact that they have a huge following.

Sounds like Components + Modules = our newly consolidated Modules, and Mambots = Snippets.

Hmmm,

Seems like this is divine I had the same inspiration last night - lol

Why not merge Snippets/Chunks and plugins? Snippets+Chunks+Plugins = Plugins.

Initially a Snippet was able to listen to System Event. But we later decided to separate the event portion into what is now called Plugins in an effort to not cause confusion.

Now if we were to merge them into one object (Plugin Objects) we will then end up with three types of plugins:

HTML Plugins - HTML Insertable objects that can be added to a web page or listen to system events. These will render an HTML output. The can be used in system settings or other parts of the Manager.

PHP Plugins - PHP Insertable objects that can added to a web page or listen to system events. When used inside a web page they can return values as would a snippet.

Event Handler - PHP Insertable objects that only listen and respond to system events.

We could futher extend this list to include things like:

API Plugins - Extend the Document Parser

TV Plugins - Adds a new TV input type

Widget Plugins - Adds a new widget to TVs

and many many more...

In a nut shell plugins are just little plug-able objects that just plugs into the system!

:D

I never thought I’d see the day when Raymond got on the "less is more!" bandwagon!

It truly is a Divinely inspired moment!

Good ideas!

I’m going to throw one more into the mix Template Plugins or just templates maybe. It’s always bugged me that templates were nothing more than chunks but handled completely differently. They are really the same thing, you just need a way to categorize them somehow from chunks so that you don’t have a long list of chunks in your document editor window. I think this could be the way.

Templates persist site-wide/quasi-globally as it stands now... this would wind up possibly as a way to solve the "unlimited" global variables as well. Perhaps we have a scope for the plugin: per page or global.

Quote from: aNoble at Aug 25, 2005, 10:13 AM

I’m going to throw one more into the mix Template Plugins or just templates maybe. It’s always bugged me that templates were nothing more than chunks but handled completely differently. They are really the same thing, you just need a way to categorize them somehow from chunks so that you don’t have a long list of chunks in your document editor window. I think this could be the way.

Okay, here’s a really wild, out-there, the caffine must be getting to me, idea.

What if we got rid of snippets, chunks, plugins, templates, etc and made them all TVs? This would work together with the idea of having per-page TVs and global TVs. Every TV could have any sort of type assigned to it and could even include executable php code which could respond to events. That way you could use richtext editors for templates and chunks, you could pass your snippet output through a widget of any kind.

Maybe I’m taking less-is-more to an extreme. It’s probably just the lack of sleep talking but I had to throw it out, if for no other reason than to achieve the rank of "certifiably crazy"

You know, I’m not afraid of extremes either ... but this might make it more difficult to describe it. How we implment it underneath the terminology is another issue entirely however. Dealing with a smaller set of variables should make for a faster, more flexible system in the end.

And now that I think about it, I also recall conversations when we fisrt started this project about the system in reality just being a plugin manager. Heck, that’s even the way Adobe built InDesign ... the entire application is a series of chained plugins.

Get rid of the TP name ... and I’m on the crazy train!

well .... doh ... I have no clue what Adam meant but if I get a bit of what he’s saying this would break most concepts of the norm and would put modx way out there with Raskin and ahead of a lot of other cms’s.

I love it!

Now, what do the big bad boys here have to say?

ahhh, yes, inDesign. Great system. Anybody can reprogram it so to say and make it into something else. hehe, Photoshop ala inDesign


Ok, Ryan is right about the terminology. so, put in a placebo.
fake it!
Call them what ever but treat them all the same