Rethinking Templates vs. Resource Types (aka Content Types)

Jason, do you know of any existing implementations, tutorials or even collection of hints to put that together? It would benefit a lot of people but I couldn’t find any info on it.

Quote from: Mark at Feb 20, 2011, 08:27 AM

Jason, do you know of any existing implementations, tutorials or even collection of hints to put that together? It would benefit a lot of people but I couldn’t find any info on it.

Will be coming in the next few weeks, but it’s essentially the same as it’s always been—you create a Resource (or various ones) with Snippets representing a view into a custom data model, and use a plugin OnPageNotFound to handle routing FURL requests to individual views into that data in whatever way makes the most sense for the model. This is how I’ve always approached client projects in MODX when creating calendars, catalogs, galleries, etc., though rarely in a generic way that lended itself to sharing components; this is about connecting and integrating custom data sources. But then that is also the benefit of a framework like this—the freedom to implement it in a way optimized to the task at hand.

Thanks. And yea, that indeed sounds like something we’ve been doing for a long time already

What I don’t understand yet though (may have been unclear) is to for example make a "blog" resource type/class which shows up in the site tree and, instead of giving you the regular forms when editing, shows you for example a list of all blog posts. Sort of like a CMP included in the edit resource page. And when retrieved through snippets like getResources or Wayfinder, it would still fetch obligatory fields from the resource, like the title, alias etc.

Maybe we’re just thinking of two different things now.

That’s what’s coming as an example very soon Mark.

Sorry - I’m too excited about this being possible.

Hi
My idea on this subject is to attach Property Sets to Resources.
It is, I think, a more intuitive role for the Template to only act as the default rendering option for an objects set of properties.

In fact TV’s are pretty much a redundant feature now that we have the concept of Property Sets.
In my mind you would build Resource Types only using Property Sets. The only default fields would be meta data basically, not even the content field need be mandatory.

So, when creating a new Resource you would choose first to "inherit" from a Property Set, then choose a template which supports the specified Set.
It’s really pretty much how all the other Elements in MODx works these days so it would keep things consistent and clean.

Thnx,
Lars

Well spoken -- that’s more or less the idea I was trying to convey (albeit less eloquently).

Actually, Property Sets are not exactly where this is going. Instead, we will see the introduction of ResourceElements — Elements attached directly to Resources. There will also be a way to define sets of Elements to automatically attach to the Resource. At that point, any localizable fields of content that are currently persisted on each Resource, will become an Element. IOW, all Content will become Element-based. Property’s are much simpler, light-weight constructs that provide further options for constructing reusable Elements.

IMO, the advanced rendering capabilities of Template Variables still make them a very useful, and differentiated construct, and one that allows easy extensibility of both input and output options for Template Variable content.

Liferay CMS has a very intuitive, scalable way to deal with this that i would love to see somehow implemented in MODx. Its the only feature i really miss from another CMS.


STRUCTURE ->  TEMPLATE  ->  WEB CONTENT (RESOURCE)

Structures in Liferay are like Template 'templates' were you define raw abstract data structure using infinitely scalable, jerarchical xml-schema to define content types. Once you have a structure, you can associate a template with a structure meaning you can have multiple different templates using only one structure (think of it like  resource with a predefined group of TVs organized in a jerarchical fashion if you want) They are still a resource, but with extended fields or TVs.  There's an editor in the manager for creating structures on the go with repeatable fields, text, combo-box, boolean and all kind of field types like a TV. That way you're always only extending the 'core' resource type which they call web content instead of creating custom tables to handle content types like galleries, events, etc. They can be all the same as they are only extending the same core 'resource' type. Like subclasses of the Resource class.

If they inherit from the core Resource class, then the mayority of currents snippets can be used against. Let say using getRources to get a gallery list instead of a custom GalleryAlbums snippet.

This can make custom Resources Types easier to share for the community like galleries, events, surveys, polls.
I think this behavior really fits the MODx world. [ed. note: lithiumlab last edited this post 14 years, 10 months ago.]

Forgot to say Tamplates in Liferay only holds presentation code. (the actual html code we currently dump in the template content with placeholders).

Here’s another post from earlier today i think extends my thoughts on this.
Feedback appreciated.

http://modxcms.com/forums/index.php/topic,61738.msg366861.html#msg366861

Pablo.