I disagree here; I think both tracks can be fulfilled, at least in limitations on one of them. We aim to be more of the latter but from a CMS perspective; I really do think a good bridge between developer and designer can be made.
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.
We have said we’re a Content Management Framework - not necessarily a PHP Application Framework. There’s a difference, I think. (If our marketing copy says we’re a PHP app framework, i’ll go take Ryan out to pasture - j/k ryan - we’ll fix it.) Our CMF centers more around the content management side of framework development.
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).
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.Agreed; but this can easily be remedied by development standards, best practices documentation, developer incentives, conferences, etc.
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.
Agreed.
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.
I also think CodeIgniter’s docs are quite good too. But let’s be fair here with Revo:
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)?Admittedly, these docs lack big time. We could use some help on how documentation for this would look, as I’ve stated above. I agree that vision for 3PC development needs help being written down.
Where do I put my custom (or vendor) classes?I hate to say it, but this will depend on your solution. Now, with that said, we can provide some default scenarios, as I have done in a few tutorials.
Is something going to autoload them?Depends on your implementation, what "custom classes" in your definition is, what the development is for, etc. You need to provide more information on your requirements and scenario here before we can answer that question.
Can I manipulate the ORM if I need to optimize my join queries?Most definitely; such documentation can be found in the xPDO docs, specifically on xPDOCriteria, found here: http://svn.modxcms.com/docs/display/XPDO10/Retrieving+Objects
Can I load only the parts/classes of the framework that I know I need?Sure. Services can be manipulated. It depends, again, on what you’re developing. A 3PC? A custom manager page? A front-end snippet? What is it you want? Case scenario?
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.Well, it’s hard to answer questions that are too vague to answer.
I understand your point, but to be fair, you need to provide more details on your case scenarios for us to provide adequate answers for them. Engineers didn’t discover flight by saying, "How do I fly?" or "How does one build something that goes in the air without falling?" They asked very detailed questions, like about the aerodynamics with relation to wind patterns, or how to implement wing structures that will properly correlate to the friction of air versus the compulsion of gravity. Case scenarios, in other words.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?Yes and no. Some people aren’t going to have File System access, but are still going to want to be able to write small snippets. Limiting snippets to FS-based only causes a whole host of problems and accessibility issues. Sometimes you want non-static Elements, sometimes you don’t.
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?A few things - permission issues, security issues, location of those files to allow proper SVN deployment within a SVN-based Revolution, etc. It’s not as simple as it first sounds.
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...You don’t have to write a Transport Package to maintain an IDE - you can simply include from the snippet, and edit with the IDE. Transport Packages are only for remote deployment and integration into Package Management - the ability to remotely download and install packages from within the manager. They also help with versioned installations (something SVN cannot do because it can’t maintain DB versions), resolving database differences, post-setup scripts, pre-setup validations, etc. They are an advanced and optional feature. You can still develop a 3PC without them.
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 withWell, those docs need to be corrected then.
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?Chunks are partial views, along with Resources - Snippets are controllers. Saying that you can put whatever you want in either confuses that separation, and leads to a whole slew of other problems with maintainability, flexibilty, and proper structure. I completely, wholly disagree with your statement here.
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.I think this is a true statement.
Generally speaking, It seems to me that a CMS is just a fancy name for an application for performing CRUD operations on content objects.This is an inaccurate oversimplification, in my opinion. You could say that about any application, written, ever. CMS’s do much more; they provide caching mechanisms, separation of code/content layers, site creation automation, client-friendly environments, etc.
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.Revolution provides those hooks; albeit they aren’t fully documented yet. Again, I think you’re confusing a Content Management Framework (what MODx is) with a PHP Application Framework (what CI or Symfony is).
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.It’s definitely not inappropriate; we don’t mind comparisons. Each is strong in their own respect.
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.Smarty, as much as I like it, does not provide an accurate view layer. PHP by itself is just as much a view layer as Smarty - Smarty just gives it different syntax. Compare in Smarty:
{foreach from=$myArray item=foo}
<li>{$foo}</li>
{/foreach}
<?php foreach ($myArray as $foo) { ?>
<li><?php echo $foo; ?></li>
<?php } ?>
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.And then you spend weeks trying to get the UI benefits for your clients that they want. In my opinion, CMSes are wildly popular in the web world currently because they are not CRUD scaffolding. They don’t automagically populate all your CRUD systems; they rather provide frameworks for that to happen and let you populate data. Symfony will never be a good CMS; nor will MODx be a pure PHP Application Framework like Symfony or Zend. That’s not their intent, nor their market.
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.And I can tell you that leads to all kinds of confusion between the View and Controller layer, that has ruined upgradability, flexibility, and developability for hundreds of startups, projects and development systems over the past 20 years in all sorts of different computing environments. Cocoa, for Mac, is a very popular language because it completely separates View models from Controller logic. We should not, imo, confuse the two.
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.I also doubt that RAD-oriented PHP folks spend much time in debating proper staging issues with dev to production migrations for dynamic sites manageable by multiple users, some of whom don’t know what SVN means, allowing for proper installation procedures to work on vastly different server environments, versioning of content without SVN dependencies, and remote deployments.
They add complexity to the PHP dev process (and time, and extra work).And they are completely optional for people who want to do it the old way. Transport Packages are optional. You don’t get remote deployment, versioning, install options, install validations, and dev-to-staging solutions all in one solution if you don’t use them, but hey, that requires extra work and time. (Snarky, sorry, but true.)
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.So don’t use them.
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 beastThe marketing copy referenced has been adjusted, the offending persons for writing such copy have been flogged, and we will make sure the reference doesn’t happen again. That said, I still argue that Revolution when it hits GA will be the best Content Management Framework out there.
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...Probably because the Revo docs need some love. I’ll look into adding that...but where?
If I wanted to open an auto repair shop in my neighborhood...I better know what the inside of one looks like, no?I’ve worked with both those systems, and can tell you that the problem isn’t with the Revolution framework; we just haven’t finished the docs yet. It’s in beta. There’s 2 of us actively on it. We’d love to have more help. Maybe I’m misunderstanding you - if this is your way of volunteering to help for documentation, then why didn’t you say so earlier.
I disagree here; I think both tracks can be fulfilled, at least in limitations on one of them. We aim to be more of the latter but from a CMS perspective; I really do think a good bridge between developer and designer can be made.
We have said we’re a Content Management Framework - not necessarily a PHP Application Framework. There’s a difference, I think. (If our marketing copy says we’re a PHP app framework, i’ll go take Ryan out to pasture - j/k ryan - we’ll fix it.) Our CMF centers more around the content management side of framework development.
<title>Content Management System, PHP Application Framework, Web Application Framework & More - MODx</title>
That said, I’ve worked on 4 fully separate applications (an order fulfillment system with code managed from SVN, a native threaded forum solution, a cataloging system, and a suite of applications) that use all or part of MODx Revolution technologies. And I have definitely not found them inadequate for the task. Immature in their application, or documentation, yes; but not inadequate.
We’ll also be developing CLI utilities later on; we’ve already got Ant scripts for the build process, and hope to enhance that later on. We’ll also in 2.1 and onward be looking into developing the models for other DB systems. And as i’ve mentioned elsewhere, we definitely want to create some form of scaffolding for 3PC development; we just have to get out of beta first.
Agreed; but this can easily be remedied by development standards, best practices documentation, developer incentives, conferences, etc.
Free market systems often produce higher quality products because of comparative pricing; such systems also work in OS development environments because good programs "push out" bad ones. We hope to create something similar here.
Now, I’m not saying that to toot our horn or anything. I’m simply saying it to state that Revolution has made vast progress in the last 6 months, and will in the next 6 months. And this is with 2 developers. If we had more active, consistent ones...we’d get a ton more done. We’ve started to have a few more getting interested (bobray, shamblett, everett, others that i’m forgetting atm), but not as much on the core as in 3PCs.
With that said, I will fully, 100% admit that the documentation needs work. But this is Open Source - and Jason and I can’t carry all of that load. We’re trying, but there’s only so many hours in a day. We need people who are willing to get dirty with the docs, and create structures for good documentation that either Jason and I, or others, can fill out. So far no one’s biting. Maybe that’s our fault, maybe it’s not, maybe it’s the recession. Who knows.
Well, it’s hard to answer questions that are too vague to answer. Wink I understand your point, but to be fair, you need to provide more details on your case scenarios for us to provide adequate answers for them. Engineers didn’t discover flight by saying, "How do I fly?" or "How does one build something that goes in the air without falling?" They asked very detailed questions, like about the aerodynamics with relation to wind patterns, or how to implement wing structures that will properly correlate to the friction of air versus the compulsion of gravity. Case scenarios, in other words.
Yes and no. Some people aren’t going to have File System access, but are still going to want to be able to write small snippets. Limiting snippets to FS-based only causes a whole host of problems and accessibility issues. Sometimes you want non-static Elements, sometimes you don’t.
That said, having "static" Elements (Elements are chunks, snippets, plugins, etc) is planned for Revolution 2.1. We just couldn’t make it in the 2.0 release; there was already too much on the plate, and we had to table some things.
A few things - permission issues, security issues, location of those files to allow proper SVN deployment within a SVN-based Revolution, etc. It’s not as simple as it first sounds.
You don’t have to write a Transport Package to maintain an IDE - you can simply include from the snippet, and edit with the IDE. Transport Packages are only for remote deployment and integration into Package Management - the ability to remotely download and install packages from within the manager. They also help with versioned installations (something SVN cannot do because it can’t maintain DB versions), resolving database differences, post-setup scripts, pre-setup validations, etc. They are an advanced and optional feature. You can still develop a 3PC without them.
Well, those docs need to be corrected then.
Chunks are partial views, along with Resources - Snippets are controllers. Saying that you can put whatever you want in either confuses that separation, and leads to a whole slew of other problems with maintainability, flexibilty, and proper structure. I completely, wholly disagree with your statement here.
This is an inaccurate oversimplification, in my opinion. You could say that about any application, written, ever. CMS’s do much more; they provide caching mechanisms, separation of code/content layers, site creation automation, client-friendly environments, etc.
Revolution provides those hooks; albeit they aren’t fully documented yet. Again, I think you’re confusing a Content Management Framework (what MODx is) with a PHP Application Framework (what CI or Symfony is).
Smarty basically just cleans up the syntax into a tiny-bit-friendlier format. It does not, in essence, create a view layer. No logic should, imo, exist in a view layer.
And then you spend weeks trying to get the UI benefits for your clients that they want.
In my opinion, CMSes are wildly popular in the web world currently because they are not CRUD scaffolding. They don’t automagically populate all your CRUD systems; they rather provide frameworks for that to happen and let you populate data.
Symfony will never be a good CMS; nor will MODx be a pure PHP Application Framework like Symfony or Zend. That’s not their intent, nor their market.
And I can tell you that leads to all kinds of confusion between the View and Controller layer, that has ruined upgradability, flexibility, and developability for hundreds of startups, projects and development systems over the past 20 years in all sorts of different computing environments. Cocoa, for Mac, is a very popular language because it completely separates View models from Controller logic. We should not, imo, confuse the two.
I also doubt that RAD-oriented PHP folks spend much time in debating proper staging issues with dev to production migrations for dynamic sites manageable by multiple users, some of whom don’t know what SVN means, allowing for proper installation procedures to work on vastly different server environments, versioning of content without SVN dependencies, and remote deployments.
The marketing copy referenced has been adjusted, the offending persons for writing such copy have been flogged, and we will make sure the reference doesn’t happen again. That said, I still argue that Revolution when it hits GA will be the best Content Management Framework out there.
Probably because the Revo docs need some love. I’ll look into adding that...but where?
I’ve worked with both those systems, and can tell you that the problem isn’t with the Revolution framework; we just haven’t finished the docs yet. It’s in beta. There’s 2 of us actively on it. We’d love to have more help. Maybe I’m misunderstanding you - if this is your way of volunteering to help for documentation, then why didn’t you say so earlier. Smiley
Thanks Stephen. We hope you’ll stick around, continue contributing to this discussion (and maybe to some docs or code too!), and enjoy your time with MODx.
MODX Staff
First, developers are not the target stakeholders for MODx and certainly should not be the only ones who can install it. But more importantly, it’s much more than a "storage medium issue"; they are in the database for metadata and configuration purposes within the MODx platform (I think I’ll refer to MODx as a platform rather than framework from now on, to avoid unwanted comparisons with pure development frameworks). This is absolutely necessary and comes with huge benefits if you understand the complete architecture and that all the Content Elements that are used to make up Web Resources are meant to be reusable and configurable by people other than developers.
Maybe I’m still missing something (and I haven’t gone as far as to diagram an actual proposed alternative solution)...but it seems to me that in order to install MODx at all, devs need * some * level of file system access, then there’s caching and other mechanisms that require the web server process to be able to write to the filesystem on a regular basis. All I’m suggesting is that MODx could store snippets and such on the filesystem so that devs who *do* have filesystem access don’t have to deal with the extra work (no matter what you tell me, or how little extra work it is, it is in factual terms extra work) of using the MODx manager to create snippets that do nothing more than a PHP include. And of course, these types of devs would be able to set the path where snippets should be stored. Folks without day to day direct filesystem access will never know the difference because they’ll just be using the manager. Sounds like a win-win to me - so one of us must be missing something.
It’s just a MODx-internal storage medium issue. So I’m still wondering about my original question: why does MODx *need* to store code in the DB in the first place? Or, put another way: if I’m the type of developer who will likely never store my code in the DB of a CMS, what’s in it for me to agree to do the extra work of maintaining these snippet/include hooks (simple cost/benefit)? It’s an unusual model which breaks sharply from tradition, and thus deserves some justification, no?
Another way to look at this: As above, I agree that there is somewhere in our not to distant future a way to please both sides of the development equation. It must be kept in mind, however, that not all teams have separate people playing the roles of designer, frontend guru, backend guru, dba, sys admin, hand-holder. Obviously the composition of a team varies widely so that sometimes, as I (and probably many folks reading this) know well, one person is playing some, most, or all of these roles. In those cases, which are the majority, the person wearing multiple hats doesn’t want or need any extra steps to accomplish his/her tasks - especially if the benefit of doing so is not made clear.
Just the opposite; Snippets promote complete portability and reusability by their very nature, as do all Content Elements.
addendum: I haven’t thought too hard about what the code-in-db model means in terms of application portability or reusability (and I don’t have a full MODx app to analyze yet), but my sense is that it wouldn’t be good.
He means that instead of the actual source content of the Element being stored in the DB, a file path is stored in the DB which points to this source content. This would be true for any Content Element including Templates, Chunks, Template Variables, Plugins, and Snippets.
I’m not sure what you mean exactly by “static” elements, but if it means “I get to continue keeping my code where I want without doing extra work”, then forget what I said above.
This is why PHP is looked down upon by most skilled developers and attracts unskilled ones; we prefer to encourage proper separation of presentation and content by providing specific types of Content Elements. This is not a restriction as much as it is purposeful organization.
We might have to agree to disagree on this one. The HTML-only restriction you place on chunks has the implied assumption that $phpCode === $businessLogic, which is in itself fundamentally flawed and an oversimplification. Further, the fact that snippets can easily (and quite often, as I’ve observed) build and return HTML/presentation-layer code further obviates the need for and effectiveness of such restrictions. Placing limitations on the system based on fundamentally flawed assertions in the hopes that it will instill MVC purity on the users of the system is at best naïve, at worst it’s shooting the system with “Zero restrictions” in the foot. It’s an interesting theory, but so far I’m just not buying it. My humble opinion.
Another way to say this: you can’t force people to write good code by legislating it. The best you can do is show them how it’s done, and hope for the best. In the end, it will always come down to the knowledge level and discipline of the person writing the code.
It’s a framework, and even an application framework, but is distinct from the developer-centric idea you refer to as a "PHP application framework".
Perhaps. And perhaps it’s just semantics - some of your (and Jason’s) other commentary (and the title tag that is broadcast to the world) suggests the vision for MODx is that it become a full-fledged PHP application framework. Time will tell
It’s not at all futile, and again is an organizational choice to encourage proper separation. As you alluded to, you can still circumvent this by returning presentation-related output directly from your Snippets.
Smarty basically just cleans up the syntax into a tiny-bit-friendlier format. It does not, in essence, create a view layer. No logic should, imo, exist in a view layer.
Right. And I think that’s what the role of a view layer focused system or sub-system should be. As above, I think trying to force/legislate that people comply with proper, pure MVC structure (and I share your purist view about logic in views) is misguided and futile, and places arbitrary, indefensible restrictions on the development process. I’d love to be proven wrong, however.
You are separating web apps from web sites with no justification IMO; I see this as an arbitrary difference perpetuated by the egos of developers who think they are the only one’s who should be able to build robust, functional web sites, and of designers who think they are the only ones who can construct sharp-looking ones.
Obviously, this depends on the project needs, and who the “client” is. Sometimes that client is the person in the next cubicle, or the CEO of a startup who just needs his app to work for investors, and can afford to slap on something fun to manage content with later.
And then you spend weeks trying to get the UI benefits for your clients that they want.
I do blame the tools for perpetuating the problems; that’s like not blaming cars with bad fuel efficiency for an energy crisis. And it’s not legislation; it’s encouragement combined with purposeful application design not all of which is related to our puritanical feelings on separation of presentation and logic. Perhaps this is clearer after reading the information on how Revolution implements the MVC pattern and various related sub-patterns, and we can move on to a new level of the conversation.
And I can tell you that leads to all kinds of confusion between the View and Controller layer, that has ruined upgradability, flexibility, and developability for hundreds of startups, projects and development systems over the past 20 years in all sorts of different computing environments. Cocoa, for Mac, is a very popular language because it completely separates View models from Controller logic. We should not, imo, confuse the two.
Don’t blame the tools for bad programmers and failed businesses, and don’t continue to fool yourself into thinking you can legislate good code. I don’t know much about Cocoa, but knowing what I know about Apple (I’m an enthusiastic Mac user), they’ve probably made it difficult for you to hurt yourself too bad by writing bad code, and in the process placed all sorts of restrictions on your flexibility. I won’t be holding my breath for Cocoa to take over the world. Either they’ve set things up this way, or they’ve done what the MVC oriented frameworks have done: Defined a standard based on experience and best practices, and provided enough examples for anyone who’s interested to “get it”. Obviously I think this makes more collective sense.
Jason addressed some of your reply, and some of it I agree with, and maybe we just misunderstood each other. That said, I’ll only reply to the parts I feel necessary to reply to (and will shorten our posts!).Yes, it does; your Snippet can point to a file on the filesystem, and you can store metadata about it in the DB while still managing the snippet code in SVN and editing in your favorite texteditor. This is planned for 2.1 or sooner (but not for 2.0).
I’m not sure what you mean exactly by “static” elements, but if it means “I get to continue keeping my code where I want without doing extra work”, then forget what I said above.
Definitely not a non-issue; I think each of those are solutions for different needs. If you’re doing a unique project never to be distributed again, static file development with SVN is the way to go. If you’re developing a 3rd Party Component (3PC) that you want to make generic and distribute, Transport Packages are the best way to do this.
Sounded like there was a dependency between managing projects with svn and using transport packages...seems like a non-issue now.
I agree; of course, this introduces the question - what is a base level for a Component? Does it include lexicon support? I think I have an idea, but again, this is key. Also, should such features be in the core of MODx, or a "utility package" that can be installed via Package Management? Going the latter route would cut down on size for the Revolution base install, but would add an extra step for devs (albeit a small one). Which do you think?
That’s why I said the scaffolding was simply a good starting point - not the end game. Not only because it saves you time, and results in a usable complete application, but also because you are starting with a beautifully written, MVC-pure, body of highly-reusable code to extend in any way you like - and to learn from if you’re not already an expert. This is the kind of thing that developers who know the difference have fallen in love with.
Hehe, present commitments prevent me from volunteering to deliver anything concrete right now, but MODx is squarely on my radar (and now the basis of a site that I’ll be managing) and I’d welcome the opportunity to become somehow more involved at some point.Well feel free to post any questions or concerns you have with MODx while deploying the site. Our community is fantastic (they really are) and are quite active and very, very helpful. They’d be glad to answer any questions you might have.
Even though I may disagree with some of your approach, something tells me that what you’re up to is pretty darn cool, and well worth paying attention to. Also, hopefully some of what I’ve said here will fire you up - but in the best way possible.Oh, I love these kinds of posts - they keep us thinking, refining, focusing. And hopefully the posters end up contributing even more. I, for one, definitely appreciate your words here.
Don’t know if I can keep up these long back and forth posts though...might eventually need to just pick up the phoneFeel free to PM me and I can give you my Skype info. I’d love to talk about what you have to say. Thanks Stephen.
First, developers are not the target stakeholders for MODx and certainly should not be the only ones who can install it.
This is why PHP is looked down upon by most skilled developers and attracts unskilled ones; we prefer to encourage proper separation of presentation and content by providing specific types of Content Elements. This is not a restriction as much as it is purposeful organization.
The perception that PHP is not fit for serious development is a far outdated one, and I’m a bit surprised that you would help perpetuate it. If nothing else, the fact that some of the largest and most heavily trafficked sites in the world are built on PHP is a modern testament to it’s worthiness - I won’t name them, because I’m sure you’re aware. We agree conceptually on the end goal of sound, layered applications - we (so far) disagree somewhat with regard to how to proliferate the practice of building them.
It’s a framework, and even an application framework, but is distinct from the developer-centric idea you refer to as a "PHP application framework".
It’s not at all futile, and again is an organizational choice to encourage proper separation. As you alluded to, you can still circumvent this by returning presentation-related output directly from your Snippets.
You are separating web apps from web sites with no justification IMO; I see this as an arbitrary difference perpetuated by the egos of developers who think they are the only one’s who should be able to build robust, functional web sites, and of designers who think they are the only ones who can construct sharp-looking ones.
I do blame the tools for perpetuating the problems; that’s like not blaming cars with bad fuel efficiency for an energy crisis
I agree; of course, this introduces the question - what is a base level for a Component? Does it include lexicon support? I think I have an idea, but again, this is key.
Also, should such features be in the core of MODx, or a "utility package" that can be installed via Package Management? Going the latter route would cut down on size for the Revolution base install, but would add an extra step for devs (albeit a small one). Which do you think?
the ability to customize a MODx base install to personal or project-specific needs sounds great. In the end, I code for the fun of it, despite the roof it keeps over my head....there, I said it...
So, without having actually built or seen an example of a big-ish MODx app, the idea of a UI forcing it’s way between me and my code is hard to imagine being fun. My dream platform will provide a nice and powerful enough UI for the stakeholders on my team who want/need it, and leaves me and my code and my command line to rock onI really hope you get to look more at MODx Revolution, especially it’s internals. I think you’ll be pleasantly surprised.
MODX Staff
I may have forgotten the word "only" before target, but I absolutely mean it. Making the construction of a web site dead simple for non-developers is key to bringing down initial and total cost of ownership for businesses that need a web presence, which is just about any business these days. The whole point of a web framework like MODx is to provide commoditization of common tasks, and MODx is trying to take this to the next level by encouraging the development of generic components which site administrators, designers, and other non-developers can deploy themselves.
First, developers are not the target stakeholders for MODx and certainly should not be the only ones who can install it.
I don’t think you really mean this. Developers are clearly among the critical stakeholders a development “platform” must seek to serve. If you did mean it, then who are the target stakeholders?
I never said it wasn’t fit for serious development, so I’m perpetuating nothing. In fact I debate this daily with developers who insist that Perl, Ruby/Rails, Python, etc. are far superior languages. My point was that the trend of mixing presentation and logic that started with ASP/JSP/PHP has no place in this content management system, as it’s primary goal is to isolate these so those with the most skill in each can do their job most efficiently. And further, the part of the MVC sub-pattern represented by Elements in MODx is completely flexible in terms of not separating it. For all I care, you can include a PHP file in a snippet and echo and print to your hearts content. It would take creating a single snippet that uses an output buffer and collect this output and returns it.
This is why PHP is looked down upon by most skilled developers and attracts unskilled ones; we prefer to encourage proper separation of presentation and content by providing specific types of Content Elements. This is not a restriction as much as it is purposeful organization.
I think we’ve been hanging out with different skilled developers
There are numerous, impressive sites currently in the wild that are constructed with MODx without the involvement of a single developer. Existing components were used by people who simply learned the MODx templating/configuration system to construct these. So no, it is in no way obvious to me that the simplest of sites would require the involvement of a developer, and would further say that the goal is to prevent this in as many situations as possible, while making it easy for developers to extend site functionality as needed, in small incremental pieces if necessary (as would be dictated by modern agile approaches) and with as few limitations as possible.
It’s a framework, and even an application framework, but is distinct from the developer-centric idea you refer to as a "PHP application framework".
I hear you, and as I’ve said before, I respect the fact that you guys are cutting a new trail - but I reject the notion that what I describe is developer-centric. No matter what your vision is, it won’t go far unless developers get on board. Obviously, an installation of MODx is useless for all but the simplest of sites without the involvement of a developer - so things have to make sense and be efficient for them. The PHP application frameworks that I refer to make things easy and powerful for developers not as a self-serving exercise, but as a means to the end goal of pleasing clients (and the other stakeholders in the equation).
Chunks are for designers, snippets for developers. Developers use chunks to provide an easy interface for designers to completely customize the output of their functional snippets. Or, if you have no need for designers, don’t use Chunks at all, and force the site stakeholders to use the markup your Snippet generates itself. If you are the stakeholder, it’s not an issue, but it seems silly to me to have to call a developer to change markup within a Smarty template for a skilled HTML/CSS designer who does not understand and does not want to understand a foreach loop. If you have Chunks serving as templates for each iteration of the loops in your code, they don’t need to call you and can get on with the design while you develop another cool component.
It’s not at all futile, and again is an organizational choice to encourage proper separation. As you alluded to, you can still circumvent this by returning presentation-related output directly from your Snippets.
Again, this is where we disagree on approach. I don’t think you’re teaching or even encouraging proper separation, you’re attempting to mandate it by building restrictions into the system. Maybe it’ll work toward our shared goal of “better-built apps everywhere”, I’m just having a hard time seeing how it would. The fact that a dev who has no idea what MVC is will end up with only HTML in his/her chunks does not make him/her a better developer - he/she’ll still be as ignorant to best practice app structure as when he/she started, and will transfer no knowledge to the next, perhaps non-MODx project.
I would argue that all of the web-based applications you describe could have used someone who’s focus was on usability and design, leaving you to focus on logic and functionality. Presentation is presentation, regardless of the project IMO. If we’re talking about daemon server processes, or cronjobs, or other things without a presentation layer through the web, then I might agree. But I also do not disagree that some projects don’t have the luxury of providing user-experience experts or UI designers and it would be more efficient to just get the job done without separating presentation and logic. In those cases, or in cases where the abstraction layers add too much overhead for the required performance, then a framework that does not require this separation, or no framework at all would be a better solution. Otherwise, I’ll stick to my guns here.
You are separating web apps from web sites with no justification IMO; I see this as an arbitrary difference perpetuated by the egos of developers who think they are the only one’s who should be able to build robust, functional web sites, and of designers who think they are the only ones who can construct sharp-looking ones.
Not at all. There is a legitimate separation to take note of here, and our misfiring on this is probably just an outgrowth of our perhaps differing development experience. Personally, I’ve built more internal web-based applications (analytic tools, back office/staff management, helpdesks, custom event management, etc) which were all but devoid of textual content, than I have public-facing web sites (which tend more toward content-heavy). Think: traditionally client-based software applications gone web-enabled, hence my use of the term web application.
Although I may be in the minority with this experience (and preference), for these types of projects, choosing (and/or getting signoff for) a platform that had its roots and focus in Content Management (or whatever words we choose) would have been (or at least seemed) absurd to all stakeholders. This has nothing to do with anyone’s ego IMO, but has everything to do with choosing the right tool for the job. And for me in the context of this discussion, it’s trying to understand what I might use MODx for, outside of the current small content-based site I’m working on. Drawing this distinction isn’t in any way arbitrary.
Agreed, and I know the Revolution paradigm is still somewhat abstract at this point. Example implementations will indeed go a long way in solving this problem. But I think education must be supplemented with commoditization and regulation (so long as that regulation consists of simple, clear principles that do not inhibit innovation); and that’s as far as I’ll take that metaphor.
I do blame the tools for perpetuating the problems; that’s like not blaming cars with bad fuel efficiency for an energy crisis
I still feel the root problem cause here is lack of education (in both development and fuel efficiency...unless we can blame the Bush administration across the board hehe). No matter how good the tools are, if people aren’t educated in how to use them (or why they should be using them in the first place), then they are essentially useless in the collective sense. We don’t have terrible fuel efficiency simply because the cars are built poorly, it’s because people (in the US anyway) haven’t (until very recently) been educated enough in the collective to demand more fuel efficient cars. Tools don’t make better programmers (or carpenters, or drivers, etc), programmers learn how to make better tools - with proper education. So, I don’t blame the cars.
Also I read your post on the MODx internals, and while I’m intrigued and on-board conceptually with all that you say, I think it’s wise to reserve further specific judgment until I’ve gotten my hands a bit more dirty with things. And although I’m certainly curious enough, unfortunately I just don’t have the luxury at the moment to find my way through the deeper side of MODx by trial and error - I need a bit of hand holding, and I’m probably not alone...some example implementations would sure go a long way...but I’ve already said enough (too much?) about that...
As for an example of a big app, I’m really wanting to hopefully get a alpha preview of the native threaded forum, called Discuss, I’ve been working on out in the next month or two. We’ll see. I might go ahead and put it in the public SVN for those who want to play with it before then, or look at the code.
Sounds great. I’ll eagerly await public availability of Discuss, good luck bringing it along.