next »

[gspark]

From first look, it appears ExpressionEngine is something Modx is heading towards -  a multi-purpose everything framework ? What most of us would be interested in is a multi-framework we can use for everything, blogs, mai lists,  forums, website etc instead of having to use mutliple software.

http://expressionengine.com/overview/features/

[davidm]

Yeah I know EE I have used it for 2 years for my blog... great software, but cluttered admin IMHO and MODx is more flexible... I don't have time (leaving for w-e) but I'll get back here with a more detailed comparison...

[Bravado]

Not to mention that Expression Engine isn't free whereas MODx is. 

[rthrash]

But EE is really nice and their site redesign is incredible. Good stuff really, but not the same thing as MODx. I think MODx is more like a blend of Code Igniter and EE.

[CoolGoose]

Well i think that modx 0.9.7 new manager will surpass expression engine and immersecms.
I've played with expression engine a while (the free version) and the fact that you use templates as different "folder" from modx is very strange and sometimes irritating .
I hope that modx 0.9.7 will start to have a good documentation for the framework. Something like the one from codeignitor would be great cause that one is super

[Everett]

I've inherited several EE sites, and you can't argue that EE is full-featured and well-documented.  What I don't like about EE is the following:
In EE, EVERYTHING is a blog post in a weblog.  By default, EE does not provide the nice Folder/document structure view that MODx has.  I like to think of my content as living in certain places, and MODx lets me do that.
In EE, your templates have content.  In MODx, you choose how your content is viewed.  So in MODx, you open up a page, then you select which template that page will use.  In EE, you build a template, then within that template you specify which content that template will display.  This is a simplification, and both systems have ways of extending or overriding that behavior, but for most of the sites that I've worked on, MODx just made more sense.

Isn't Code Igniter built by the same folks as EE?  Ellis Labs?

[davidm]

Yes it is and Expression Engine 2.0 is built upon CodeIgniter, EllisLab is betting that this will attract CodeIgniter developpers to EE and boost plugins creation. That's a very smart move, and the EE 2.0 video was really a big step up from the current release... we shall see.

[Everett]

MODx could get a lot of mileage out of promoting the xPDO stuff... write some really solid documentation (preferably run it by someone who isn't an expert in that stuff and see if they can stumble through it).  Some videos would be a godsend, and I'd suggest using more clear names... lord, xPDOObject doesn't tell me a thing about what the heck that object is or why I'd want to extend it.  Little things like that just make it more difficult to understand. 

What I'd love to see in MODx is the ability to define arbitrary tables... e.g. "Store Locations", and then the manager could control the CRUD access to edit/update the address, city, state, and phone fields.  You can emulate this with Template Variables, but it's not 100% clean when it comes to the database architecture.  Expression Engine offers more flexibility there, but it's not all that clean either.  A GUI front end for defining table relations would just be amazing... I've only really seen it in Filemaker... ha.

[OpenGeek]

MODx could get a lot of mileage out of promoting the xPDO stuff... write some really solid documentation (preferably run it by someone who isn't an expert in that stuff and see if they can stumble through it).  Some videos would be a godsend, and I'd suggest using more clear names... lord, xPDOObject doesn't tell me a thing about what the heck that object is or why I'd want to extend it.  Little things like that just make it more difficult to understand. 

It's an xPDOObject, so it is providing what ever user-defined class you want to build with xPDO access to all the methods it provides.  This is much like PHP's stdObject, though every object implicitly extends stdObject in order to gain access to it's methods, whereas xPDO requires that your classes explicitly extend xPDOObject.  As I said in the other topic, nothing good documentation won't cure...

What I'd love to see in MODx is the ability to define arbitrary tables... e.g. "Store Locations", and then the manager could control the CRUD access to edit/update the address, city, state, and phone fields.  You can emulate this with Template Variables, but it's not 100% clean when it comes to the database architecture.  Expression Engine offers more flexibility there, but it's not all that clean either.  A GUI front end for defining table relations would just be amazing... I've only really seen it in Filemaker... ha.

This is the vision, to have visual and programmatic editing and lifecycle-maintenance tools in MODx/xPDO for user-defined domain models reverse-engineered from existing databases and/or generated along with new custom database designs, in a way that makes it easy to develop and maintain applications, manage data structures and relationships, and even share data across various storage engines.  We're only part of the way there, but hopefully, what we've done with xPDO already (i.e. developing MODx Revolution 2.0, and other projects that we'll hopefully be able to turn into case studies) will attract the attention of enough PHP developers, UI designers, and technical writers, and others interested in contributing to the effort to make that vision a reality sooner than later.

[Everett]

This seems an appropriate place, but one area where MODx beats Expression Engine hands down is the ability to find what code is handling a particular url.  Say you've got something like mydomain.com/path/to/page... in MODx, it's really obvious that you'd go looking in a folder named "path" for a sub-folder named "to" where you could find a page named "page"... maybe you'd have to examine the template code and its associated chunks to find the exact bit of code you needed to change, but it's a very simple and direct process for finding the code that is used to handle any given url. 

In Expression Engine, you have template groups that contain templates... the template manager has a search feature, but in my opinion, its implementation is very difficult to use by comparison.  In the EE sites I'm maintaining, the act of merely FINDING the code I need to change has been the single biggest time-suck.  EE reminds me of the Windows Registry... it's kinda like a black box... some things are straight-forward, but there are enough caveats to drive you crazy.  EE isn't as bad as the Registry, but I never had that amount of trouble finding things using MODx.

[dev_cw]

mydomain.com/path/to/page

This is only true if friendly paths is turned on. On some sites it is domain.com/page_alias so the path would be hidden. But in this case you could simply use the /page_alias and know what document it is about (since each alias in this case needs to be unique). 

In my opinion the only thing that EE may have on modx is that it has a "prettier" manager (noticed I said pretty not more functional, their media manager rocks) and that may be challenged in Revolution soon anyway.

[davidm]

Good point Shane but Revolution will face another beast altogether with EE 2.0, the new admin is really strikingly better than the 1.x branch not to mention the codebase (2.0 rewritten with CodeIgniter). And they dropped some of the concepts like weblogs that "boxed" EE into a restricting pattern...

Though Revolution will be even more flexible and usable than Evolution, the competition is not resting either : it will be fierce, and one of the strong contender IMHO will be EE 2.0.

[Everett]

Well, I'm a big believer in healthy competition... cross-pollenation etc.  Onward!

[shamblett]

Agreed, competition leaves you no alternative but to improve, we'll just have to make MODx better won't we!

[mwalsh]

This is an interesting thread.  Despite being an avid fan of MODx I am considering Expression engine for a couple of projects largely because of the "multi-purpose everything framework" that it offers.  These particular projects, where I have to deliver a normal website, blog, forum and online shop, despite all being possible in MODx it's probably easier to produce using Expression Engine where most of that functionality is covered by core modules.  It would be great if MODx can start to move into this space.

[ed]

This is an interesting thread.  Despite being an avid fan of MODx I am considering Expression engine for a couple of projects largely because of the "multi-purpose everything framework" that it offers.  These particular projects, where I have to deliver a normal website, blog, forum and online shop, despite all being possible in MODx it's probably easier to produce using Expression Engine where most of that functionality is covered by core modules.  It would be great if MODx can start to move into this space.

Indeed an interesting thread. I have developed client sites with both MODx (0.9x) and recently EE, at present there is for me one clear difference between them, support.

EE has copious high-quality documentation and excellent on-line support. MODX, errm, has room for improvement. Consequently with EE there is a gentler learning curve and problems get resolved much more quickly. For commercial projects, IMHO, EE is the lesser risk and the license fee is immaterial.

Will this change with EE 2.0 and MODx Revolution?  We'll see.

[Everett]

Yes, for heavy commercial sites, EE might be a better alternative, simply because you can get someone on the phone if you need to, and there are a lot of built-ins and a big library of plugins and modules.

I still think you end up wasting a lot of time in EE... their template system is convoluted in my opinion (not nearly as easy to hand over template design to dedicated front end people), and the layout of the manager is excessively restrictive.  Is it worth the time you save with well-crafted blog and shopping cart plugins?  It's possible... 

[chinesedream]

This is an interesting thread.  Despite being an avid fan of MODx I am considering Expression engine for a couple of projects largely because of the "multi-purpose everything framework" that it offers. 

About "multi-purpose everything framework", MagentoeCommerce dot com (mc) is a good example of EE I think. If you use the site often enough, you will find many "UI" flaws, using 'm' deafult themes, you can tell that folks at Varien are not very good at UI but I think many problem in the mc site is more on how  EE's  multi-purpose everything framework works- the limitation

I like the idea of "multi-purpose everything framework" however I am also a strong believer that one can't excel in everything. I'd been playing with the Revolution Alpha 6 quite a bit lately, and really loving it, I hope Modx focus on what it does best, not multi-purpose everything.

[rthrash]

If you like Alpha 6 download, you'll love what's in SVN trunk.

[OpenGeek]

I like the idea of "multi-purpose everything framework" however I am also a strong believer that one can't excel in everything. I'd been playing with the Revolution Alpha 6 quite a bit lately, and really loving it, I hope Modx focus on what it does best, not multi-purpose everything.

Not a chance that we will change our focus; the entire philosophy behind Revolution is to provide both a basic developer framework and a content management framework for constructing sites out of components that can easily get access to common services.  By not providing all of these common services in the core framework, or at least by providing ways to allow developers to provide custom implementations of these services without hacking core files, we leave the field wide open for custom, optimized solutions to be delivered on the platform, and for much easier integration with existing solutions (at least in some cases, depending on what is being integrated and how it was built).  This may mean the initial cost of development and ownership is higher with MODx, but the life-cycle maintenance and change costs can be greatly reduced, as will the potential for vendor lock-in with the components themselves.