Answered Set default template if parent of parent of parent == 123

I can say several reasons, why ModX should not make core (such things as PostgreSQL/Oracle support, ORM and template system) (and save time for improving business logic of CMS).


First. Look at repositories

1. ModX CMS/CMF
https://github.com/modxcms/revolution 618stars 323forks 7599 commits since Dec 28, 2006

2. Symfony framework
https://github.com/symfony/symfony 8976 stars 3460forks 18591 commits since Jan 4, 2010

3. Laravel framework (as Symfony alternative, for example)
https://github.com/laravel/laravel 12249stars 3998 forks 3944 (+5361 in required core https://github.com/laravel/framework ) commits since Jun 9, 2011

ModX now create core + cms-related business logic. Symfony only core (without any database layout ) but have in 10 times less forks (even with the fact that modx on 3 years older than Symfony).

War is ended for ModX. I think, we all understand, ModX will never create core better than Symfony or Laravel have. And with every year difference will more... With same progress speed ModX as project become outsider in next 5-10 years :-( ... For now ModX is 3rd in Russian CMS rating 2013 http://www.ratingruneta.ru/cms/opensource/

To save market share (community), it's good idea to drop engine. Like Opera. ModX is good as in browser CMF, not as framework. ModX CMF may win (vs Drupal) as CMF, but not vs Symfony or Laravel as framework.

I will never use ModX for projects where I need to use IDE like PyStorm/PyCharm. I will use Django (Python), as framework its much better... PHP-programmers will prefer Symfony/Laravel/Yii/Zend Framework/etc. And there is no ModX in this list...

Second. Time

Why ModX spend time on core?.. Why not take already good (or even best) components and create good CMF/CMS based on this components?.. ModX use ExtJS. And it's good choice. It's the best UI framework on the current planet. Let's choose best ORM and best template engine. Doctrine and Twig are candidates... Drop some part from modx core, lets third-party developers of this components do all dirty job (PostgreSQL, querysets, template inheritance etc.). Save time for creating thing that improve ModX experience. ModX can become good glue between best components + nice CMS business logic with ability to create good CMS without opening any editor, just in browser.

Third. Value propositions

I'm not programmer (even python), I'm manager. I look on world as manager. So what is ModX?.. It's project where we can talk about customer segments and value propositions. ( https://en.wikipedia.org/wiki/Business_Model_Canvas )

Let's ask questions:
Who use ModX, what segments of users?.. Why do they use it?.. What is the killer feature?..

I can answer on that question as I see it. Developers who use ModX are more skilled in programming than Joomla or Wordpress users. They do not like box CMS like Joomla. They need more freedom, custom document types (which is possible in ModX via TVs). But... they use ModX because of it already has database structure and admin. This users prefer balance between configuration and creation, something between box cms and framework.

They use it because of what else?.. They need admin and database structure, no time or knowledge how to create database tables... They have no time or knowledge of how to use IDE... They prefer work in browser (simple, more speed and no need to build anything). They do not use mercurial/git/svn or may be do not know about it.

They upload code to server, develop there via ftp and editor like Sublime Text and next change domain to production.

They love ModX because of ModX give the most of things that CMF can give working only via browser... This users do not compare ModX with bigger frameworks but expects ModX will use them...


===

I use vi (or vim)

I use vim to change configs on server...

As for me I can use PyCharm or PHP Storm, but I do not see on ModX as on such serious system. For serious projects I will use IDE but not with ModX (it gives no benefits for them)...

I know, in ModX I can create custom models... But XML... No-no-no... Just compare with models in Django... https://dpaste.de/W3jQ

and that I despise ExtJS and Smarty

I've never used Smarty seriously but it can inherit templates, ModX templates can't... For end user developers, who use ModX, it's killed feature... About templates system: In Python world I like jinja2 ( http://jinja.pocoo.org/docs/dev/ ) or django templates... Twig developers inspired by this systems... As you can see, http://twig.sensiolabs.org/ , they are pretty similar...

ExtJS is the world leader of user interfaces... Yes, a lot of bugs (Indian code and so on...)... Yes, bad licence... But it's the best system for now... Look at their examples... http://dev.sencha.com/ext/5.0.1/examples/index.html

Also with Sencha Touch (separate but related product) with rewriting only part of code it's easy to release mobile version... (+Phonegap = cross platform mobile applications for free)... Modx for iPads&iPhones with Sencha Touch? Easy!..

You will find nothing but agreement, even from the core developers, that MODX needs more databases, and needs a new framework. However, as far as the philosophy behind MODX itself, aside from the decisions on its inner parts, adding more and more features built-in probably won't get a lot of traction. See, MODX means "MODular, eXtensible", so the concept of having a core product, with lots of APIs and events to allow insertion of custom code easily installed as modules, won't change much.

I see ModX as best glue between best components which work in browser. I do not see good core (may be its not bad but another cores better) but I see good CMF. Opera loses Presto as browser engine but saved browser. And now Opera's engine is much better. ModX as CMS/CMF is not a browser. Layer between core and end product is much more bigger... And it's not just skin as in browser. It's all business logic...

With better core APIs will become much better... For compatibility reasons it's possible to create some wrapper for easily migration...

My personal take on the core and installable modules is that there needs to be more uncoupling of some of the features that are now part of the core, not more hard-coded implementations of currently separate modules. For example, you spoke of Wayfinder, but pdoMenu, part of the pdoTools package, is much better - faster and more flexible. Likewise pdoResources is better than getResources.

I agree with you, when you tell about modules, but this all packages do very-very easy tasks, in every good CMF like Django/Ruby on Rails etc. this functionality included in core via ORM and template engines... So in good systems with core core just we need not such modules as Wayfinder pdoMenu pdoTools Ditto etc..

I understand, ModX not Django but I suggest to look at some good things in Django and get inspired from them...
https://docs.djangoproject.com/en/dev/topics/db/queries/
https://docs.djangoproject.com/en/dev/ref/models/querysets/
https://docs.djangoproject.com/en/dev/ref/templates/builtins/

P.S. Sorry for such big text... May be it's little offtopic and should be moved to another forum about ModX future...

Quote from: sottwell at Oct 05, 2014, 01:18 AM

there needs to be more uncoupling of some of the features that are now part of the core, not more hard-coded implementations of currently separate modules. For example, you spoke of Wayfinder, but pdoMenu, part of the pdoTools package, is much better - faster and more flexible. Likewise pdoResources is better than getResources.

Totally agree here, whilst building what might be considered "core features" into the core might seem like a good idea in one way, but it reduces flexibility and bloats the core with features one might not need or that might get superseded by a developer not in the core team. The emergence of pdoTools and pThumb is a perfect example of that. The fact that MODX isn't an all-in-out straight of the box system is it's beauty. The more that get folded into the core, the more it runs the risk of getting into a Wordpress type mess.

Quote from: absent42 at Oct 05, 2014, 10:31 AM

Quote from: sottwell at Oct 05, 2014, 01:18 AM

there needs to be more uncoupling of some of the features that are now part of the core, not more hard-coded implementations of currently separate modules. For example, you spoke of Wayfinder, but pdoMenu, part of the pdoTools package, is much better - faster and more flexible. Likewise pdoResources is better than getResources.

Totally agree here, whilst building what might be considered "core features" into the core might seem like a good idea in one way, but it reduces flexibility and bloats the core with features one might not need or that might get superseded by a developer not in the core team. The emergence of pdoTools and pThumb is a perfect example of that. The fact that MODX isn't an all-in-out straight of the box system is it's beauty. The more that get folded into the core, the more it runs the risk of getting into a Wordpress type mess.

I do not suggest include such snippets in core as snippets... I suggest take good ORM like that http://laravel.com/docs/4.2/eloquent#insert-update-delete (or Doctrine http://www.doctrine-project.org/) that can use any database user want and give ability to use any operations with data in model fields with database agnostic style (without sql for simple queries at all), with chaining style ( https://en.wikipedia.org/wiki/Method_chaining) support...

So in my opinion modx should not work with such low-level things like database connection, executing sql, etc. I say about replacing xPDO to something more powerful, beautiful and easy, kill xPDO as core to save ModX as CMS/CMF as Opera did with thier Presto engine (https://en.wikipedia.org/wiki/Presto_(layout_engine) ) or as Drupal did in 8 version... It's also possible save xPDO as brand for marketing reasons if needed, remove half and create wrappers for API compatibility reasons and deprecate old APIs...

And developers of this snippets will use it, create more better and better snippets etc...

How i see it now:
- xPOD already outsider and difference will only increase (compared with frameworks like Symfony/Laravel/etc.) and no way to change it, if it was war, xPDO already lost the war
- ModX is good CMS/CMF based on xPDO, ModX - it's one of the top systems (not outsider, of course) but war will much harder after Drupal 8 release, a lot of ModX fans (like me) will migrate to new system...

P.S.
Another example: Ubuntu going to replace their Upstart to systemd (I think, it was hard decision). But what to do if systemd is better?.. (if you interesting about Linux, you can read http://thevarguy.com/ubuntu/021814/canonical-gives-upstart-systemd-ubuntu-linux ) [ed. note: Lord Daedra last edited this post 12 years ago.]

I'm not a big fan of Twig, but you can use it in MODX now: https://www.youtube.com/watch?v=B3taVT6Cx4A.

I'm actually pretty fond of xPDO and find it much more intuitive and easier to learn than Doctrine. It was hoped that independent developers would create xPDO interfaces for other database platforms, and there has been some work on a Postgres driver, with commits as recent as two months ago: https://github.com/the-dunnock/xpdo/tree/pgsql_driver.

I think I lot of your predictions are premature, since the future of MODX is MODX 3. Revolution (and even more so, Evolution), have numerous legacy issues that cripple the core.

TVs, in terms of both architecture and performance, are a horrible solution to the problem of customizing resources, and extending modResource, as currently implemented, is a bandaid solution.

I expect that MODX 3 will have elegant solutions to these problems and add solid dependency injection, a much quicker and easier-to-customize Manager, a simplified and more granular permissions system, and a number of other killer features.

BTW, the number of commits for a project is not necessarily a good metric, A project that has more atomic commits will have more total commits, but isn't necessarily any better.

You are correct, though, that this conversation should be in a separate topic.

[ed. note: BobRay last edited this post 12 years ago.]