Warning: very long post below, I don’t know what got into me. Jason, be careful what you wish for when inviting someone to engage in a discussion
I think 2, but I’m biased as a core developer. Wink I truly do want to engage you in this conversation, as it is central to our adoption issues. IMO, we’re in a catch-22 where we need more developers to "see the light" in order to make life for designers and end-users more productive without having to be a jack-of-all-trades.
I think it turns out that actually it’s a combination of a bit of all 3. In the end though, it would seem to depend on what you want Modx to be, and to whom. For example, if you want to give folks who are building content focused web SITES a better way (compared to some of the alternatives) to sprinkle in programmatic customizations - with a strong designer bias, then you’re on the right track. But – I think if you want to convince developers who are building (perhaps larger scale) web APPLICATIONS with some content sprinkled in to use Modx, then you have some work to do.
Interestingly, I found this blurb from smashingred in the comments on this page:
http://www.devtrench.com/things-that-suck-about-modx-cms (sorry about the title, but the author, in truth, loves Modx): “You will also see the erroneous use of MODx being labelled as an Application Framework disappear when the new site is up (month or 3 from now) and all the documentation will clarify this and more.”
Also from the body of that article: “I just don’t see the structure there to really call it a framework, and I would prefer to call it a CMS with an open or pluggable architecture”.
I tend to strongly agree with both of these comments, but it looks like you guys have decided to stick with the application framework label. My opinion is that the label just doesn’t fit (today), compared to almost any of the true application frameworks out there – and people who understand what a framework can be, aren’t ultimately going to be fooled. From what I can tell, the current MODx platform just doesn’t scale well from an application sustainability and maintainability point of view, and it falls well short of providing the types of tools that framework users have come to expect (eg, command line utilities, choice of ORM, scaffolding, etc).
We make no assumptions about how to write/maintain code, but provide similar ideas to partials/helpers; maybe they are hoops, but I don’t see them that way. The key is in separation of presentation and logic, decoupling if you will, and that’s what makes MODx completely different than the other beasts IMO. The problem is, developers continue to not properly separate these things and the contributions reflect poorly on the vision of keeping them separated. We need more developers to participate here and create generic solutions that reflect this vision to change the perception and that is tough to do with so many PHP CMS and framework options out there. The only thing that has to be coupled with the CMS is how you present output from your components, and even this is extremely flexible in MODx. Everything else is wide-open, and the real difference is going to be (IMO) in package management, where the API allows scripting control over how things are installed, upgraded, etc., be it content, code, or custom data objects.
Standardization and Documentation
Conceptually we agree (as most of the development community does) that separation of presentation and logic is a good thing. Where we seem to disagree is in how to not only implement this well, but how to do so in a way that encourages others to adopt the same currently accepted best practices which are in line with your vision.
It’s perhaps the "wide-open"ness of MODx that is one of my concerns about the platform. The current system encourages an almost freestyle approach to building apps - this tells me something about the quality of add-ons, etc that I can expect (and have observed). This architecture helps designers and users (and budding developers) get more involved in the process, but when folks can freestyle their code, the result is usually not something you can expect to easily and cleanly build upon or reuse, as you alluded to. It’s human (developer?) nature - provide little structure or guidance for coding on a platform, then people will do it poorly. And going from one contribution to the next will always be like starting from scratch, because there is no standardization. This is one of the reasons I’ve mostly moved away from other CMS (beast) communities, and toward the deeper frameworks. There is little comparison between the quality and reusability of the code that emanates from these very different camps.
It’s good to also keep in mind that every framework that’s worth the bytes it’s sitting on allows you to do things in whatever way you want (MODx is not the first) - BUT - the really good ones first tell you how the framework is intended to be used, if you’re planning to comply with the authors’ suggested best practices - AND - they provide well thought out, complete examples. So, these problems can partially be traced back to the documentation.
We all know how difficult it is to write documentation and keep it up to date, but no matter how good your intentions are, if you don’t communicate them clearly, you’re unlikely to get as many people on-board as you hope. Two of the best collections of documentation are for Symfony and for jQuery (CakePHP’s are pretty good too). Full of examples and suggested best practices, and written for someone who has never used the tools before. I’m sure I’m not telling you anything that you haven’t already heard, but speaking candidly, not only are MODx’s docs sparse (I’m perhaps unfairly referring to Revolution), but the language often assumes a level of familiarity with MODx concepts that most new users just won’t have.
I’ve read the docs, blog tutorials, forum postings, and picked apart some add-ons (including SPForm), and I’m still confused about how it’s intended that my app be set up. Tpl files, connectors, processors, chunks, snippets, i18n files...how is this all supposed to be set up (according to the vision)? How do the pieces fit into the MVC pattern? Where do I put my custom (or vendor) classes? Is something going to autoload them? Can I manipulate the ORM if I need to optimize my join queries? Can I load only the parts/classes of the framework that I know I need? Are all questions that left unanswered will make it difficult for anyone building more than a content site with a few cool features to adopt MODx.
Design Philosophy and Code Maintenance
Perhaps maybe the biggest and most problematic assumption MODx makes about how to write/maintain code though, is that developers would ever want critical business logic to be stored in (or dependent on) the db of a CMS - except in special circumstances.
Whether we’re talking about snippets or pseudo snippets which only do includes (which, to me, is a hack - not a documented part of the system design), the result is the same. Given the extra work and problems that this introduces for developers who use IDEs and version control (as just 2 examples of potential problems), it begs the question: why does any code/business logic *need* to be in the db in MODx? ie, what design goal is this satisfying? Is there some performance or other benefit to storing snippets in the db? Shouldn’t a best practice oriented framework encourage the best practice of keeping code under version control by making it easy, rather than forcing extra steps - and actually making it easier to avoid this best practice?
Why not let the snippet editor in the MODx manager simply edit files on the file system, so developers have a legitimate choice of how to maintain them? The more I think about it, the more strange it seems that by its very design MODx is suggesting that I dump my IDE to write code in a text area – for many people this is a very strange notion...or have to build/maintain something called a transport package just so I can keep my IDE...it’s just a little upside down...Although I’m guessing maybe I’m still missing something about your intentions where this is concerned...
Also, I read somewhere in the official MODx docs that the suggested workflow was to first test snippet code outside MODx, then paste it into the snippet box. For the many developers like me who are always looking for ways to speed up their development process, this is a conversation ender. I’d almost rather teach PHP to every designer I’ve ever had to work with
Another example is forcing developers to use only HTML in chunks and PHP in snippets. Why? I think I appreciate what you’re trying to achieve here, but shouldn’t developers have a choice for what kind of code goes in views vs controllers?
So, while MODx succeeds in decoupling some application layers when compared to those other beasts, it introduces tight coupling in the areas of workflow and application structure - and I’m finding this particular tight coupling unnatural and uncomfortable...and limitations not found in other true frameworks.
I think the nature of this problem potentially rests in our fundamentally differing views of what a CMS should be, and whether or not there should be a line drawn between a CMS and an application framework architecturally.
Generally speaking, It seems to me that a CMS is just a fancy name for an application for performing CRUD operations on content objects. All the other objects in my application should sit next to (not under) the content CRUD module – and I should be able to choose how I want that application to work: freestyle, framework-based, or other. A useful CMS would provide nice API hooks so that my other application objects can interact with content programmatically, while designers and users have an easy intuitive interface for interacting with those objects – and that’s where the CMS’s job ends.
So, one of the underlying problems for me is that MODx is starting to remind me of those infamous beasts by taking the position that “the CMS is the thing” and everything that happens in an app has to talk through the layers of the CMS (and MODx even goes further by helping me keep my code in the CMS), rather than just letting it be the CRUD module that it really is. As MODx continues to grow in this direction, I worry that it will become just another beast – and never a framework. Remember, leading up to the time of the initial 1.5 overhaul release, people started calling Joomla a framework too...it’s still not. In my humble opinion, hammering on a CMS to make it into a framework is a bit misguided from the start.
Hope it’s not inappropriate to discuss other perhaps competing projects here, but this seems to be a good example. I haven’t gotten past the home page of the Silverstripe.org project yet, but I see that they’ve packaged the CMS and the framework separately. This immediately makes much more sense to me as a starting point, from an architecture point of view.
IMO, this is the most difficult issue for CMS systems to tackle. There is always an intimate relationship between presentation and logic, and how to de-couple those without making the developer’s role or the designer’s role impractical is the challenge; one we’re trying to tackle head on here. I don’t think the existing CMS beasts as you call them, or pure development frameworks like Symfony are able to address this in the same way, but I may be wrong too, as I’ve been immersed in the MODx world for many years now. I’d love to hear more details of how these "partials" and "helpers" work in fact, if for no other reason than as a reality check.
Some of the PHP frameworks have been implementing MVC well for a long time now (Symfony among them), and I personally am a serious devotee to the pattern – so, separating presentation from business logic is a problem that has already been solved by the collective mind – so I tend to disagree here. Further, setting things up so that designers can focus on design and not code is something that things like Smarty templates and others already do pretty well – but this has little or nothing to do with a framework – it’s a thin sliver of the the view layer that the underlying application framework should be fairly, if not completely agnostic to – much less exerting control over.
While the frameworks already do an excellent job for pure application development, they have traditionally fallen short in the area of Content Management. It’s been mostly up to developers to roll their own, or somehow integrate an existing system. It hasn’t been pretty, but fortunately some frameworks (eg, Symfony) will auto-generate clean, object oriented CRUD code from a data model (with a single command line command) – which saves hours/days of programming, and provides a nice starting point for a custom CMS with sound best practices already built in.
This has started to change in the last year or so with the maturation of a few CMS plugins for some of the frameworks...which sit on top of the framework along with your other modules, rather than the other way around. This also means that if you don’t like a CMS, you can swap in another one quite easily with low to no impact to your application logic.
I won’t go into detail about helpers/partials, except to say that partials are like chunks (but you’re free to put PHP code in them), and helpers are like snippets – to extend the view layer functionality (but you’re free to put HTML code in them). There’s plenty of other info on the net for the curious, including the Symfony docs. So I have to point out that the limitations you’ve placed on what kind of code can go where may not seem like limitations to you, but they are – especially to a developer who’s used to having total freedom.
This is certainly a valid issue, but we manage all of our code in SVN, then use transport packages to prepare it and install/upgrade it into an ongoing site/project. Most of our snippets are simply file includes that bring in classes or files containing the code needed to perform a specific task, along with configuration properties that can be controlled by a site designer or end-user, so that is not an issue.
One of the beauties of PHP itself is its simplicity with regard to dev environments - and I think it should stay that way. <?php echo ‘hello world’; ?> is a complete script – add a web server and a browser and you’re done. Transport packages sound more like something cooked up in a clustered java deployment environment for an enterprise application, than something for RAD-oriented PHP folks. They add complexity to the PHP dev process (and time, and extra work). And we all know that more complexity usually results in more problems somewhere along the way. They sound like they’d be great for deploying add-ons, or for maybe deploying apps to remote servers, but for day-to-day development, IMO they just sound like a pain - having a hard time finding the justification for these extras from an overall workflow point of view.
After all is said and done, I think it really does come back to where I started with this diatribe: just being clear and honest about what you want MODx to be and to whom. Right now, I respectfully think you’re not being honest with yourselves (or the public) by calling MODx a PHP Application Framework. It’s simply and quite objectively not, when held up against the other developer-focused frameworks – BUT – MODx kicks major butt for what it IS – a pluggable, easily extendable CMS (or website management system)...a better beast
Like all tools, MODx, in its current incarnation, is great for a particular size and type of project and for users of a certain skill and experience level. It would seem wise to be clear and focused about that, and try to get as many people that fit the mold on board, rather than the “all things to all people” that it seems to be trying (or at least advertising) to be now.
I will say though, that after reading splittingred’s post above, it looks like I will actually be using MODx for the personal site I’m working on.
For now, my site only needs hooks into the CMS, and a nice UI for me to manage the content. I’ve already built the entire view layer (HTML, CSS, PHP, JS) with stubs for the actual content, and have been looking at candidates for the backend (and ways to enhance my knowledge of the current state of the art). He provided a perfect example (I’d vote for including it in the docs somewhere) to show me how easy it will be to plug my UI into the CMS part of MODx. Maybe I should have checked the older docs, but I found nowhere in the Revo docs any mention of how to retrieve content...
With all this said, if you’re serious about pursuing adoption from framework-savvy developers, then I’d recommend building something with Symfony (or CakePHP as my current second choice), and reading the docs – just to see how it all feels first hand. I think you’ll see what I mean. If I wanted to open an auto repair shop in my neighborhood...I better know what the inside of one looks like, no?
I hope this all didn’t sound too much like a rant. I get the feeling you spend a lot of time inside the MODx box, so I’m just hoping to give you some honest perspective about what it looks like from outside that box - at least from where I’m sitting...and maybe something I say here will inspire you to turn it around and teach me something about the possible errors of my ways.
Hope this provides some useful info, and didn’t bore you to tears or take up too much of your day...
☆ A M B ☆
MODX Staff
