Rethinking Templates vs. Resource Types (aka Content Types)

Here’s something that’s been on my mind... when you create a "Resource", it would make sense for you to be able to be able to specify that you want to create a "Book", or a "Product" or a "Bio" as the type of resource you were creating. For example, WordPress has "Posts" and "Pages", Drupal has "Stories" and "Pages" or some such. It makes sense: each type of Resource infers a certain set of attributes (a book might have a "plot summary" or "author", whereas a "Product" resource might have attributes for "height" and "shipping weight"). The attributes are by necessity closely tied to the templates used to display them: if your "Product" pages have 20 different attributes, then your template for that page must have 20 different placeholders that determines where that data is displayed.

It gets a bit blurry in there, but I think it would make sense for you to be able to define custom resource types (such as "Product" or "Book" etc.), and THEN define available templates for those resource types. You know? That just fits easier in my brain. I don’t think "Hey, I need to create an abstract resource here to which I will associate a pre-defined set of attributes." That’s more or less what MODx makes me do, but no, I think, "I need to create a "Book" page here and a "Product" page there. You know what I mean? After you define a type of resource, THEN you could create templates that matched those particular resource types. (I’m using the term "resource types" in a way that analogous to WordPress’ "post-types" - it’s just a way to refer to types of content that has unique sets of attributes).

WordPress essentially does the first part of this: you can define a custom "post-type" and choose some of the attributes available to it... after that WP kinda epically fails in terms of sensible architecture and sane templating possibilities, but at least to the manager end-user, it’s easy to understand. In MODx, I imagine if you right-click the page tree, instead of seeing "Create Resource Here", you’d instead see "Create Book Here" etc.

I think if this idea were integrated into the manager, it’d make for a more sensible user experience. It would also help clear up the confusion of template variables. I understand where that name comes from, but to be honest, I’ve never liked it and it’s difficult to explain to clients and newbies. I prefer the term "Custom Fields"... seems to be understood more readily. I know the architecture will support the idea I’m outlining here, so I’m making the following suggestion in manager work-flow:

1. Define a Resource Type (e.g. "movie" or "product")
2. Define custom fields for that resource type (e.g. "plot summary" or "shipping weight")
3. Define one or more templates that are viable for representing instances of that resource type. It’d be awesome if the MODx manager could even create a sample starter template for the newly created resource type -- simply print out a simply HTML head and body with the placeholders used, and then designers could easily adapt that.

One immediate advantage to funneling the process in this way would be that you could only select valid templates for any particular resource. That warning that pops up whenever you change a template is bewildering for newbies. Even *cough* experienced users (who ostensibly know better) *cough* may inadvertently blow away their TV data when they select a template that does not support the same kind or number of TVs.

Does that make sense? The more I think about it, the better I like this idea, and I was wondering if I’m alone on this island or if other people had similar ideas... anyone have thoughts about this? Is this perhaps already in the works for future versions of Revo?

I think it should be able to add custom class_keys already by extending modResource.

That said, that’s as far as my knowledge for the subject goes, lol. I came across this this afternoon: https://github.com/splittingred/modBlog/ but unfortunately there’s nothing really interesting in there... yet. It does confirm (in the schema) that you need to extend modResource though.

Just found this quote from Shaun:
"In the future, when we add full support for custom Resource types, this will be even more useful." http://modxcms.com/forums/index.php/topic,55323.msg318332.html#msg318332
So I’m not entirely sure if this is already possible. The others posts in that topic don’t shed more light on that either.




Actually, I just did a random test. You can add new classes in the class_map table, and that shows up in the list then... Don’t hit save though - your resource will disappear. What actually happened now is that I added the class "versionx" with parent class "modresource", and the resource disappeared from the tree menu and gave me a "resource not found" error. Funny thing is, I open up the VersionX page and what’s in there...? (a heavily distorted/data missing resource, lol)




The idea of limiting templates to classes in a similar fashion that you can limit template variables to templates actually sounds like a very good suggestion to me. Perhaps with the four basic classes (document, weblink, symlink and static resource) it may not be needed quite as desperate as a modBlog class, but you could limit your static resources to only a blank template for example. I wonder if a plugin could pull that off - it would have to overwrite the template select box somehow...


We’re getting this in 3.0 (wonder what that’ll be called..) though.. can’t wait!

If I understanding you, you’re saying that TVs should be attached to resources, not templates. I think that’s a much more intuitive structure. The trick is how to get from here to there and how to do it without breaking every site that has TVs (and I agree that it’s a bad name for them, though it does remind people what they’re connected to.).

Knowing OpenGeek, down the road we may see a structure where anything can be attached to anything.

I have contemplated a Wizard that would help you create custom objects that would go in their own DB table (e..g, blog posts). You’d fill in the field names and types in a form, the Wizard would create the schema, run parseSchema(), and maybe, as you say, create a few sample Tpl chunks to create, edit, and display the objects.

I suspect that the WordPress wizard is cheating by only allowing blog post fields and just hiding the ones that you don’t select, but I haven’t looked at the code.

I’m currently hooked up in a wordpress project and honestly, customizing the admin is easier compared to MODx Revolution.
Not elegant but easier.

Wordpress does not use a wizard for the custom post-type, it’s up to the developper to declare them using the available hooks (as a plugin usable in every theme, or as a theme specific function but only available for the theme who declare it) in php.
It’s hiding the fields that you don’t need.
But Wordpress allow "metaboxes" that are custom fields tied to the post/page (not the theme)

http://thinkvitamin.com/code/create-your-first-wordpress-custom-post-type/

While keeping template variables, i second your comments concerning fields available site wide.
It would be a tremendous addition to MODx to have custom fields that work exactly like template variables but not tied to template but to Resource Type (Using the same tag as tv as well).

Good replies here. Let’s keep this going!

@Bob:

TVs should be attached to resources, not templates

-- yes, but more specifically to a class of Resources. I was calling them "Resource Types", but the idea is that you’d have a class of resources for "Book" or "Movie" or whatever, and each book or movie would have a defined group of fields. From the few beers I’ve with Jason, I understand that where MODx is heading is at least similar to this where ALL fields will essentially be TVs instead of having the default built-in set. However, I’m not sure if this meant we’d have definite "resource classes" where one class would have one set of fields and another class would have different fields.

@Mark: I think this may go beyond what Shaun was talking about here: http://modxcms.com/forums/index.php/topic,55323.msg318332.html#msg318332 -- but it’s hard to say with some of the sparse comments. It’s interesting there was no mention of this idea in the roadmap...

@lossendae: yes, I’ve just finished a book on WordPress plugins, and I have to agree that the WordPress manager is easier for the end-users, but oh my god... the API and the architecture is positively insane. This is the MODx forums, so I feel safe saying this, but who-ever architected the WordPress register_post_type() function needs to be hog-tied... it’s nightmarish. I’m working on a plugin (http://wordpress.org/extend/plugins/custom-content-type-manager/) that more or less gets WordPress about where MODx Evo was in terms of custom fields (i.e. TVs), but the average WP developer has to do some onerous coding using poorly architected functions in order to pull off "custom post types". I agree with you that the end result is cleaner in the manager (the WP templating leaves Drupal in the dust), but it doesn’t hold a candle to MODx). The way that WordPress and MODx handle the custom fields is about the same: there’s a separate table that contains a row containing the data for each custom field. In WordPress, custom field data is stored in the wp_meta table, whereas in MODx it’s stored in the modx_site_tmplvar_templates and modx_site_tmplvar_contentvalues -- the database pattern is similar (extended data is stored in rows, not in columns), although MODx achieves greater usability by using 2 tables instead of 1. That’s why MODx has a standardized set of custom fields for any given template whereas in WordPress, one post might have no custom fields whereas the next post might have 20 -- WordPress is extremely squirrelly in this regard (that’s part of the reason I wrote the above mentioned plugin).

I think Expression Engine actually does extend the database columns, which has the desired effect of creating "classes" of Resources with dedicated attributes for each (although it makes for some super-wide tables with ridiculous numbers of columns and a larger database footprint).

So instead of associating TVs with a template, I think they should be associated with a "Resource Type" or a "Resource Class" (whatever you want to call it). Templates should also be associated with a particular resource type (or class). That’s one more layer of abstraction that would solve the problems inherent here. WordPress fails because it has no built-in way of standardizing custom fields for a particular "post type". MODx "fails" because it standardizes the fields in the wrong place -- it sort of standardizes them in the the view layer instead of in the model layer (I hope the MVC purists will excuse me). The MODx solution is way more flexible, but it’s still not quite right in my opinion.

@Everett

You can define custom fields in Wordpress using post_meta registred for a post/page type in the functions definition file. I have a few custom fields that only shows for portfolio specific post-type in Wordpress and that’s pretty powerful.
However, i totally agree, the architecture is messy as hell. The hooks are handy allowing fast development but if I have to take the work of someone else, it can rapidly be a real nightmare.

I miss MODx so much that i always keep saying in my head "That’s powerful and handy, but it would be so much simpler to achieve that the MODx way - It’s a shame that such facilities are not there by default with a clear API".
It’s not like i can’t do it myself, but i would rather like a native almost universal way of doing it.

Let’s take an example where TV associated with Custom Resource Type can be handy: a blog.
I have a couple of unreleased template that have a few TVs like tags, categories, layout etc...
If i could link TVs to Resource Class, i would be able to have TVs linked to the specific template like layout, menu options, etc... and TVs linked to the Custom Resource Class like tags, categorys, post thumbnails, etc...

Plus it would allow for custom admin UI as well, allowing MODx to show hierarchical Resources in the tree when needed, and a grid listing when needed.

It’s possible to achieve similar behaviour now but it requier a lot of additional code to associate manually template to existing TVs on install, and it’s not rock solid if the users has decided to call the tags TV with another name of his choice. Huge drawback IMO.

If those two points comes to MODx, it would be a tremendous addition to the framework.

Even if MODx is all about flexibility, it would be good if it could also target a broader audience, like the site wide theme available on Themeforest. I for example, would submit templates to themeforest if i had the certitude that the setup could be easier for the final customer who might not be a developper, nor a designer.

To summarize, what i miss now in MODx are the following points:
- Custom Resources Class
- TV associated to Resources classes
- Custom Admin UI for Custom Resources Classes if necessary

Correct me if i’m wrong, but the first point is already possible but undocumented, the second point requier a little bit of engineering to do it right, and the last point only require a few additional lines in ExtJS resources tree (The action link is managed within the Custom resource class).

All of what you described here lossendae is intended to be implemented in MODX by extending the core. This is the idea behind Core Extensions within our Extras section, and a blog/news Custom Resource Type will go a long way to exemplify this. Though I have to say, the benefits of using Custom Resource classes is that you can define custom database tables to store, index and retrieve the Resource data in a way optimized for the task, rather than from the core Resource and Template Variable tables which are optimized for structuring the presentation layer of a web site, not transactional content that is published frequently and/or in large quantities (such as news items, blog posts, or other dated content) and organized by custom criteria.

Interesting!

So what you recommend is to store not transactional content in an additional table and implement our own solutions for Resource class custom fields ?

@lossendae:

You can define custom fields in Wordpress using post_meta registred for a post/page type

Yes, I know. Check out that plugin I wrote -- I covered all that in the book I wrote. WP’s implementation is very poor, however -- e.g. you don’t have to have unique keys in the post_meta which causes severe architectural headaches. Imagine the chaos in MODx if you had 10 identical TVs for one template.

@OpenGeek:

IMO, dedicated tables for each class of resources is a good idea both for reporting, importing 3rd party data, and for database performance. I understand how we might create a plugin to extend the core, but how do you recommend we handle the URL mapping for these? Via a URL segment? e.g. a request for www.mysite.com/movies/xyz would ultimately fetch a row from the "movies" table? In a way, the question becomes "how do I add URL handling to a custom table?" Drupal does it via their "node" table, which basically maps a URL to a foreign table, but the relations are convoluted as @$%# and basically unusable for importing/exporting data.

Wouldn’t TV associated to Resources classes instead of Template be better as part of the core ?