Article vs Quip / Custom Resource Class vs DB Table

I have read the manual about what a Custom Resource Class (CSC) is and its usage at
http://rtfm.modx.com/revolution/2.x/developing-in-modx/advanced-development/custom-resource-classes.

I have also read the tutorial for Articles and install the package.

But I am still having a hard time understanding WHY something should be a CSC and when Not?

An Article is a CSC, but a Comment is not? Why?

Both are hidden from the user in the resource tree. For good reason there could by 100s
Both have a special page or section to modify, edit, etc.

What am I missing about this relationship?

If I just wanted to list all the comments on a page, I would assume that I could write a snippet to get the comments that I wanted and display them.

It may be that both "could work" but I am just looking for a good explanation on this. Are there other articles or discussions on this?

An Article is a CSC, but a Comment is not? Why?

An Article is nothing else as a resource, with some new methods and manager-views.
Articles are stored in the modx_site_content - table.

Quip-comments are stored in its own custom-table and have nothing todo with resources, only the relation, connected with the resource-id.
Of course in theorie, comments could also be child-resources and an extended resource-class.

But I think this wouldn't be a good idea and would overcomplicate things.
And it would produce many, many resources and may slow down some processes at some point.

quip has packaged snippets to list comments on the frontend.
But you could use something like rowboat or migxLoopCollection or bloX or your custom-snippet to list them on a page in the frontend.






[ed. note: Bruno17 last edited this post 12 years, 10 months ago.]

Thanks for the response.

But I still don't understand WHY?
WHY is articles a resource that is hidden from menus and from the tree?
I understand that there could be a lot, so that is one reason they are hidden.
But Why create a new resource class and store this in the content table?

As I look to create my own package, I want to understand the pros/cons for this approach, so I can make the best decision.

Any details to help me understand this, would be appreciated.

well, I can't speek for the developer of both, Articles and Quip, Shaun McCormick here, he could tell more about the WHY,
but I think, the biggest pro is: its possible to reuse all features, which are developed for resources,
like the template-system, the plugin-system, template-variables, the permission-system, the caching, many snippets for listing,tagging,commenting and much more.

The biggest con IMO is, they are stored into the site-content-table, which IMO are meant to be pages and containers for different views of things (like listings, detail-views, forms, maybe for Category-Containers and stuff like that) but not for storing masses of records for stuff like blog-articles, products, events and everything.
Its nothing wrong by doing so, and it is working very well, and is very flexible and extentable and easier to put together for non-coders, but sometimes it doesn't feel right for me.
I'm sure Jason Coward could tell much more about that.

I think, which way to go for your package(s) depends on which features you want to reuse, which are developed for resources and which features you plan to develope by yourself (btw.: there are allready many which can handle custom-tables, like rowboat for simple listings, MIGXdb for creating CMPs and do listings, bloX for building very customized frontend-stuff, formit2db for posting into custom-tables from frontend...), and how your db-schema is designed for your package. [ed. note: Bruno17 last edited this post 12 years, 10 months ago.]

Thanks, this is helping and I may be starting to understand, but I have some questions...

Quote from: Bruno17 at Dec 02, 2013, 09:03 AM

I think, the biggest pro is: its possible to reuse all features, which are developed for resources,
like the template-system, the plugin-system, template-variables, the permission-system, the caching, many snippets for listing,tagging,commenting and much more.

Does this mean I might have to add custom code for permissions or caching?

Lets do a simple comparison to help me understand this....

Sticking with the blog package, we have
option A - using a CRC. Having a Article container, with all the articles stored as CRC in site-content-table.
Option B - using a normal resource page, probably some fancier snippets and templates to pull the articles from a custom set of tables.

so, does this mean security and permissions on who can see or edit the articles, might require more custom code in the CMPs if they are custom table, compared to just using standard resource permissions? Could this be the same for other areas?


Quote from: Bruno17 at Dec 02, 2013, 09:03 AM

The biggest con IMO is, they are stored into the site-content-table, which IMO are meant to be pages and containers for different views of things (like listings, detail-views, forms, maybe for Category-Containers and stuff like that)

This is what I was thinking, but maybe there are some benefits that I don't understand yet...

Quote from: Bruno17 at Dec 02, 2013, 09:03 AM

I think, which way to go for your package(s) depends on which features you want to reuse, which are developed for resources and which features you plan to develope by yourself (btw.: there are allready many which can handle custom-tables, like rowboat for simple listings, MIGXdb for creating CMPs and do listings, bloX for building very customized frontend-stuff, formit2db for posting into custom-tables from frontend...), and how your db-schema is designed for your package.

The good news is I will get to design the db-tables as needed, which is why I have so many questions. If I use some CRCs then I would define the containers and supporting tables one way, but if I do this all with custom tables, then I might do this a little differently.

I will look at some of those programs you mentioned and see if the can help and speed up the development.

Thanks for helping to clarify some things.