Rethinking MODx

Fair enough. I guess I am getting ahead of myself again. I said earlier that I was going to build a stronger foundation before I went too crazy making all sorts of suggestions...Back to my lair I go.

ATB,

Jay

David it would mean more than a "mean a slightly different database structure" ... more like a complete and proper overhaul.

I’d argue that TVs/Content Fields should not be bound to templates at all, but to a "meta template" called something like a "Page Type" or "Content Type". This would allow you to have multiple TVs/Metadata/Templates/Chunks/Snippets/Templates/etc loosely bound together so that when you want a new Doc, you would click the magic "New Shopping Cart Page" button or "New Exec Bio Page"... TVs should by default be accessible to all Resources, unless specifically restricted ... not the other way around.

Quote from: rthrash at Nov 07, 2006, 08:20 AM

David it would mean more than a "mean a slightly different database structure" ... more like a complete and proper overhaul.

Yeah well I didn’t want to scare people about upgrades
Thus the understatement

Quote from: rthrash

I’d argue that TVs/Content Fields should not be bound to templates at all, but to a "meta template" called something like a "Page Type" or "Content Type". This would allow you to have multiple TVs/Metadata/Templates/Chunks/Snippets/Templates/etc loosely bound together so that when you want a new Doc, you would click the magic "New Shopping Cart Page" button or "New Exec Bio Page"... TVs should by default be accessible to all Resources, unless specifically restricted ... not the other way around.

Interresting.

As long as there is a way to select which custom field have to be associated with a document, no problem with me. Page Type (as a label for it) would be better than Content Type since it would cause confusion with the actual document’s content type I guess...

Also, I’d like the ability to be able to still associate a Page Type to a template. I am thinking clients and editors there. If you don’t provide this, you’ll force content editor to make a double selection : one for the page type, and one for the template. This is source of error : content editors should be given as little critical choice as possible. That or an automatic selection which can be controlled by admin. Let’s say I create a document in the Product container (I have learned my lesson but for those who did not : folder), I’d like to have the ability as an admin to define an auto Page Type selection : "Product FactSheet" Page Type for the document created in the product or whatever container/folder (a bit like the InheritTemplate plugin does right now).

It’s been an interesting reading! Let me add my thoughts to it.

Quote from: rthrash at Nov 06, 2006, 11:47 AM

But even then it’s such an esoteric area to focus on that has zero impact on site usability/functionality/etc that it’s honestly not worth splitting hairs about.

Feel free to build your sites however you’d like though. As you’re well aware, MODx doesn’t put any restrictions there, and the demo content is not meant to be anything more than that ... just a demo and not a definitive best-practices guide.

It will definitely show the attention we (I consider myself a member of MODx development community) pay to the quality and conformity to web standards if both - the demo site and the manager - conform to correct use of doctype, semantic markup, and clean code.

Probably, however I’m not totally convinced about it, it will not add to the usability/functionality/etc. But it definitely will not hurt either! And this would be a very meaningful sign to those who take care of it (those who don’t will not notice anyway ).

The ability to have a total control over the markup was for me one of the most important reasons to switch to MODx.

I know, the manager in 0.9.5 is pushed to its limits, but it is possible to make it better in this area even at this stage. And the demo site shouldn’t be any problem.

Quote from: rthrash at Nov 07, 2006, 01:35 AM

TVs may disappear in the future in favor of everything just being a "content field" (including, shockingly, [*content*]). And everything might also be able to have an input filter and an output filter ... analogous to TV types and Widgets that are there today.

Great! I think all content fields should be treated equally as that approach would allow to use any document type which could be freely defined by the designer/master editor. I imagine I could create a separate document type for every publication need, be it an article, an image gallery, an image in the image gallery, a blog post, a FAQ, a product datasheet, a download... Each of those document types would consist of specific content fields - both for meta data and the actual content.

When editing a given document type, the editor would be presented with this particular set of content fields. Of course, document types and the content fields themselves should be controlled by access rights.

While editors should not be able to modify the structure of the document type, they should be able to add multiple instances of content fields in some cases - this applies particularly to downloads tied to articles. However, I’m not sure about this particular one.

There’s still lots of scenarios where that tight of coupling of TVs to Templates is too restrictive. What if you have a shopping cart with multiple layouts for different types of products, but all using the same exact data. Rather than duplicating the Content Type X times, a more efficient way is to simply allow different tempaltes. Templates should be assigned to Content Types, not the other way around.

Similarly, what about RSS feeds ... not technically a page. Or a PDF view or an eForm Template page ... the point being that not all content is a page, which to me indicates "Web Page" ... time to revisit and dust off that Lingo-olology that just got a friendly bump from a year ago!

Quote from: rthrash at Nov 07, 2006, 09:06 AM

Similarly, what about RSS feeds ... not technically a page. Or a PDF view or an eForm Template page ... the point being that not all content is a page, which to me indicates "Web Page" ... time to revisit and dust off that Lingo-olology that just got a friendly bump from a year ago!

Yes - we had a very similar topic some months ago. I was talking about CMS "simulating" documents out of tables.
Rethinking the topic, we should ask: What is "content"?
Basically, content is the content of a "field" (a cell, a column, a RAM-address, a whatever). Any type of set of such fields can be arranged in various ways or formats, on a surface (i.e. page) or a stream (i.e. feed or podcast), or both. The output-type as well as the criteria for the aggregation of content-fields - a search expression, a date, a user, a category - are virtually endless.

Just felt the need to add my 1ct to this magnificient thread

Quote from: silent at Nov 07, 2006, 09:22 AM

Rethinking the topic, we should ask: What is "content"?
Basically, content is the content of a "field" (a cell, a column, a RAM-address, a whatever). Any type of set of such fields can be arranged in various ways or formats, on a surface (i.e. page) or a stream (i.e. feed or podcast), or both. The output-type as well as the criteria for the aggregation of content-fields - a search expression, a date, a user, a category - are virtually endless.

Exactly! And a set of fields with content, a presentation template containing the layout and (visual) styles, and type of the content that is served (eg. application/xml+rss, application/pdf etc.) would form a given type of publication/document.

Quote from: rthrash at Nov 06, 2006, 06:06 PM

Those would be the planned "content packs"

How about "solution packs" instead... in my mind, these packaged versions are more about delivering a specific solution, and content brings to mind the content of the site... although, if you can provide a site with all the content, that would really blow everything else away

I agree that I think there should be some standards for the contributed items, like snippets, etc. The challenge is, until you start to work with something, you really have no idea whether there is "enough" information in documentation and examples. Yes, hopefully perculating up through the forum will help provide some of that, but in the end, I can think of anyone more qualified to at least lay the foundation of the documentation than the author... then users can provide feedback about changes, additions, areas where the author’s familiarity with the code is too much of a leap for users and needs additional documentation, etc.

Perhaps the repository could have a two-tiered setup and some kind of stamp of approval... I think I saw Ditto being labeled as "MODx Audited" or something. Something that shows that a snippet has been reviewed by the core team to show that the code is sound, future compatible (at least as much as possible, which might just mean till the next release), and has met a certain minimum of standard requirements. This wouldn’t stop other code from being submitted, but hopefully would provide a nice level of status for developers to shoot for which also provides users some measure that let’s them know what they can expect... they can still use other code, but knowing ahead of time that it may not be as clean and docs may not be up to standard allows them to make an educated choice.

Something that I thought would be nice in the templates would be nested templates.... right now, you would have to accomplish this with major chunks that are consistent across templates, and then create multiple templates with a few variations in chunks. But perhaps having a master or wrapper template that is consistent across all pages, and then if your main content area varies depending on the type of page, you could have dependent templates that can be selected for those sections at the page level... just trying to think how to cut down on excess coding... but not sure if it makes sense... still on my first cup of coffee

I actually agree that "Audited" would be good to use on well-documented, well-tested snippets, but the only one that is thus far is Ditto - which lots of people have trouble getting their head around. Unfortunately, the MODx Team’s priority is MODx itself. I think there is merit in an Add-On Audit Team who could help make sure that add-ons work in other languages and don’t clash with other Audited add-ons. Possibly they could focus their attention on snippets based on requests from users - in some ways a 3-star snippet may be in more need of an "Auditing" than a 5-star. However, I believe there is some understandable historically-motivated opposition to making any distinction between "official" and "unofficial" add-ons.

To return to the "meta template" stuff:
I know it’s just labels, but I’d rather documents were divided into DocumentTypes rather than PageTypes, as the document may not be a page, as has been pointed out in this thread.

If we treat each and every variable on the Edit Document screen as a Document Variable, including Template, including whether it is Rich Text or not, including the content type and content itself, as well as any "Template Variables", then the next step leaps out.

Each DocumentType should be able to set the default values of all these variables - including Template.
This would override the variable’s own default value.

This would associate the DocumentType with the template as David (and others) would like, but still provides room for over-riding it on a per-document basis without losing a load of variables.

But David’s users could still accidentally change the template.

So. Imagine next that as well as being able to set the default value, you can set whether these are editable...

Ping! Suddenly you are able to hide much of the complexity of the editor from other users.. suddenly it’s much easier for people to use. If they’re adding news pages that will be listed via Ditto, they just don’t need to see all the Uses template, Menu title, Menu index, Show in menu, Document parent stuff.

You could go further and decide what user groups / level of access can change some of the variables, and Document Type is a sensible thing to connect to security.

I also think that nested DocumentTypes will be beneficial - I can think of times when inheriting values from another DocumentType would be useful.

Now, how much of all this is the MODx 1.0 way??

Just to add a little to the TV dicussion.

There are some variables which apply to only certain documents, so it need to be assigned to certain templates (or as this discussion, maybe in the future assigned to document groups or something else), so a TV call ISBN might only apply to BOOKS and not AUDIO TAPE.

There are also variables that will be universal so it won’t depend on any templates or documents. For example I didn’t use the meta description feature of MODx but instead add a MetaDescription TV so I can easily enter meta description for all pages in my site. So it is universal.

There is also discussion earliers that mention that in the future every variable will be treated the same way (title, longtitle, and even main content and other template variables). Someone even mention that he setup a plugin to disable the ’content’ textarea. So maybe there can be an option to allow users to enable/disable certain fields? For example, if I never use longtitle, description and introtext, I can disable them and it won’t show anymore. Giving me a cleaner form. If possible, the user may even arrange the field according to his taste. For example he may want alias be the first field, title second, etc. Maybe the universal variable that I talk about in the last paragraph can be manage at the same place, where user can easily add/manage custom variables (that will act exactly like titles, description ....) in the same page.

If we click a document on the left pane, the page info is shown on the right pane. Well most of the time we click on it because we want to edit it, so why not have an options to allow user to choose what they want to do when we click on the tree node (the default action)? User can choose to display the page info (like now), or straight away to the edit page.

After adding a new document, we need to click on another tab to check ’publish’ to save a document in a publish mode. There are too many steps and most of the time I believe the user will forget to do that. He then need to reopen the document, click on the tab and check publish, then save again. Why not just have a publish button beside the save button when creating a new document? (refer to wordpress)

There are a lot of minor changes (fine tuning) that if done will make MODx incredibly user friendly, it is already so good now, why not make it the best.