ponderings on frameworks..

Just been thinking about my current implementation of content structure in modx...
I had to design a simple special offer box, and pull it into modx to be changeable for editors.
So, the usual:



spec-templ has the design, special-offers snippet does the processing.
Then I created a folder and sub-pages representing individual special offers.
All good and well, all working fine. However, my content data is haphazardly sitting within each page in modx - prices are in content box, old price is in a tv including most other fields, however its all jumbled & mixed up when viewed in modx.

So that made me think... wouldnt it be better to have different resource types aside from pages? Like customizeable data structures, which could consist of one field or multiple fields. Considering everything is based on "pages" per se, you are ultimately stuck with pagetitle, content, h1 + any other TVs you wish to add to this structure.

I think this might add a lot to the idea of a "framework" where you can custom build and mashup content data structures within modx.

Thoughts?

This might be relevant (though I've never used one): http://rtfm.modx.com/display/revolution20/Custom+Resource+Classes


------------------------------------------------------------------------------------------
PLEASE, PLEASE specify the version of MODX you are using.
MODX info for everyone: http://bobsguides.com/modx.html

Perhaps a MIGx multi-field TV to hold the values for a special would serve the purpose? It could even have date fields for when the item goes on and off special. Then getResources and some output filters in the tpl would do the job of displaying the specials.

Yeah, Custom Resource Classes accomplish that very thing -- that's what powers the Articles plugin, for example. There's not much documentation on it yet though....

There are many ways to accomplish a framework type setting. In fact, I've got one and am releasing it soon.

Form Customization allows you to utilize a normal resource but change the presentation of its editing so that any given field or tab is visible or invisible, set to a default, modifiable or strict, etc. You may also add fields and tabs, as well. Most often, these forms are set to appear on a resource of a given template. This requires no additional code expertise.

Custom Resource Classes allows you to add fields and behaviors and designations as a separate ModX recognizable class. This requires developing a connector (in PHP) at the least and modifying the database (normally with a custom table).

Plugins may be used to set fields, etc when you create, save or delete a Resource. This can give you the benefit of binding necessary data objects together without having to use a connector.or a custom table. This requires PHP, familiarity with the ModX objects, and ModX Events.

Ultimately, you have to remember that each field in ModX may be used in a variety of ways (I use a CSS Selector as a Page Title for one framework). And some fields are utterly unavoidable, even if you do not render them. (i.e. What resource is not going to have a Page Title?)

you can use, as Susan suggested, MIGX for simple tasks like that.
For more advanced ones, where you need it searchable and joinable, you can use joined custom-tables and manage the connected items by a MIGXdb - TV or standalone by a MIGXdb-CMP