Evo or Revo?

@tim I beg to differ on a few points.

Property sets exist, but are barely usable in Evo and then only for snippets and only for fairly advanced developers. In Revo, they are easily editable in a grid with descriptions, the grid shows which ones override default properties, and they can be attached to any element. In addition, the developer can limit the choice of settings for each property (boolean, drop-down list, or string). That means naive users can change property options with little risk. They also eliminate the whole issue of misspellings, backticks, and incorrect tag format. You can put in a tag like [[SnippetName]] and let users edit the properties to change the behavior of the snippet without touching the tag. Having naive users edit tags can easily result in disaster.

You can easily hide the Package Manager from users who shouldn’t be using it.

In Revolution *any* tag can be cached or uncached, not just snippet tags as in Evo, and the caching is much less quirky than in Evolution.

Finally, I would definitely do a humongous site in Revo due to the ability to use xPDO to integrate, manage, and query custom database tables. Another plus is that none of your code would have to change if you switch to another database platform supported by xPDO.

The point with the caching (using [! !] in the example you posted versus the [[ ]] cached) was aimed at your property set solution.

I may be wrong (haven’t really worked with Evo in ages), but as far as I know when putting anything inside a snippet chunk (so other snippets, chunks or placeholders) you need to make the outer one uncached in order to "trick" the parser to process them both.

To paraphrase that: Evolution works outside in (so only if something is uncached it will fetch what is called cached inside), where as Revolution works inside out (it recursively parses the source to grab the deepest element/resource tag it can find, and in the next round it can use that, and there’s no need to use "tricks" to get inner parts to parse).

Like I said, I may be wrong on that as I’m not sure on the specifics and maybe chunks are excluded from that behavior.


An advantage of the easiness of updating which I didn’t mention, is the fact that addons are getting more attention by end users as they can just click, try and uninstall if it’s not what they need, which means that more people use more different addons which in turn helps the developers iron out bugs and get them up to higher levels.

Of course you can’t compare Revo with Evo addons due to the fact that Revolution has been out only for a year or so, but there’s a lot of great addons that are no longer supported and have indeed not survived an upgrade path. Revolution forces developers to take updates very seriously as it’s so easy to do, and will happen more often. Therefore it’s unlikely (in my belief) that developers will just change naming of properties, without offering backwards support. It can still happen - but because it’s somewhat being taken into consideration from the start I think it’ll cause less problems...


Oh, and I never said property sets were more advanced - just that it would most likely only be used by advanced users who have a number of different uses for one addon, and could use a central place to store configurations.

Websites with 5K resources shouldn’t be the slightest problem for Revo - though it’s often more efficient to use specialized systems for specific purposes. That’s related to the right tool for the right job, and in that way Revolution offers somewhat more flexibility in picking the tool from its toolset. I don’t have practical examples, but I believe Shawn Wilkerson set up a Revo installation with all postal codes in a certain state or something similar as a proof of concept which held about 50.000 resources? Not sure on the details atm.

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

An advantage of the easiness of updating which I didn’t mention, is the fact that addons are getting more attention by end users as they can just click, try and uninstall if it’s not what they need, which means that more people use more different addons which in turn helps the developers iron out bugs and get them up to higher levels.

There’s a corollary to this. Once you build a package for Revolution, you can completely rewrite it, run the build script, and upload the update. It encourages more frequent updates for both bug fixes and enhancements in addition to making it *way* easier for users to do the updates.

The installs and updates are much "smarter" as well. A recent update for SPForm, for example, moves the list of banned users from a file to a chunk. In addition to updating the code, the update script reads the content of the user’s current banlist file, creates the chunk, fills it with the content from the file, saves it, and renames the file to banlist.bak. In addition, the initial install asks the user for a return email address and creates a working contact form on the site. The Captca plugin install checks to make sure that all necessary GD and FreeType functions exist and aborts the install with a message if they don’t.

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.

...but then, this target audience will most likely run into other hurdles using revo, let alone being the audience appreciate the advantage of OOP never felt the need to autoupdate a snippet btw. i feel more in control to do it myself & see what’s going on, or not.

As far as package management, I’ve long had the intention to one-of-these-days dig into the SkinGraft template management module and adapt it to other elements. It handles everything from chunks to TVs required by a template quite nicely and would be well worth expanding to manage other elements. Tabs, I think, for the different elements similar to the Manage Elements page. And creating a "package" isn’t at all complicated; it even has a feature for generating the required files.

Quote from: BobRay at Apr 28, 2011, 06:54 PM

The installs and updates are much "smarter" as well. A recent update for SPForm, for example, moves the list of banned users from a file to a chunk. In addition to updating the code, the update script reads the content of the user’s current banlist file, creates the chunk, fills it with the content from the file, saves it, and renames the file to banlist.bak. In addition, the initial install asks the user for a return email address and creates a working contact form on the site. The Capthca plugin install checks to make sure that all necessary GD and FreeType functions exist and aborts the install with a message if they don’t.

Some Evo extras have install scripts - not many but I think from memory that SMF connector has one.

You could even have a script automatically fetching remote resources, though I can’t think of one that does.

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

The point with the caching (using [! !] in the example you posted versus the [[ ]] cached) was aimed at your property set solution.

Ah - sorry - I see what you were getting at now. I haven’t tested this but offhand it sounds reasonable (and you are touching on one of Evo’s more general weaknesses i.e. the cached/uncached snippet issue). Fair enough, though I doubt many people here have had problems with completely uncached websites anyway (I haven’t - and the largest MODx site I’ve made that I still have access to and hence can count has 786 documents; not the biggest but bigger than the majority).

-- Tim.

You’re right that you can do an install script for Evo, but it’s not much fun and I don’t think anyone has done it twice.

With PackMan, you can create an install script for even a somewhat complex, multi-part, Revo add-on component in less than a minute.

Here’s a good example of the power of xPDO. I mentioned the SPForm upgrade moving the content of the banlist file into a chunk. Here’s the code that does it (minus a few sanity checks):

I still think that a close look at SkinGraft would provide the answer for Evo. I’ve modified the latest available version a bit to fix a couple of bugs when including TVs as part of the template’s auxiliary requirements, and it’s really impressive. Creating an archive is quite painless; I’ve ported a number of templates as SG-ready.

I have it installed on my sottwell.com site; anybody who wants to check it out can ask and I’ll provide a login that allows access to it.

Quote from: BobRay at Apr 29, 2011, 06:41 PM

Here’s a good example of the power of xPDO. I mentioned the SPForm upgrade moving the content of the banlist file into a chunk. Here’s the code that does it (minus a few sanity checks):

<?php
    $chunkObj = $modx->getObject('modChunk', array('name'=>'spfBanlist'));
    $fName = MODX_CORE_PATH . 'components/spform/banlist.inc.php';
    $chunkObj->setContent(file_get_contents($fName));
    $chunkObj->save();

Untested, so treat as semi-PHP and semi psuedo-code, but how about (in Evo):

Edit: corrected code in later post below

-- Tim.

The cruncher is in that getObject function. If you look in core/xpdo/xpdo.class.php you’ll find a maze of functions this one depends on which in turn depend on other functions, not to mention the xPDO::WHATEVER calls.