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

I prefer "placeholder" to "proxy"; proxy is a rather ambiguous term, depending on your background.  Widgets works for me.  They always mean little odd things that do stuff. Now, who can tell me what a "wobulator" is? (Gary Cornell’s book on QuickBasic was the first time I ever saw the term "widget" or "wobulator")

I like the new list with the exception of the following two items, for what it’s worth...

Quote from: rthrash at Aug 11, 2005, 05:06 AM

[[Capsules]] (currently Snippets & Chunks)
Capsules are holders for little pieces of code and static HTML which you may wish to use on multiple pages. You can set a flag to "exectuable" to denote the Capsule contains logic or code that should be evaulated (like a custom PHP script). (merge snippets and chunks which have almost identical table structures anyway)

I think capsules sounds too Med Tech personally. Why not just get rid of the ’chunks’ terminology and continue calling them both Snippets; this term is already fairly widely known to our target audience, especially by the large base of Dreamweaver designers out there who might use DW Snippets already, and makes even more sense if they can be either static or dynamically generated content.

Quote from: rthrash at Aug 11, 2005, 05:06 AM

Installers (currently Packages & Modules)
Pre-packaged collections of Capsules, Content Fileds, Database Queries, and/or external PHP code that is used to bring additional functionality to or link with MODx. Examples include Forum bridging code to synchronize users, Image galleries, and more.

I really think we need both concepts here. Installers would be these distribution packages that handle all the work of creating and configuring all the various resources it contains. Modules are still separate pieces of code with a specific purpose separate from any installation. I mean, I don’t have to install anything, I could just author and create a simple module with no installation package.

Here’s my take on this

Content  (currently Documents)
What end users interact with in MODx, typically a web page. This can also be a CSS file, a javascript include, downloadable document, etc.

I’m not sure if content covers everything here. I think people would rather call it a PDF document rather than PDF Content

[*Content Fields*]  (currently TVs & [*content*])
You can have as few or as many content fields associated with a page in MODx as you’d like. They can be simple text fields, WYSIWYG text editors for complex data entry, pop-up lists, radio button options, etc. [*Content*] is automatically defined for every page that is created in MODx.

Now this is very nice

[[Capsules]]

I prefer [{Containers}] to Capsules. Hmmmm, the new format [{}] is not bad at all

Display Controls or Widgets

Hmmm, I prefer Widgets to display controls

[+Placeholders+] or [+Proxies+]

Nope! Placeholders are much better.

Installers  (currently Packages & Modules)

Hmmm, We are confusing the two here. Installers are not modules. Two separate code base.

@Content:
a PDF document is Content. Just like a web page is also Content. or a Downloadable file can be content... or a CSS file... or an MP3... or things we’ve yet to figure out!

@Placeholders Proxy:
agreed.

@Containers/Snippets Capsules:
no real argument here either way... just looking for short, semantic, non-cutesy names [[ is faster to type than [{ (no shift combo required) and assocaited with one of the folded in formats already tho... but I can live with anything.

@Modules:
agreed and point taken.

@Installers:
no real need to call them anything... it’s just a module that installs other modules... IOW, it is what it is! We’ll just scratch it entirely from the lingo because it’s superflorous.


Wow! We’re getting close to consensus.

hehe, here I go

@ installers -- hmmm, what happens when I have install-"ed" something? Does the name change? A bit confusing for me. I like the term "module" better.

Installer for me is a utility that allows you place items in a location ready to be used. ie, those programs that litter your system with funky files that make you feel skeptical about.

@ content Fields -- like this! Much more off and going over TV -- also for a newbie the term will peak more interest in regards to looking up the term versus TV which might cause brain farts or soemthing. However, the term "field" through me for a quicky since I was thinking in HTML terms but after a reread I realized that I was right. Strange that a good use of terms made me double think this one. However, after the realization CFs are way more easier to visualize and understand.

@ capsule -- what??? I totally imagined either a "space" capsule or a "Tylenol" one. The term snippet comes across for me as a short/brief script. hmmm

@ widgets -- Like Ryan mentioned will now most likely be confused. I learned back in university that "widget" was something that a company produces -- lolo, probably easier to say and write than "thing-a-mu-bob", "doo dad", "wha-cha-ma-call-it’s".

how about -- affects? however, PhotoShop uses the word "effect" ewww, my understanding of the two would make affect a better choice but ... errr ... "effects" might be better though.

@ plugins >> extensions
@ modules >> plugins
the reason is that if I keep rereading the definitions the difference gets a bit clearer each time for me.

I’m thinking that the core is very simple thereby any change to the core or way things are done the simplicity is now in a more advanced stage -- basically extended. thereby negating the "plugin" idea -- almost got tangled in the "what’s a plugin or module mentality".

and calling "modules" a plugin because they are things that you plugin and work. They don’t really extend the system but add a new functionality (err, yeah, yeah, but isn’t that "extending ?" -- hehe yeah but let’s not go that route ) I’m totally thinking about PhotoShop at the moment.

@ content vs document
hmm, I’ve always thought that content was what was in a document (page). The term document seems more like a file to me -- something like you’d download from the net. While content brings up images of "news" and "information".

In the tree menu the term document seems very appropriate while if I were actually editing I wonder if content might not be easier to understand. Of course, you’re editing the document but the literal focus of attention is on the content (non-physical) rather than the paper (physical) side.

ok, that’s my 2 bytes for the moment.

My votes:

+1 content
+1 content fields
+1 snippets (as combined snippets and chunks with [[]] syntax)
+1 plugins
+1 modules
+1 placeholders

-1 containers
-1 proxies

OK... so I’m going to toss another one in the ring that isn’t totally clear cut and very similar to snippets/chunks. Sorry to repeatedly bang on trying to make the system come across as simpler, but still allowing developers to see that it has a lot of depth.

Why don’t we stop trying to figure out how to explain the subtle and pretty murky differences between plugins and modules and just merge the two into moduels. Modules would then be defined as extending the core functionality and can be as simple as a simple plugin-type application wiht no interface to as complex as a full blown application running inside the manager itself. This would then give us what I think we’ve reached consensus on as our "Tattoo Lexicon":

Tattoo 101
Manager or Control Panel
Where you control content and configuration of the entire software install.

Templates
The centerpiece of MODx around which most things associated with pages revolve. The central gatekeeper almost with the exception of special applications.
There needs to be a simple and direct way for people to quickly create different types of content, like a shopping cart products page, a blog, etc. Do we need sub-templates, or content templates, or content settings?

Content
What end users interact with in Tattoo/MODx, typically a web page. This can also be a CSS file, a javascript include, downloadable document, etc.

[*Content Fields*]
You can have as few or as many content fields associated with a page in Tattoo/MODx as you’d like. They can be simple text fields, WYSIWYG text editors for complex data entry, pop-up lists, radio button options, etc. [*Content*] is automatically defined for every page that is created in Tattoo/MODx.

Intermediate Tattoo
[[Snippets]]
Blocks of text, HTML or code that may contain application logic, that are typically reused multiple times in a site. For example, a Snippet can be the static footer on a website, or a dynamic block of code that generates the site navigation menu as pages are added, moved or removed.

Widgets
Small Tattoo/MODx API extensions/behaviors that take a piece of text or data and transforms it into (typically) more complex elements with dynamic interaction. For example, Rich Text Editors, pop-up list input boxes, display grids and more.
It might be really cool to use a way to define Widget behavior, and the recently introduced Front End Editing, with a modifier on content fields. That way they could even be chained. For example: [*content:editalbe,datagrid*]

Tattoo Grad School
[+Placeholders+]
Undefined system resources that are generated on the fly by code to represent various pieces of data. Need an easy to understand example here.

Modules
Alter or extend the way the core system behaves across the board. Can be as simple as a single file performing a very spefic override to a manager API call (with no interface) or as complex as a full-blown application integration with an integrated management interface.

Quote from: rthrash at Aug 21, 2005, 10:14 PM

Why don’t we stop trying to figure out how to explain the subtle and pretty murky differences between plugins and modules and just merge the two into moduels. Modules would then be defined as extending the core functionality and can be as simple as a simple plugin-type application wiht no interface to as complex as a full blown application running inside the manager itself. This would then give us what I think we’ve reached consensus on as our "Tattoo Lexicon":

We still need separate entities for these two things. They are not at all alike, are processed in completely different ways, and we need semantics that clearly indicate the differences. Plugins is a bad word for what we have I think though, perhaps adding the word Event would help differentiate these from the more generic Modules, which can have dependent resources, including Snippets, Templates, Content Templates, Event Plugins? I’m not sure, but we really can’t merge these two concepts under the same label IMO...

What if the modules could be tied to events? According to Raymond the only difference is a minor table structure. And besides, Travis already has it working with Adam’s Quick Editor... so maybe it is possible after all

Quote from: rthrash at Aug 22, 2005, 12:55 PM

What if the modules could be tied to events? According to Raymond the only difference is a minor table structure...

...and functionality - lol

Some people use plugins and modules interchangeably so the name is what I think is causing the problem. As Jason suggest we should perhaps change the name. If not then we can consider merging the two but this might lead to an inefficient structure.

Here are some other names to consider replacing plugins with:

* Hooks
* Triggers
* Handles
* Event handler
* Extenders