Frameworks over MODX

I know MODX is already a CMS and maybe a framework itself but sometimes I feel the need to have a framework over it, if I can say that, or at least some rules to follow so I will not end up with a hundred of snippets and chunks and plugins and a bunch of extras. Maybe to much freedom is not good in all the cases?!

I have failed in creating something like this but maybe someone else is already doing that successfully and maybe he or she is willing to share that

I will describe my failure and maybe one of the more experienced modx users will be able to advice or maybe will be inspired.

My initial ideea was to use the core modx and to try to avoid the use of custom tables for creating things that could easily be mapped on modDocument. So, in my view, for each type of object I can define in a web application I would create a template and a set of templates variables that describe the object.
So if I would have to create an e-commerce site that will present products grouped on various categories, as an example, I would create:
template tplProductCategory with template variables: pcId, pcLabel
and
template tplProduct with template variables: pId, pcId, pName, pPrice, pImage, pDescription.

These would be my "classes".

I would create in web context a resource folder named category where "instances" of tplProductCategory would be stored, these being documents having their template property set to tplProductCategory.

"Instances" of products could be stored in a folder resource called products in the root of web context or under the category instances from which they are part (considering that a product can't be in two categories) and of course producta re documents with their template property set to tplProduct.

I guess this might be some what a nice and easy model, I think I am failing when I try to do a search on such a thing
If your site will need a search on these products with some filters based on the products properties I found it pretty difficult to implement .... or maybe I am not aware of the powers of xPDO.

Anyway, I am wondering if any of you have already "ways" or "rules" of doing things, or why not a "conceptual framework" in MODX rather than just doing things differently for every other project, it would be hear about that.

Thank you.

Interesting idea. The problem with your approach, IMO, is that resources carry a great deal of overhead that you don't really need.

With resources, MODX does a lot of processing to check for TVs, Form Customization Rules, published status, publish and unpublish dates, friendly aliases, hide from menu, editing date, etc. That makes custom DB tables *much* more fast and efficient by comparison.

You can use a very small number of resources and Tpl chunks to *display* the results but store the data itself in the custom tables and avoid all the extra overhead. This also provides better separation of content and presentation and makes maintenance much simpler.

It looks like the concept you are working on is, in effect, to extend the resource object. I think you would be much better off to extend xPDOObject or xPDOSimpleObject, which are very lightweight and efficient and don't carry all the baggage that's attached to Resources.

Using custom DB tables will also make custom searching, selecting, and sorting infinitely faster and easier than trying to do it with resources, Involving TVs in the process is particularly inefficient from a database design standpoint and makes for much more complex code -- TV's are stored in a separate table and using them for database access the way you suggest involves the resource object, all the separate TV objects for the page, a separate table containing the TV values for each page, and often the template object as well.

Using custom DB tables and the xPDO object(s) also lets you use all the tremendously handy xPDO methods to access your data and automatically gives you the very efficient caching mechanisms built into xPDO. This would, IMO, actually lead to *fewer* snippets, plugins, and chunks than trying to use TVs to store data.

Just my $.02.
[ed. note: BobRay last edited this post 14 years, 11 months ago.]

Thanks Bob. Yes I felt that while trying to do that model and yes actually I always turned back to xPDO, which I actually love by the way.
I also extended modResource and succeed to add its kilds to document tree (because I actually needed the alias feature and the 1-1 relation custom object - url / "unique page" )... but still not the best approach.

Maybe what I am looking for is an extras that will let me some how visually design object types extending xPDOSimpleObject in a similar way MODX is doing with its templates + TV's, where template like object would become the new schema object ( ~ sometimes table ) and TV's like objects would become table fields. Plus a relations manager to add the aggregates / composites dependencies. Basically a nice visual tool for editing custom xPDO schema, inspired by the template / TV's current defining process, embed in MODX manager

Is this a worthy idea? Maybe it is already done?

A visual design tool would be fantastic, especially if it let you specify the relationships between the various objects and then wrote out a correct xPDO schema to a single file for the whole relational custom section of the DB.

xPDO already has writeSchema(), which will create a schema from an existing DB table and parseSchema(), which will create class and map files from a schema, but (AFAIK) there's no way to auto-generate a schema that involves relationships between objects and deals with aggregate and composite aliases, foreign keys, etc.

I think writing out the schema would be fairly easy, but as with most such projects, the UI would be a bear.

So, Bob Ray (and other experienced developers around), I guess you are not only theorizing the MODX ways, you probable made many implementations. Please, share some good habits with us, would you

How should one start thinking trough MODX above the designer or lazy developer level?

How do you organize things? Do you create packages for everything so you can reuse it and transport it easily?
For administration purposes you let users use manager (context mgr) and CMPs or create a different context or just another view in web context?

Sometimes end users are so NOT technique and MODX manager look scares them.

I would be interested to find out about some real life solutions and about how others use MODX as developers.


Thanks.

I do create packages whenever I can.

I've experimented with CMPs, but haven't had time to do much with them.

As far as users are concerned, the Revolution Manager is highly customizable and you can hide just about any part of it from users who might be scared.