Well, at this point our purposes diverge. The heavy overhead of OOP (smalltalk, Java, et al) can be justified when the application is to be compiled; the overhead is only incurred during the development process. With a PHP web application, however, that overhead is incurred at every page load (more or less so depending on caching). I'm looking at making MODx as small and quick as possible; in fact I'm calling it MODxLite. As far as I'm concerned, if you'll be wanting classes and objects to extend and all the rest of the OOP goodness, then go with Revo. Yes, the back-end choice of ExtJS may not have been the best (in our opinion), but since Revo is a framework it would be better to write a new back-end for it than to turn Evo into a poor cousin to Revo with a back-end that you like better that Revo's.
With clear, concise, modular core code with plenty of event hooks and a good API library it won't be any more difficult to program snippets, plugins and modules for Evo than it is to program the same for Revo.
-
- 1,098 Posts
I agree with Susan, we shouldn't change what is already working, MODX Evolution Manager is lightning fast, the configuration file is very simple to edit, and to move a website from localhost to a server takes just few minutes (at least for me).
I think we should focus on fixing bugs, adding new features and improving the manager UI.
-
- 222 Posts
But someone has to work on the JavaScript library. On one hand, it is giving a new text editor, that uses a different library than the current one. On the other hand it is don't change the back-end.
The current back-end is done with MooTools in an old version. I'm not willing to scope with MooTools in my spare time. If you have a look to the speed, jQuery is much faster. There are more components available for jQuery, with UI you have a bunch of themes available, you can change the theme on the fly. I don't want to create a complete new back-end, I want to make better and faster.
Even now Evo works with objects, it is not new. User don't get in contact with the objects, but if you write a Snippet, you are in contact with objects right now, even the document is an object. Have you read what you have to do, to run Evo on PHP 5.4? Is this user friendly?
There will be a time, when older PHP then 5.4 isn't maintained and then there you are with two choices: Changing PHP configurations, .or keep on going with security risks.
XML is user readable, to change the configuration will be is as easy, as in the current configuration, it is just replacing text between brackets.
Gone away and found a better place to stay
Definitely want to change to JQuery.
I know Evo has objects now. I would just much prefer to keep it to a minimum, and as simple as possible. I don't have to like it, but I'm not fanatical about that.
What about native php ini-style files?
http://php.net/manual/en/function.parse-ini-file.php
The only serious changes to the back-end I've been considering is rewriting the action and processor files to collect the forms being generated into a variable instead of inline PHP, thus allowing plugins to manipulate the files instead of needing browser DOM manipulation like managermanager. Also to change the raw mysql functions to either a unified API or to PDO. Common queries like determining a user's permissions vis-a-vis a given resource and action can be made into prepared statements and stored procedures if PDO is used
http://php.net/manual/en/pdo.prepared-statements.php Using these as much as possible would greatly improve security, at a (hopefully) reasonable cost in overhead.
[ed. note: sottwell last edited this post 12 years, 1 month ago.]
If we're serious about this we need to start talking about organization and group dynamics. We can't just all flail around with each person doing whatever strikes their fancy at the moment, nor can we get into a state of quarreling factions flaming each other (which is pretty much what happened to the original Etomite project, leading to the fork of MODx).
Then some hard decisions need to be made as far as the actual coding goes.
To begin with, where will the main branch be? Who will be responsible for approving any changes and generating an installation zip download?
Do we use PDO or some other DBAPI library?
What documentation method shall we use?
I'd like to know this ASAP, as I'd like to begin work on rewriting the "action" pages.
Well, I've started... the first "action" file is completely re-written to gather up the whole thing into a variable ($output) and to use the modx DBAPI instead of directly using PHP's mysql_whatever database functions. Of course, this particular form (manager permissions, access_permissions.dynamic.php) doesn't have any events, but it's a beginning.
☆ A M B ☆
☆ A M B ☆
