I have worked with some old-school content management systems as a peon in the past (pre-2000!). I won’t go into it, but my friends, I have used professionally the granddaddy of content management
Xywrite on green monitors and DOS (and I have written some macros in its native format -- hows that for a resume?) Yes, I’m old, but not that old. One of the
first newspapers to go online used xywrite, and I worked there as a peon. I worked with the guys who created the
CMS for a major newspaper chain (as a peon). So I don’t have coding experience with those systems, but I do have end user experience and knowledge of large enterprise use of these old CMSs. And I DON’T LIKE THEM!!! But I do like the direction of modX! At least I think I do. These are my thoughts, tell me if I’m welcome here or I’m not thinking the modX-way and I should go to some other framework!! (Those wikipedia links don’t really cover the real history of those programs which is quite interesting since most people think the "web" is new, but that is another story).
And this is a bit of a ramble and I haven’t had much sleep this week...
This is along the lines of the "smart folder" discussion in part. I’ve been thinking about things like this for a little while. This is the topic that made me want to express my thoughts about CMSs to this group at modX...
For example, if I have a bunch of pages that use a certain template spread around the site, it would be useful to create a "smart" folder that pulls in all of the pages that use that template so that I can see them all together.
This can sort of be done with a snippet in a template now. And fully implementing it wouldn’t be that hard. You won’t get get exactly a list, you still have to open the page.
Create a container called "Smart Folder" and create a snippet that queries the DB with a variable for the template name. Now create a page for each template called exactly the template name, use this doc property to pass the variable to the snippet with your query in it. Then create a page based on the query. Using can use the template to add editing links back into the manger.
I’m really disappointed the @DOCUMENT binding only returns the content of a document. If it returned the processed template -- we’re almost done...as it is, you need to JSON it out through a snippet...
So we have ’Smart Folder’->’Template Name’->returns a snippet in JSON format of all docs using template. Adding a little floating flyout menu that traverses this on-demand wouldn’t be THAT hard. You might/should be able to do it with the wayfinder. But we wouldn’t be in the manger, we’d be outside it.
My thoughts along these lines have been to create a SEPARATE site for content managing, that mirrors the current document structure, but YOU control the layout via templates. It can already be done, but not easily since the API documentation is, umm, sparsely populated and somethings are harder to get at than others (like a fully parsed document). I was just thinking we should try to organize a group of people that want to create a separate content manager that is completely styled and controlled by the YOU the site creator outside of modx interface which can be intimidating to blogger-types -- specifically for the end users content manager that hides modX and makes just what you want to them to see available. The trouble with being outside of the manager for editing is race conditions. I haven’t looked into how this is exposed. I don’t even know how modX is handling it now in the manager. What if someone is editing a document and someone else is editing its template variables and saves changes to the template? Does modX know this and provide warnings?
What really needs to be added to modx is a loosing of the definition of document. We need documents to be natively other format...CSS and JSON, XML and natively output multiple formats based on caller. I know this can be done -- sort of -- but not really. It’s more kludgy than robust. And it can’t be bound, it is snippeted, and you’re in multiple places playing tag soup again.
Here’s why. Then we can have bindings that process the document based on format with error checking. Or request data in different formats (with error checking).
So suppose I can create a JSON document template (or mixed output template). Then I can create a JSON document based on that template, and have that BIND to a template variable in another page. That other page can be a wholly separate content editor, or whatever.
If I can create native CSS docs, I can also BIND them based on user roles, etc. I know this can be done now -- but once again it is kludgy and not robust -- and the kind of thing that can get clobbered in a major update. If we got a CSS group, we could develop a browser-based CSS template that has a uniform implementation of styles w/o the designer having to have ugly code. We could have easy implementations of things like thrashbox inside the manager that CSS-novices could implement with a selector. Yes, this can be done now. The document would just generate CSS and write to an asset file. But for DRY, it be great to get organized with like-minded and get it in a module so we could share. We could also get styles to more tightly integrate with tinyMCE or another editor, so that instantly, automatically, when you change the CSS in a template, it’s editor gets the new styles. And yes, this can be done now also, but with snippets. Yes, this is more of a framework type thing, but is ModX afraid of being frameworky (at least in a module)?
I assume the manager is loosely based on modX public face in the first place, so releasing the manager to be styled and controlled by templates shouldn’t be that hard. And then it would be really cool. A CMS that implements itself recursively based on roles. I’m giddy.
The thing I’m having a hard time getting my head around, is how inheritance should be handled on my end as a site designer. I need to do more experimentation to see what modX does when things are changed and documents now have hanging variables unassigned. More on that later.
Am I off base here? Should I be looking at other CMSs (or frameworks?), or is this sort of the direction modX is going.
For me ModX is *almost* a framework. And I don’t think it should shy away from that! Right now, looking at modX I think someone could create a framework language that sits atop it and never touches its interface! Yet, the end-user could log into to it and see a modX site and start editing content! That is pretty cool. Judging from the russian spam sites that pollute google, I think the russians already have a way of generating modX sites as little AI robots.
I haven’t figure out how to do role-based content within a template. Am I once again suppose to use snippets exclusively? This seems a little restrictive and not really the spirit of templating. I’m trying to figure out what is the principal object of modX. If the template is the object from which all is inherited, but at times is mostly seems like the document is the object, and the template more of an attribute of the document. At other times it seems the template is master (and a dynamic site would be). But when the document seems to be the master this gets very hard to deal with when you get into huge datasets -- you don’t want or need each piece of your data as a document, you end up with duplications and overhead you don’t need. But once again, I can’t get my data bound/processed through a template easily. And this is where the conflict between a strict CMS and a framework seems most exposed. In a strict CMS, the document content would be king. In a framework, the data structure is king and created on the fly (which is why people love frameworks). ModX seems so close to being the best of both worlds -- with very frustrating exceptions. I think that data structure changes are destructive to document content in ModX, and this needs to be fixed soon.
Is modX right for me and my desires, or should I be looking elsewhere?
If these thoughts have anything in common with the core ModXers I have other thoughts about the frameworkiness of ModX and how it would solve so many problems I see asked in the forums about converting large datasets (jobs, real estate, products, etc). Perhaps we could set up some guidelines for uniform implementation that *won’t* get clobbered by updates. And perhaps make a framework module that puts data sets first, and lives in the ModX document world.
Yes, this was a big long ramble. Thank you for your time. I just wanted to suggest how almost all the elements are here for much, much bigger things if the manager is opened up in the same way as the content and the document definition is loosened and the template made king (data set format) -- making ModX the best of both worlds. I have many more thoughts on each and everything I glossed over, but my thinking may be way off the ModX path, so I’ll wait and see the responses.
