Hiding Resources from Tree / Creating a New Interface for them

Hi all,

Quick question - I don’t think it makes a lot of sense to incorporate News Items (for example) in the resource tree - it would quickly grow unweildy. Although clearly they are Resources, and that model is appropriate, is there a way to hide them from the Resource Tree and create an interface, probably based on a grid to manage them elsewhere within the system?

Has this been done before? What approach would you recommend?

Cheers,

DM

I have to say this is a great idea, as you said the document tree really does get unwieldy quickly when used for many items. You could actually build a pretty nice blog or a simple shop with something like this.

Good luck finding an answer to this.

This is definitely the intention of allowing extensible modResource classes, but it may take a little collaboration and work to find the best ways to accomplish all of this. A agree 100% BTW, that blog/news type posts do not belong in the tree as individual Resources.

I’ll have a more thorough response to this soon.

In Evo I use to transfer the tree to a module that creates a grid for each big "category" for the client. So you will have a tab for each section and then in the tab you will have a small table for each subsection. In each entry I would show the icons for the client to click at to edit, delete, publish, create , etc. Very clear to understand and easy for the client to use.

I am ust beginnning in Revo so I still dont know how I will do this in Revo, as there are no modules any more...

Quote from: charliez at Aug 02, 2010, 07:19 PM

I am ust beginnning in Revo so I still dont know how I will do this in Revo, as there are no modules any more...

Modules became Custom Manager Pages in Revo; see http://svn.modxcms.com/docs/display/revolution20/Custom+Manager+Pages. Similar in concept, and IMO clearer that it is not a module that applies to front-end and back-end like in many other content management systems.

Thanks Jason, I’ll check’em CMPs...

This is definitely the intention of allowing extensible modResource classes

agree 100% BTW, that blog/news type posts do not belong in the tree as individual Resources.

Aren’t the two quotes colliding? Or did I get this wrong?
If you extend a modResource it will still be in the tree, no?

And if you build your own schema (revo as cmF), you gain performance and extendability (own xpdo schema vs TVs), but you loose much of the "cmS" : add-ons (quip,getResources,etc..), page caching, furl, access permissions and various other built-in features that make this CMF into a CMS.
sure - you can get all the above and more quite easily with the api, but it always means your own custom components.

Could you elaborate on that?
in a blog with ten-thousand resources, context cache will get quite big, what else? (front-end performance only, /manager is not important)
Have you any revo installation with huge amount of resources? can you point us to the bottle-necks.

side-note: as far as i see in today’s web apps - caching is the main key to performance (in terms of page load time).

thanks

Quote from: oori at Aug 03, 2010, 09:04 PM

This is definitely the intention of allowing extensible modResource classes

agree 100% BTW, that blog/news type posts do not belong in the tree as individual Resources.

Aren’t the two quotes colliding? Or did I get this wrong?
If you extend a modResource it will still be in the tree, no?

Consider a custom Resource of class joedirtsBlogResource; a single Resource would appear in the tree, but the implementation could then delegate each blog post into a custom table that is visualized and managed in some custom way outside of the tree.

Quote from: oori at Aug 03, 2010, 09:04 PM

And if you build your own schema (revo as cmF), you gain performance and extendability (own xpdo schema vs TVs), but you loose much of the "cmS" : add-ons (quip,getResources,etc..), page caching, furl, access permissions and various other built-in features that make this CMF into a CMS.
sure - you can get all the above and more quite easily with the api, but it always means your own custom components.

Could you elaborate on that?

Components become standards based on how generic they are (i.e. how many common problems they solve) and adoption. getResources is great at what it does, but that doesn’t mean it is the best way to do everything in the site. Especially when we start talking about performance. The idea is that a set of Extras that comprise a totally scalable blogging platform that’s as easy to use within a MODx site as say WordPress is, yet still have all the freedom and extensibility of MODx at your fingertips. And the same might go for other specific solutions. I just simply do not believe their is a generic solution to every web problem, though I do agree, when requirements are right, using the standard set of tools is the most practical approach.

Quote from: oori at Aug 03, 2010, 09:04 PM

in a blog with ten-thousand resources, context cache will get quite big, what else? (front-end performance only, /manager is not important)
Have you any revo installation with huge amount of resources? can you point us to the bottle-necks.

side-note: as far as i see in today’s web apps - caching is the main key to performance (in terms of page load time).

The context-cache is really the only bottleneck at this point, and this will be solved very soon using some new storage techniques for representing hierarchies. You can turn the context cache off, but at the moment, the makeUrl() functionality has to basically build the entire context cache in memory to use it on each page load where a link appears and is not cacheable.

And no, I don’t build them with a large number of Resources at the moment; when we have records in the 1000’s when generally delegate. But, again, this will change soon and there will be no limitation on the number of Resources you can have per Context.

Thanks for your detailed reply.

Consider a custom Resource of class joedirtsBlogResource; a single Resource would appear in the tree, but the implementation could then delegate each blog post into a custom table that is visualized and managed in some custom way outside of the tree.

That’s (almost) the same as having a regular single modResource with a single snippet in it which is the front of the custom blog items. the blog items will still not be a modResource with all its features (furl,quip,etc...)
As you mentioned the only draw-back is the context.cache (which will be resolved one day..), seems to me it is still preferable to have the blog items as modResource (or a class extending modResource), as the generic approach has more to gain then to loose.

The context-cache is really the only bottleneck at this point, and this will be solved very soon using some new storage techniques for representing hierarchies.

That’s great.
In my case, i use a custom front-end for all operations, so I delete the context.cache only on post add and delete (not on edit, as alias don’t change).
I can separate containers across multiple context, to ’help’ the context.cache issue, but I would prefer not, as i have no other reason to split context besides the context.cache..
a. you recommended to split contexts in case of large resource volume?
b. off the record - we’re talking more or less 2 month or 2 years time for the new storage technique you mentioned?
c. is a large context.cache a bottleneck when it’s created only, or also when accessed?

You can turn the context cache off, but at the moment, the makeUrl() functionality has to basically build the entire context cache in memory to use it on each page load where a link appears and is not cacheable.

Seems way slower then using the context.cache... especially in a large setup.

Consider a custom Resource of class joedirtsBlogResource; a single Resource would appear in the tree, but the implementation could then delegate each blog post into a custom table that is visualized and managed in some custom way outside of the tree.

I’m digging further in to this.
You offer this:
parent object: joedirtsBlogResource (extends modResource)
child object: joedirtsBlogItem (composite of joedirtsBlogResource)
grandchilds: comments,embeds,etc.. (composite of joedirtsBlogItem)

Only the aggregation pages will actually be in the tree, and all the "blog items" will be in the custom table.
right?
Now let’s forget about using existing add-ons and the manager, and it’s all custom.
One thing I don’t get - everything except FURL is cool, but to archive FURL, I would have to manage my own kind of context.cache. so I’m back in the same starting point, as I would also need to manage a context cache. so my option is simply to do it "better" (thiner / hierarchical context cache) - which is what you’re talking about doing as part of modx anyway.
no?


btw, working on extended objects and custom view cache these days, I keep getting amazed at how smart xpdo was built. really!