Evo or Revo?

Quote from: jchronakis at Nov 02, 2010, 05:49 PM

- The lack of any pre-installed packages. Wayfinder, ditto, TinyMCE or forms are expected to be there (ok, at least by me) and I think it will just frustrate me to have to go through the boring process of installing them for every site.

We did this for a few reasons:
1. It prevents people from thinking those Extras are "part of the MODx core". They’re not, and we want that easily understood.
2. Not everyone wants the same Extras. Removing them removes cruft.
3. They’re ridiculously easy to install. Furthermore, you can use the PackMan Extra to create a Package that has all the Extras in it you want as subpackages. Then it’s a 1-click install of all your Extras.

- The absence of QuickManager. The people who edit the sites, complained quite loudly about it.

QuickManager was developed by the community. The MODx community will have to port it, if it wants it.

- The lack of some ready access policy templates. I can see how powerful the new access control system is, but I would like to be able to quickly assign users or groups a set of permissions for some common tasks e.g. manipulate freely resources without being super users. Some predefined policies would be very helpful here, i spent half a day trying to get rid of the "permission denied" message in manager page.

Good idea, but what would those policy templates be? How would they be implemented? Any suggestions?

- The drop downs on the access policies. A list with everything available and a checkbox in front of it may take more space but allows to build an access policy quickly. Accessing a huge drop down menu is troublesome.

This is already done in 2.0.5: http://splittingred.com/assets/images/policy/

Quote from: splittingred at Nov 03, 2010, 09:46 AM

- The drop downs on the access policies. A list with everything available and a checkbox in front of it may take more space but allows to build an access policy quickly. Accessing a huge drop down menu is troublesome.

This is already done in 2.0.5: http://splittingred.com/assets/images/policy/

Just shoot me.

But seriously . . . nice addition. It appears to make the security permissions system even more complex to explain (though much more convenient and bulletproof) and I hate to see yet another use of the term "template" (though I can’t think of a good alternative).

BobRay:

It’s really just a UI difference; Policies still behave the same way. Policy Templates just let you specify what checkboxes show up when editing a Policy.

This allows editing policies to be much more intuitive and sensible. It also allows us (via PolicyTemplateGroups) to restrict *which* policies show up in dropdowns to add policies, which will help clear up confusion between Admin policies and Object (Resource) policies.

Quote from: splittingred at Nov 03, 2010, 12:04 PM

BobRay:

It’s really just a UI difference; Policies still behave the same way. Policy Templates just let you specify what checkboxes show up when editing a Policy.

This allows editing policies to be much more intuitive and sensible. It also allows us (via PolicyTemplateGroups) to restrict *which* policies show up in dropdowns to add policies, which will help clear up confusion between Admin policies and Object (Resource) policies.

I definitely get it and I see the advantages. It’s just that many different, widely separated, and hard-to-find, sections of the book are now wrong (what else is new ). And I have a new concept to explain.

What about using "Template Type" in the grid rather than "Template Group" ? I think it’s clearer and possibly more accurate. Would it make more sense to have three types: Administrator, Resource Object, and Element Object?

What about using "Template Type" in the grid rather than "Template Group" ? I think it’s clearer and possibly more accurate.

Probably not, since in the future Templates might need to be in more than one Group. Type doesn’t semantically state that.

Would it make more sense to have three types: Administrator, Resource Object, and Element Object?

Maybe. Can you file that at http://bugs.modx.com/ ?

Done. It will help a lot if I can get a quick decision on the change since it will affect the rewrite in a number of places.

BTW, the form looks like hell in IE7 and some fields are obscured, though it still seems to work.



I have a truly horrible internet connection for the rest of the week and IE7 seems to work better with the brain-dead sign-on here.

We’ll be keeping it as Admin/Object for now. Consider that the quick decision.

Quote from: splittingred at Nov 03, 2010, 01:37 PM

We’ll be keeping it as Admin/Object for now. Consider that the quick decision.

Roger. Thanks.

BTW, I think "Admin" is a better name for it than "Administrator" since it’s more of an administration type than an administrator type -- that makes a better parallel to Object. It also downgrades the importance, which I think is appropriate and it avoids the possible confusion with the standard "Administrator" policy and the "Administrator" user group.

Using Revolution can help you run multiple sites easier. It is also simpler and easier when you are alternating cached/uncached snippets.

Evolution is what won me over to Modx, but Revolution is what’s keeping me in the fold.

Evolution has its graces, such as fast-loading manager pages, simple API, and minimal server requirements for installation. But Revolution embodies everything I could want in a content management system: a powerful API, infinitely extensible, client-friendly, and a well thought-out and responsive IDE (contrary to some community opinion ). I’ve deployed about four Revolution sites since it’s public launch. The only customer complaint I’ve encountered so far has been a blank home page, which was fixed by clearing the cache.

At this point I would recommend Revolution for any first-time Modx’ers. Evolution will be maintained, but Revo will only continue to improve.

Mike