Ooops, seems like Ryan beat me to the clock when I was writing this loooonnnng messsage... Editing inconsistent part out right now !
Hi Tom, it’s only normal to ask where we stand as far as MODx development is concerned,
given the scope of your project I would say even the current build is really up to the task (though you’d have to give more details to really check that out thouroughy).
Now, about the 0.9.5 release, it was originally set to be released at a much earlier date it’s true. For various reasons, we chose not to go forward with the intial plan, as we went along we realize it would be better to delay it for the time being, so that everything we had in mind would fit perfectly (we set high goals for MODx, and that’s also why I joined, most systems are so "mainstream" thinking kind of tool...). If anything, we might have been too transparent about our plans, too early. The thing is,
MODx development, even with the delay, is pretty fast if you look at the changelogs there are much added to each development cycle.
This will be even more true of the upcoming release (now we can use the word with certainty, since we are ironing the 0.9.5 beta for a release) : I’ll let dev team members give a time frame and go into more detail about what is new but I can tell you there are major changes there that will push MODx flexibility even further 
On a side note, let me say that
version numbering is something that you can’t compare from one project to another. I rember back at my Textpattern days where the 1.0 was expected, it was dubbed 4.0 after a series of 1.16gamma, 1.17gamma... etc. Those gamma were as stable as any final release in most opensource communities.
Anyway, my point is, 0.9.2 could have been a 1.0 if you consider :
- that it’s stable (almost never had to do any support for my 5 clients powered by MODx)
- that it has a rich feature set : not only standard features but also quite advanced stuff (not seen elsewhere, at that)
- that the community is strong and vital, with a growing user base
Really, 0.9.5 will be a major step up on top of that, turning MODx into what I believe to be one of the very top solutions around.
Anyway, CMS Made Simple is in beta for its 1.0 and they truly made some nice improvements, and they have an increasing number of extensions too. I know, since I sometimes use CMSMS for smaller projects. This being said, MODx is more than a CMS, it’s a content management framework. You can build custom applications with it, and you can build them faster and easier than with other systems.
You can do things with MODx you simply can’t (or at least not without serious additionnal development or heavy tweaking) do with CMSMS. Consider data structure : there is no equivalent for MODx template variable in CMSMS.
Most systems have a rigid way to structure content. Usually, content has a limited structure: Title, Summary, Body. Extensions (plugins, modules or the likes) sometimes offer to manage different types of content (images, products, job offers…): but again, they force you to use a predefined content structure which does not necessarily fit your particular needs. When they do offer a way to create custom content fields, they are either limited in number or in types of fields.
With MODx you don’t suffer from those limitations :
- You can create any type of custom content fields: text, rich text, number, date, images, checkbox, dropdown, email, url… with no limitations whatsoever. The best part: you can do so directly from the backend, without ever having to alter the database structure manually.
- Each custom field is linked to a given template: that’s why the custom fields are called Template Variables in MODx. It allows you to define which templates can use the custom variables, and possibly define several content structure if needed.
- You can use, style and place those content field easily: a simple tag, [*my_template_variable*], and you can display the content wherever you like, the way you want it displayed. Better yet, if you need to make it available for frontend editing, just add a # before the variable name [*#my_template_variable*].
With this capabilities, I have built a company directory, a catalog for a travel agency, and I am finishing a big project with lots of custom content (more than 80 custom fields, 400 pages, some privates some public, lots of custome querries...etc). It’s really a great tool
Those are part of the reasons I use MODx when my clients need customization.
I have gone the "pre-packaged" way (e.g use a ready-to-go module or extension of some kind) before .
I ended up loosing a lot of time tweaking those modules to get them to do what my client needed, and on top of that, looking like my client want it. All in all, while it might seem counter-intuitive, it’s easier to build something with MODx than install a module in say, Joomla. Templating is so much more flexible.
Now, there are case when customization is not an issue :
when you deal with "standard" content, modules are great because they provide a quick and efficient solution. More often than not though, you’ll have to do at least a bit of customization to have those modules styled as you want them to be. Plus, if you need you website to evolve and add custom features in the future, it’s better not to have to switch to a new system... That’s why I now use MODx for almost every project, except maybe the smallest ones.
To end this particularly long message,
I have looked for the Hospitality Reservation Module in CMSMS Forge, but didn’t find it... how close is it to a release ?
I would advise testing it before making a choice. That would also mean you already know what data structure you need and that this particular module can fit the bill...
MODX Staff
