Rethinking MODx

Ryan,

Thanks for the acknowledgment and I think your order is actually better than mine.

OT (may be moved to another thread if necessary): This is a pet peeve of mine, but I am a standards-based developer who doesn’t agree with the XHTML 1.0 as a current standard for web sites to be viewed in web browsers. I would love to see you change all instances of XHTML to (X)HTML because for most sites there is no reason to use XHTML over HTML 4.01 since XHTML is NOT a replacement for HTML but a "reformulation of the three HTML 4 document types as applications of XML 1.0 [XML]. It is intended to be used as a language for content that is both XML-conforming and, if some simple guidelines are followed, operates in HTML 4 conforming user agents." - XHTML™ 1.0 The Extensible HyperText Markup Language (Second Edition), W3C.org

Since few people actually use it for its intended purpose and since most browsers don’t actually support XML 1.0--delivering what is actually HTML to HTML user agents--is not (necessarily) the correct use of the DOCTYPE.

Too many developers, helped by web development application manufacturers*, jumped into using XHTML erroneously, thinking it was the "latest" version of HTML when in fact HTML 4.01 is the last standard for delivering HTML to conventional user agents like Firefox, IE, Safari, and etc.

Let me know what you think. Maybe I am just turning into a curmudgeon.

*Dreamweaver and GoLive’s default Doctype is XHTML 1.0 Transitional and most users never, ever change this. Don’t even get me started on transitional Doctypes on new sites.

If it weren’t for the quirks mode oddities and (what I believe but am probably wrong about) several of the ajax libraries needing a specific doctype, I’d put some time into thinking about the change. 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. In other words, it’s working now and is one of those areas that’s almost purely philosophical in making an argument one way or the other.

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.

Ryan,

You are right, it is probably too esoteric an issue. And yes, there can be issues for DOM and AJAX because of some of the real limitations of the spectrum of elements and browser support. As I said, it is merely a pet peeve and was really off handed. It never hurts to ask the question though.

All the best,

Jay

Actually, I think it might be okay keeping Development at the end.

Realistically, there may be those who don’t move to the next level, and one could certainly, I think, build MODx sites, administer them without moving to that next, more advanced Development level. It could start to introduce a bit of a mental overload for some of us

Those who consider themselves "developers" are probably going to skip to that section first no matter where it is. This could also be a way of saying, okay, now that you’ve got a site installed, designed, up and running, getting comfortable with how things work out of the box and have an idea how editing works, either for yourself or for your users... now, just as you were getting bored or starting to think you have everything mastered, you are ready for some turbo-charging.

I forgot to mention earlier, but I really like the idea of some future distros. This is something that the Drupal camp is really starting to grasp on to, even to the point where anyone can create their own distro... talk about creating a dream packaged for designers/developers. Not only will this be great based on cutting through some of the confusion and helping people get up and running quickly with a very specific need, I think this could provide an excellent learning tool, kind of a live tut in a box... need to know how to setup MODx as a blog site? Grab the MODx blog ’n a box and away you go. Need a typical brochureware site with news publication? Here you go.

Those would be the planned "content packs"

I still think the order is more appropriate and reflective of where MODx stands right now though, especially for those that will be less frustrated with an initial experience, potentially.

Quote from: Neutrogeno at Nov 02, 2006, 04:34 PM

2. The whole hyerarchy thing is simply old school. Instead you should introduce the concept of "section" and eventually "subsection". Each post should belong to a section (or sub-section). Home page should be a section apart. Friendly URLs should be mapped on the schema section/(subsection)/articletitle. So you could eliminate the archaic and ambiguous folder/file tree at left in the admin panel.

Joomla? Yucks. What if you want to organize a book with a lot of chapters, sub chapters and sections? With Joomla it is very hard for you to create a nice navigation menu. And note that Section/Categories is no hierachy at all (not even 2 level) because all documents must fall to a category! You can’t put a document under a section without category.

Quote from: Neutrogeno at Nov 02, 2006, 04:34 PM

4. Template Variables should be tied to one or more sections not to templates. TV are related to data structure not presentation.

Yep, I agree on this. There should be some kind of ’TV’ that is universal, once created will be available to all documents (so it can no longer call TV, haha). I think of TV as some extra data that I can attach to my document, for example if all my contents is about books, I will create 2 TVs call ISBN and Author. It really has nothing to do with template. It is more an EV - Extra Variables. My friend created a TV and couldn’t find a way to use it the whole day, until he find out that he need to enable the specific template for that specific TV! So the logic behind TV is hard to grap.

At Last, my personal comment.

Please! Write some documentation and examples for ditto. The current documentation is a list of features (not documentation). There isn’t enough explanation, tutorials and examples!

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. Then again I could be pulling your leg. Or not.

I think all modules before getting listed on the site should have full install instructions and lots of examples and "how to do this" type of stuff. Also some of them need a requirements list, I installed a module that didnt work with mysql version that I had running.

Quote from: rthrash at Nov 07, 2006, 07: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. Then again I could be pulling your leg. Or not.

Actually, this last bit will make a lot of sense to me : [*content*] is just an arbitrary field which is supposed to be always required, but in my case I have to extensively use the HideEditor plugin to mask the content field upon editing, for many of my MODx documents use only TVs... Now I guess what you’re suggesting there Ryan will mean a slightly different database structure, wouldn’t it ?

Back on labelling TVs : It would really not be Extra Variable thus, but rather Document Variable or Content Variable.

About "TV are related to data structure not presentation" : I sure can understand why Neutrogeno said this, but even so I wouldn’t like being unable to have different data structure for different documents. Further, there has to be a way to tie document structure to the presentation layer : as far as the web is concerned most of the time every document data structure is intimately tied to the way I publish the information, e.g the presentation (for instance, let’s say I build a product datasheet with TVs, all documents associated with this document structure / set of TVs will be product sheet and probably will need a single coherent layout and styling).

I am not so sure templates are such a bad way to operate.
If it does change, we should also keep in mind that a user should easily be able to choose which data structure a document should use.

Quote from: davidm at Nov 07, 2006, 10:11 AM

Actually, this last bit will make a lot of sense to me : [*content*] is just an arbitrary field which is supposed to be always required, but in my case I have to extensively use the HideEditor plugin to mask the content field upon editing, for many of my MODx documents use only TVs... Now I guess what you’re suggesting there Ryan will mean a slightly different database structure, wouldn’t it ?

I was wondering how I could hide that cus I dont use it either.