Future of Chunks

Hi. I’ve been looking at how chunks are stored and used, because I’m looking to add Add/Edit Chunk functionality to the frontend. I have two plans: one is a simple class library that can be used by custom frontend apps, the other is to add a chunks menu to QuickEdit.

Also, from a site-editor point of view, I’m thinking that chunks are the best place for me to place advert and commission link code, because it keeps the HTML and javascript neatly together, making the page content easier to read and edit.

So.. can I clarify the future of chunks?

I can see there’s some history: the db table calls them "htmlsnippets". But I can’t tell what is history and what is intended future feature from the table fields.

The fields ’id’, ’name’, ’description’, ’snippet’ and ’locked’ all work as expected (snippet = chunk content).

But there’s also ’editor_type’, ’category’ and ’cache_type’ which appear not to do anything. (Switching to rich text editor doesn’t get that saved in the editor).

I quite like the idea of category in particular - it would be useful to divide out ’adverts’ from ’standard text’ etc, and also would mean that I could have a routine that randomly picked an advert chunk, and I wouldn’t have to change the routine every time I added another advert chunk. (Although I guess I could already do this with a chunk name search for chunks beginning ’advert_’, but it’s not the point).

So are these fields dead or dormant?

What is the future of chunks?

(On a related note: the trunk version of mutate_htmlsnippet.dynamic.php appears to reference FCKEditor, when of course that plugin isn’t in the trunk.)

Short term (e.g. 0.9.x), I believe those fields are just dormant, and in fact someone is working on using Categories to help organize Chunks, Snippets, Plugins, etc.

Long term (e.g. 1.0/Tattoo), in my vision at least, all of the various components of MODx that return content (everything currently under the Resources menu) become one table/class, called an Element or Content Element. In essence, Chunks will be the simplest form of an Element, and the notion of Templates and Chunks merge to define this basic Element class and it’s behavior. TV’s extend the basic Element a little, providing more advanced behaviors; Snippets, being the simplest form of a PHP script content element, becomes a ScriptElement class, which extends the basic Element class as well. PluginElements and ModuleElements can then extend the ScriptElement class to do what they need to. And from there, defining any kind of content element is as simple as extending the Element class or any of it’s derivatives.

This way, each element can define a related content object that retrieves and processes the appropriate revision of that element’s content, and which can be overridden by the page that is accessing it. Then, based on what site context the request was made in, the default or user preferred culture/language, and which revision is marked as the current revision published to the site, the Element instance returns it’s stored content and processes it as defined by the class of Element it is. In addition, Elements can nest any other Elements, using a technique similar to the current module_guid approach.

Short term: I didn’t see anything when I searched for chunk category or related terms (even tried the Google search). If anyone knows who is using categories, and whether they are using the category field or something else altogether, please let me know.

Long term: sounds fab as ever; it sounds like I’d be able to have an American advert and a British advert as cultural variants of the same chunk.

I guess that any chunk editor I release will be redundant in 1.0 - I assume that future front-end editors packaged with MODx will be able to edit *any* kind of Element, and/or change which revision is the live published one. I really like this idea btw, I guess it would also give us somewhere to ajax-autosave ’draft’ versions as they are being edited. I assume you can only edit the most recent version OR create a new version based on an older version, otherwise it would get unwieldy.

I can see that content elements can be defined. Great, but is this how I distinguish between (and group) content types, even when there is no technical difference?

Imagine I have a site that has a bunch of advert chunks and some other text chunks (like a "thank you" message for form submission). Is there any plan in 1.0 for categorising these elements or am I supposed to define them as distinct element types?

Reasons I would like to group chunks include access control, workflow and comprehendability.

Presently there’s no distinction between being able to edit snippets and being able to edit chunks - I guess this is part of the history. Is the long-term elements plan wrapped up in a better user access system?

Quote from: OpenGeek at Aug 06, 2006, 04:17 PM

TV’s extend the basic Element a little, providing more advanced behaviors

Extend a little? Wow. I was thinking that TVElements would be associated with templates and documents and widgets - thus the method and value returned is defined by many things. Is that little as in the difference "0.0.5" makes?

Whilst on the subject, I’d like to see "global TVs" in addition to "document TVs". There’s a lot of functionality in TVs that isn’t available to a chunk, and is not as easy to do as a snippet: it would be quite nice to have the logo for instance selectable *once* based on a selection of "normal logo", "logo with snow", "flaming logo" etc rather than per-page.

Paul,
I have started working on using the categories table and the actegory fields. In this topic you can see some screen shots of what I have started working on: http://modxcms.com/forums/index.php/topic,6287.msg44290.html#msg44290

So once this is done you could setup your adverts in their own category.

Sounds good, but:

"The topic or board you are looking for appears to be either missing or off limits to you."

I’m not in the inner-inner circle it seems.

Quote from: PaulGregory at Aug 06, 2006, 06:41 PM

...it sounds like I’d be able to have an American advert and a British advert as cultural variants of the same chunk.

Absolutely.

Quote from: PaulGregory at Aug 06, 2006, 06:41 PM

I guess that any chunk editor I release will be redundant in 1.0 - I assume that future front-end editors packaged with MODx will be able to edit *any* kind of Element, and/or change which revision is the live published one. I really like this idea btw, I guess it would also give us somewhere to ajax-autosave ’draft’ versions as they are being edited. I assume you can only edit the most recent version OR create a new version based on an older version, otherwise it would get unwieldy.

Unwieldy indeed. At some point, maybe I can find/write an efficient diff processor in PHP so we could save just the differences, a la SVN, but I think I have enough on the current roadmap to worry about it...
;)

Quote from: PaulGregory at Aug 06, 2006, 06:41 PM

I can see that content elements can be defined. Great, but is this how I distinguish between (and group) content types, even when there is no technical difference?

Imagine I have a site that has a bunch of advert chunks and some other text chunks (like a "thank you" message for form submission). Is there any plan in 1.0 for categorising these elements or am I supposed to define them as distinct element types?

Reasons I would like to group chunks include access control, workflow and comprehendability.

Categorization is multi-faceted moving forward. First, you’ll be able to use categories, with a hierarchy; the current category table is only suitable to model a flat, single level set of categories, but simply add a parent reference and we have the capability to define a tree structure of elements to organize them more granularly. Second, since elements can reference other elements using a `guid` and `parent_guid` column (a unique identifier assigned all Elements, and unrelated to the primary key column, which can also help make the elements, and their relationships more portable from deployment to deployment), they can further be organized in this more direct way. For instance, consider a ScriptElement (i.e. snippet) that defines several child elements to serve as templates to be used and referenced in that ScriptElement’s content, be they of the simple Element class (i.e. Chunk), a more advanced ContentElement (i.e. next-gen TV), or another ScriptElement (i.e. snippet). You would be able to have any kind of related Element listed on a related elements view in the manager or a front-end editing plugin.

Combine these two and you have a pretty powerful set of tools with which to organize and customize your manager and/or front-end interfaces.

Oh, and workflow will also be possible via two additional features. Custom metadata (did I mention the MetaElement class before, oops) can be one of those related element types, and any ScriptElement class (or custom Element classes) can stop the propagation of further processing of related elements in a specified order of execution. In this way you can chain a set of scripts to execute based on decisions made in the one before.


Quote from: PaulGregory at Aug 06, 2006, 06:41 PM

Presently there’s no distinction between being able to edit snippets and being able to edit chunks - I guess this is part of the history. Is the long-term elements plan wrapped up in a better user access system?

Quote from: OpenGeek at Aug 06, 2006, 04:17 PM

TV’s extend the basic Element a little, providing more advanced behaviors

Extend a little? Wow. I was thinking that TVElements would be associated with templates and documents and widgets - thus the method and value returned is defined by many things. Is that little as in the difference "0.0.5" makes?

Whilst on the subject, I’d like to see "global TVs" in addition to "document TVs". There’s a lot of functionality in TVs that isn’t available to a chunk, and is not as easy to do as a snippet: it would be quite nice to have the logo for instance selectable *once* based on a selection of "normal logo", "logo with snow", "flaming logo" etc rather than per-page.

That’s just it, all Elements are global in this design. You can attach any of them to a Resource, which is the name of the class which represents anything accessible via a URI (web page, symbolic link, web service, ajax service, etc.), or to any other Element, of any Element class. And one Element serves as the root or base element for a Resource, i.e. this is your Template, only it can be of any Element class, not just a static HTML template.

Also, all Elements have properties, can define an InputClass, OutputClass (basically class-based versions of widgets, currently only available to TVs) and corresponding Input and Output properties, and you can also define pseudo-Elements, which do not have persistent data storage in the Element table. These are like Elements that are only processed in content as tags (thus, they extend the modTag class), and serve as the base implementation for processing...

• link tags, e.g. [[~49]] or [[~alias:myfancyportfolio]]
• placeholders, [[+myplaceholder]]
• configuration settings, [[++site_url]]
• @bindings, e.g. [[@INHERIT]]
• any thing else you can implement as a tag with an initial token string

Tree structures assume a hierarchical taxonomy; this will be sufficient for basic categorisation but it sounds like the custom metadata will be more flexible (tags).

I think my initial question about chunks is answered - they will become an element with a HTML inputclass and a straight outputclass; still with a single category reference but with associated metadata. And possibly a parent element, although I fail to think of a use for that.

1) If elements are global, I’m not sure I understand how one would distinguish between a single resource that is attached to a template, and a resource (classic TV) which is attached to a document but only if the document has a template that is associated with that TV.

2) It would seem that it is a Bad Idea to give snippets/chunks/plugins/modules the same name in 0.9.x because although they won’t clash now, they will clash when they are the same table in 1.0. Correct?

3) Does that extend to page names, or are documents still treated differently?

Quote from: PaulGregory at Aug 06, 2006, 07:03 PM

Sounds good, but:

"The topic or board you are looking for appears to be either missing or off limits to you."

I’m not in the inner-inner circle it seems.

Paul, here is a link to the screenshots on my test site: http://modxtest.muddydogpaws.com/category_examples.html

Looks great. Can you confirm that this uses the ’category’ field?

Paul, Kyle’s work took advantage of the category field, but there may be a conflict with the modules functionality. We’re trying to figure out whether or not there needs to be a new table or field added I think.