Evo or Revo?

I’ve heard someone say the depreciated stuff will be released as an addon. Not sure if that’s true / planned but that may help you out in that case...

Quote from: Mark at Apr 21, 2011, 06:39 PM

I’ve heard someone say the depreciated stuff will be released as an addon. Not sure if that’s true / planned but that may help you out in that case...

That would certainly be useful and is useful to know - thanks.

-- Tim.

The whole engine has been redesigned for Revolution. The deprecated methods have been replaced by ones that are much more efficient and OOP-compliant. In every case, it’s relatively easy to convert to the new methods.

getTemplateVars() is a good example. To get the TVs attached to the current resource, you now use:



The upside is that once you understand the xPDO get*() methods (e.g., getObject(), getCollection(), getOne(), getMany() ), you can do just about anything without ever consulting the docs. You can get any object related to a resource with something like this:



The first one gets a user object and the other two get a resource object.

And you can get any field of any object (user, resource, TV, system setting, whatever) with this:



These are all fairly clunky processes by comparison via the old DBAPI.


Honestly, once you get used to the new methods, you cringe at the thought of working with the DBAPI. My productivity is up by a factor of at least 10 with xPDO.

More info here: (and a list of the deprecated methods).

Me again

I may be a newbie at MODx but I have been designing and programming websites for 12 years so I do have an experienced eye on the these things.

OK.....

I have now used Evolution and it’s like coming out the cold; the manager is fast, I can work properly. The interface is much more intuitive and easier to grasp, these two thing together would have meant if I started this way round I probably wouldn’t have bothered with this debate.

I miss the package manager but i am sure I’ll understand the Evo install process for modules easily enough. And the tag syntax is not as elegant.

So, my question is modified somewhat; Should I, as a designer and developer of SME and community websites (ie page limit is unlikely to be a deal breaker) , go with Evo or Revo? What will I gain from Revolution?

Oh, and thanks to all who have responded to my newbie fumblings.

I don’t intend to get into an argument with Jason + company nor to denigrate what they’ve done; I quite willingly admit they are brilliant programmers, and Revo is an amazing piece of work. I just haven’t felt any pressing need for it. If that kind of thing is your preference, then by all means Revo is the way to go. For me, Evo makes me happy.

As I’ve said before, I don’t really see the big advantage to resource-hungry OOP in the average web site. What’s the difference in actual development - include a class file (which itself requires a bunch more files and objects), instantiate an object, and call its functions, or just include a file as needed with the desired functions? I somehow got the impression that websites were supposed to be as fast and light as possible, and heavy OOP just isn’t either one. I’ve never liked extJS or Smarty either, probably for much the same reasons.

That’s not to say there isn’t room for a lot of improvement to the Evo manager, but I really don’t see the point in making it into something that is slower and requires more server resources for the average basic website.

I won’t rant too much about the architecture, except to say that after you do OOP for while, everything else just looks wrong. Since everything is an object in Revo, I can do almost anything I want to just by knowing the object name, and how to use a handful of universal methods. I spend *way* less time wading through MODX code and can write code off the top of my head that usually works the first time.

As for the Manager, the Revo Manager is definitely slower, but there are so many pluses that it makes me far more productive. Just to name a few:

• Clearing the cache without leaving my spot
• Editing any element or resource in a pop-up window without leaving what I’m working on
• Full list of all resources, elements, and files visible at all times
• Quick search for all system settings - with descriptions
• Default properties and property sets
• Very quick download and installation of add-on components in Package Manager
• Grid listing all default properties of add-on snippets and plugins -- with descriptions -- editable while editing the add-on

Quote from: BobRay at Apr 28, 2011, 03:36 PM

As for the Manager, the Revo Manager is definitely slower, but there are so many pluses that it makes me far more productive. Just to name a few:

• Clearing the cache without leaving my spot
• Editing any element or resource in a pop-up window without leaving what I’m working on
• Full list of all resources, elements, and files visible at all times
• Quick search for all system settings - with descriptions
• Default properties and property sets
• Very quick download and installation of add-on components in Package Manager
• Grid listing all default properties of add-on snippets and plugins -- with descriptions -- editable while editing the add-on

I like the first one - but it more inspires me to write a short Evo module than switch to Revo. This is one of the common issues I remember from my brief flirtation with Revo - there were some good features - but they could have been implemented on Evo for far less effort. The baby seems to have been thrown out with the bath water.

Having said that, after a brief reality check, much as I like the first point, that one, the second and the third are solved reasonably easily by just having multiple tabs open in your browser (switching browser tabs is no more difficult than clicking on buttons/tabs/whatever in an ajax application).

I don’t need to search for system settings in Evo. There is a manageable number and I know what they mean. There is a brief description/reminder by each one. Having to learn a whole load more isn’t balanced out by a tool to help me when I haven’t done so yet. This is less of an issue for newbies who need to learn some settings anyway (but AFAIK much less in Evo than Revo), but again I find myself wondering if this learning curve is going to be worth it.

Property sets - in Evo, if I want to put in the parameters for Ditto pagination, I have a chunk with them in and just have [!Ditto? .... {{DittoPagParams}}!] in my templates. Done. I have these in a text file that I just paste into a the chunk when a site requires it. You can even mimic the Revo order of Default Element Properties -> Property Set -> Tag-defined Properties by putting the chunk before any parameters specific to that snippet call. Property sets are already there, they just are not menu driven, and don’t have a buzzword.

I can see the package manager being an attraction - but lets have another reality check - just how long does it really take to install something on Evo? Download a file, usually unzip the contents, copy into your local webspace or ftp/scp to a remote one, and paste in a snippet/plugin. Done. Its a small fraction of my development time and while it may occasionally be an iritation its not a deciding factor in which CMS to use.

Built in documentation/summaries of default properties and the like is great up to a point, but I can’t see them being a substitute for proper documentation. Also, the vast majority of snippets I am already familiar with. Newbies won’t be, but they probably need the full documentation/tutorials initially.

You’d be right to point out that the above in general do not constitute disadvantages with Revo. For newbies these specific points are probably neutral ones in that I’m saying there is little difference. However as I already know Evo and am happy with it, why would I wish to have a learning curve when I see no advantages?

-- Tim.

Good points, but remember that for many newbies, installing a snippet or plugin in Evo is a pretty daunting event and many of your workarounds would be out of reach.

I like the first one - but it more inspires me to write a short Evo module than switch to Revo. This is one of the common issues I remember from my brief flirtation with Revo - there were some good features - but they could have been implemented on Evo for far less effort. The baby seems to have been thrown out with the bath water.

Having said that, after a brief reality check, much as I like the first point, that one, the second and the third are solved reasonably easily by just having multiple tabs open in your browser (switching browser tabs is no more difficult than clicking on buttons/tabs/whatever in an ajax application).

True. But I can’t count the times I had three of those popups open in Revolution, ordered around a template I was editing, to build a menu/listing/search with several templating chunks. That’s something you can’t have with multiple tabs, and multiple windows will stack so isn’t feasible unless you have a couple of monitors set up.

I don’t need to search for system settings in Evo. There is a manageable number and I know what they mean. There is a brief description/reminder by each one. Having to learn a whole load more isn’t balanced out by a tool to help me when I haven’t done so yet. This is less of an issue for newbies who need to learn some settings anyway (but AFAIK much less in Evo than Revo), but again I find myself wondering if this learning curve is going to be worth it.

It took time for me to get used to the system settings in Revo - but searching them is a big plus. What if you want to change one setting, and you know what it’s known as (the key). Would you rather go to the right tab and scroll to the right position, or just type in the first three letters, hit enter, and change the system setting which automatically updates? (no need to click save at the top or bottom of the page!)

Property sets - in Evo, if I want to put in the parameters for Ditto pagination, I have a chunk with them in and just have [!Ditto? .... {{DittoPagParams}}!] in my templates. Done. I have these in a text file that I just paste into a the chunk when a site requires it. You can even mimic the Revo order of Default Element Properties -> Property Set -> Tag-defined Properties by putting the chunk before any parameters specific to that snippet call. Property sets are already there, they just are not menu driven, and don’t have a buzzword.

Revolution allows you to finetune your caching, and by using [!Ditto? ... !] you are giving up on your caching, and your site will lose a lot of speed in fetching the resources every single page load. May not be a problem if you have 50 pages, but what if you add a few zeros to that?

I must admit I rarely use property sets thought - but just cause it’s there for advanced users doesn’t mean you have to use it. You wont even notice it’s there!

I can see the package manager being an attraction - but lets have another reality check - just how long does it really take to install something on Evo? Download a file, usually unzip the contents, copy into your local webspace or ftp/scp to a remote one, and paste in a snippet/plugin. Done. Its a small fraction of my development time and while it may occasionally be an iritation its not a deciding factor in which CMS to use.

I have to disagree there. It’s not just installation, but also updating. It’s not having to go to the modx site, downloading the package, uploading every time a new version comes out. But wait.. how often have you updated an addon in Evolution? Probably only when you had serious issues - there was no way to know a new version was released (which may very well fix a bunch of serious bugs, and add that functionality you’ve been waiting for!) unless you’d watch the addons page carefully. The Package Manager checks it for you, and shows them in red whenever you visit the package manager. Just click on it, and it’ll fetch & install in < 30 seconds.

Built in documentation/summaries of default properties and the like is great up to a point, but I can’t see them being a substitute for proper documentation. Also, the vast majority of snippets I am already familiar with. Newbies won’t be, but they probably need the full documentation/tutorials initially.

Documentation is available at rtfm.modx.com - that’s also where the "Help" buttons get it from iirc. It’s just a shortcut, and for new users it can be convenient to just have it when they need it.

You’d be right to point out that the above in general do not constitute disadvantages with Revo. For newbies these specific points are probably neutral ones in that I’m saying there is little difference. However as I already know Evo and am happy with it, why would I wish to have a learning curve when I see no advantages?

-- Tim.

Because those changes that may seem minor at first definitely increase productivity, system efficiency and what not. After working with Revolution pretty much solely since December I can’t stand working in Evolution anymore... I miss my quick update, not having to think about mixing up cached & uncached snippet syntax to get something basic working etc etc.


Now that was definitely a pro-Revolution post (and I’ll never deny I’m a Revo fanboy) but if you need the faster loading and are willing to negotiate that for loss of flexibility & scalability you’re allowed to do that and I encourage you to choose whatever works best for you.

@Mark

You have a very good point with the package updating issue.

On the other hand how many developers here have maintenance contracts with the owners of the sites we build? As we don’t (usually) these sites are unlikely to be updated anyway (I’m not saying this is a good thing!). I’m not sure that it would be a good idea for clients to upgrade themselves as I suspect that they are more likely to incur problems from buggy updates than any security holes.

Still, that notwithstanding, you have a good point there, certainly in the cases of sites which by their nature should have ongoing updates and maintenance. On a similar vein there is the pragmatic point that if Evo is in effect dumped via lack of marketing/development than Revo will have the more up to date code.

Revolution allows you to finetune your caching, and by using [!Ditto? ... !] you are giving up on your caching, and your site will lose a lot of speed in fetching the resources every single page load. May not be a problem if you have 50 pages, but what if you add a few zeros to that?

The example was about property sets, so this is possibly confusing two issues. Firstly, regarding caching, replace [!...!] with [[...]] in my example. Yes - I gather Revo has more fine tuning available with caching. On the other hand, as I’ve never had a problem with running Evo sites with pages invariably uncached, I’m as yet not inclined to worry. Neither am I inclined to worry about sites with more than 5000 pages - I have one such site which occupies 1/2 to 2/3 of my time and has done for almost two years, but its completely bespoke code and an off-the-shelf CMS would be unlikely to be suitable for this particular site. Furthermore from browsing the forum I see issues with large sites and the manager (this may be solved by now - I don’t honestly know) in which case worrying about the frontend seems a little academic anyway.

In short, I suspect that most sites bigger than the nominal 5000 Evo limit wouldn’t be using a CMS anyway, and if I was to build one that would be that size and be suitable for a CMS, I wouldn’t be using MODx (at the moment).

I must admit I rarely use property sets thought - but just cause it’s there for advanced users doesn’t mean you have to use it. You wont even notice it’s there!

Back to property sets - refering back to my last post, the point is they were there, just with no buzzword. Making something menu driven and adding a buzzword does not make it more advanced!

You are right though when you point out that we can just ignore what we don’t use. What I was primarily trying to get across in my last post however is that alot of Revo’s features such as property sets are not enabling anything ’new’ - its just different.

Now that was definitely a pro-Revolution post (and I’ll never deny I’m a Revo fanboy) but if you need the faster loading and are willing to negotiate that for loss of flexibility & scalability you’re allowed to do that and I encourage you to choose whatever works best for you.

Indeed, and I wouldn’t deny I’m a Revolution cynic . I’m less than convinced of flexibility. I think the scalability may come (based on the fine tuning available), but thats as yet unproved in practice (based on forum postings).

I should reiterate that I don’t think Revo is bad - I just don’t think its better. Even if I was to become convinced that it was better, given the learning curve involved I’d want to know that Revo (as opposed to other non-MODx CMSs) would still be the best solution for me.

-- Tim.