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

Tech Preview is just that... a Tech Preview. When the last one is released, it switches gear to Tattoo 1.0 ... or heck at this point 1.5 is more in order because it certainly will be farther down the road than we ever initially inteded for a first release!

lolo, I was referring to TV ... keystroke miss

In that case, TVs are a dying term. That I can guarantee.

I think I need to clarify my understanding of Modx.

Currently Modx does not have a "Component" like extention that will have its own interface to allow user to interact with. Is that correct?

In Mambo the admin interface provide a standard set of icons for the Components, Template,,Modules, Mambot to use such as: published, unpublished, delete, and whereever appropriate, new, edit, save, copy or clone, assign, default, edit html, edit css..

Since Components have its own interface then Mambo only provide the minimu icons such publish, unpublish and delete whereas for Modules, Mambot, Templates do not have its own interface then Mambo provide the standard set of interface icons to manupulate those objects.

So my question is do we want to create such thing like "Components" in Mambo where the developer is freed to extend and be creative to create their own interface to interact with their components?

What is your thoughs on this?

Thanks

There IS an inteface to interact with everything already in place for MODx.

For now, that includes Snippets (Mambots?), Plugins (Modules?), and Modules (Components?). The difference is that there’s no hard and fast restrictions on where Modules can run, so it can be front or back end.

Is that helpful?

Yes, but I am refering to something that is not current in place via Modx and the developer want to create something that only unique to their application (modules/components).

How would they go about doing it in Modx?
Is that possible?

Thanks

Modules are our form of packages for a custom web application, made up of various MODx resources -> snippets, chunks, plugins, TV’s, templates. Think of these resources as building blocks for creating web applications, and by combining them and using them in document content, TV’s, etc. as needed, you can create a robust web application, page by page. If you package them as a module, you have the added benefit of being able to run it from the frontend or backend, shared configurations amongst the module’s dependent resources, etc. So you can create complete web applications (modules) or simple stand-alone components (snippets, plugins, TV’s, chunks) very easily in MODx.

The thing I never liked about Mambo (or *Nuke) is that the module rendering was typically restricted to what the developer created for an interface (or a default). In MODx, you take a more modular approach to this. And because of this, the possibilities are endless in creating anything from a simple page block in a sidebar, to a robust web application with multiple views and complete with an admin UI available in the content manager.

Jason,

Is there such a thing like that now that I could take a look?
Is QuickEdit a good sample for this discussion?

Thanks

Quote from: chanh at Aug 25, 2005, 12:46 PM

Is there such a thing like that now that I could take a look?
Is QuickEdit a good sample for this discussion?

QuickEdit is a good example, and the only Module shipped by default in TP3.2.

I’m also working on a makeform module that uses individual form element templates and an array definition to dynamically build and process a form against any MySQL database table, but am building this in conjunction with a client project. I may release an early version of this in the next week or so for another example.

Here is another excellent example of a module. Unlike QuickEdit which is tied closely to the core API, this one seems to run much more independently.

http://modxcms.com/forums/index.php/topic,768.msg4562.html#msg4562