MODx 0.9.7 alpha (rev 2404)

PHx needs more than a bit of rework to work in 097. It’s not trivial.

I stand corrected... all the more reason not to commit to it for big projects then At least not until Armand has the opportunity to evaluate the work and maybe put this in perspective with the new parsing capabilities of the new rev... could be nice to involve him at some point (if not already done), if relevant (I am by no means able to offer an opinion about that, of course, just thinking out loud).

But that sure raises a second question which is not trivial either : Ditto 2.0 has introduced PHx filters... luckily, you can disable PHx support but you’ll have to take that into account when writing your Ditto calls otherwise you’ll be unable to upgrade to 0.9.7 when the time comes. Sure, this was to be expected given the xPDO jump and parser upgrade

I haven’t followed this very closely, but a cursory reading of some of the related threads made me think that PHx was considered such a useful feature that its functionality is being integrated into the new tags in 0.9.7+. All of the tag styles are changing as well, and Jason is developing a tag conversion utility that will scan content, chunks, and even snippets to replace the old with the new. Given that PHx functionality will exist in future releases and only the method of coding it will change, I expect that a similar conversion process (manual or automatic) may make this less painful than it sounds.

Anyone actually involved in this want to confirm, deny, or clarify my statement?

0.9.7 has modInputFilter and modOutputFilter classes that will do the same as PHx placeholder modifiers, but they will work for all tag elements. I don’t know if the conditionals are supported anyway yet..

Ditto will be fully 0.9.7 compatible by the time we’re in public beta and it will make use of whatever replaces PHx. Now, to find my SVN password so I can check out these latest revisions...

Quote from: doze at Mar 24, 2007, 07:44 AM

I trust that any decision Jason makes is for the best.. although I was really amazed to see Smarty being used in core, another processing layer and syntax.. It would be possible to do 100% MODx own templates with snippets and input/output filters for manager and still be fully customizable, but I understand it would be a lot more work to do.

I appreciate the confidence level, and if everyone recalls I am anything but a Smarty fan myself. However, this just makes sense. Plus, it’s just a generic service extension to MODx, can be used with or without the MODx parser service, and is a perfect fit with the new object-oriented core, for helping produce 100% customizable management interfaces. The performance is almost unchanged, and the skinnable manager templates are simply beautiful (at least compared to what is currently there).

In the future, we could see the MODx management services (the connectors specifically) used in just about any manager theme or external interface imaginable; from QuickEdit, to Eclipse plug-ins, to J2EE portlets, to Flash, to a MODx native tag manager theme. This is because they are 100% isolated from any knowledge of the interface. In our first example, Smarty just happens to be the best solution to get from here to there quickly, and IMHO, will do nothing but help attract an already mature PHP developer community to MODx.

Ultimately, I like flexibility and options, and shipping 0.9.7 with a manager that follows the new core’s MVC philosophies, regardless of which parser or template engine is producing the interface, is nothing but a positive. We get a central layer of management services exploitable from any AJAX interface, isolated in a new context of MODx. All you Smarty haters (it’s ok, I’m a recovering Smarty hater) can continue to use plugins to extend the manager as you do now; the rest of us can start to easily customize our manager markup as needed in the intuitive Smarty templates and customize logic in the very straight-forward and easy to understand controller files.

And though we may or may not implement conditional logic and/or smarty like accessors to PHP variables, control structures (i.e. foreach loops), etc., in the native MODx parser, my preference has historically been to keep it out of the MODx parser. I’ve re-invented several wheels in the past year, so it may sound like the pot calling the kettle black, but Smarty does this already, and does it well. Why not simply add an optional service to MODx to take advantage of those features, to supplement those of native MODx tags? We can still work towards implementing proper native conditional templating in the MODx parser, but in the meantime, we provide an example of how you can easily add your own custom services to MODx and get a manager theme to distribute with 0.9.7 featuring complete separation of content and logic, as it should be. I think when you see the page templates and connectors for yourself, you will understand more why I let Shaun talk me into this.

;)

Quote from: rthrash at Mar 24, 2007, 09:45 AM

PHx needs more than a bit of rework to work in 097. It’s not trivial.

I just haven’t had time to look into refactoring the modInputFilter and modOutputFilter classes which replace phX functionality for 0.9.7. If anyone has some time to invest in this, I’ll be glad to assist, but I have a full plate with everything else going on...

Quote from: sottwell at Mar 24, 2007, 02:54 AM

Just upgraded my site to rev 2461. Manager gave me an error that the function __construct didn’t exist:

Now I don’t know much about Smarty except that I don’t like it, and am sorry to see it being used here. However, I took a look at the included Smarty.class.php, and it doesn’t have a constructor named __construct, but its constructor is named Smarty. So I changed the above to parent::Smarty() and got the manager up OK.

This was just a PHP 4 oversight. Your correction is the proper one and it will be committed today.

Quote from: sottwell at Mar 24, 2007, 02:54 AM

However, the front end is not at all happy...

Warning: ksort() expects parameter 1 to be array, null given in /home/sites/sottwell.com/public_html/core/model/modx/modx.class.php on line 1525
Warning: Invalid argument supplied for foreach() in /home/sites/sottwell.com/public_html/core/model/modx/modx.class.php on line 1526

I’ll pick through the template and fix all the tags, as soon as I can find the documentation for what the tags are supposed to be now; maybe that will even fix the errors at the top.

Ok, did that. Saving a chunk produces the "are you sure you want to leave this document without saving it" dialog, although the chunk is saved. I’ve changed the internal links in the home page, and cleared the site cache, but the original link forms are still there; not sure how since I don’t see any cached files in the cache directory. The page content is changed in the database; closing and reopening it shows the changes.

Wayfinder snippet causes server 500 error even just a plain [[Wayfinder]] call. I turned off friendly URLs and removed the .htaccess file to make sure.

So I’m going back to the earlier rev. This one definitely isn’t working for me.

I’m aware of the problem with saving a chunks; they are also not saving with the data properly escaped, but these are being addressed. Still some work going on in regards to the way the buttons are handled, including these warnings. I’m sure Shaun (splittingred) will have some more commits when he finishes recovering from LASIK surgery.

Again, when migrating from a pre 0.9.7 site, the tags have to be migrated first. And the snippets definitely have to be upgraded, including any included files. This is what the translation utility is for, though I want to try and automate is as much as possible in the upgrade before final release.

Individual component problems on upgrade need to be recorded, so if you can help find out what the specific problems are, it would greatly help us address more of them in the upgrade process.

These issues as we continue developing in the alpha phase are going to pop-up, and is why I release downloadable snapshots of the reasonably stable commits. I certainly don’t want to discourage experimenting with the bleeding edge; I need more help with this for sure, but expect to have to get your hands dirty if you do...

I just back up my "working" site, run the upgrade, and if there’s obvious problems I can’t figure out relatively quickly, I simply restore the backup. I’ll wait a bit, for a few more SVN commits, then give it another try. I think the 500 server errors were from trying to upgrade the Wayfinder snippet, but the cache wasn’t getting refreshed completely. Next time I’ll do it a little differently.

Quote from: OpenGeek at Mar 24, 2007, 01:29 PM

I’m sure Shaun (splittingred) will have some more commits when he finishes recovering from LASIK surgery.

Tell him absolutely not to rub his eyes for a couple weeks. I had LASIK five yeras ago, and I went from legally blind to 20/20 vision in less than a half hour. It was a very freaky experience, but if it’s done right it’s an absolute miracle.

Best of luck, Shaun!

We’ll see how much time I have before my eyes get too tired to see...but here we go. I think Ryan and Jason have said plenty that illustrates well what I could say, but here’s some more follow-up:

I trust that any decision Jason makes is for the best.. although I was really amazed to see Smarty being used in core, another processing layer and syntax.. It would be possible to do 100% MODx own templates with snippets and input/output filters for manager and still be fully customizable, but I understand it would be a lot more work to do.

I totally understand this - the capabilities of MODx’s core are growing day to day, but having worked with the manager code for a bit now...the ability of the parsers do separate code from content successfully with the necessary iterative loops and display processing simply isn’t there. Smarty offers all of that in a light, easy-to-learn package with minimal overhead.

I definitely understand this in light of the public side of MODx - I would definitely not be for Smarty being used in the front-end of MODx processing. However, the backend simply needs a quick, developer-friendly parser to do the complex parsing that is needed for administrative displays. One thing I tend to find most people who don’t like Smarty are those who really haven’t used it in a development environment. Here it is allowing us to completely separate the code from the content and achieve a true MVC development environment for the manager. It was simply the most practical, commonsense way to go - and anyone who’s worked on the manager code can understand how muddled that code was/is before this separation.

Also, the way we’ve built Smarty into MODx allows for this to be replicated easily across multiple parsers, if wanted. If we get MODx’s parser up-to-par enough to do the things Smarty does with the same amount of overhead or less, sure - let’s move back to that. But there’s no sense in reinventing the wheel if it’s already working fine. One not-necessarily-good trend I’ve noticed in my eight years as a web developer in the open source community is for open source developers to feel the need to do everything by themselves - even down to basic, rudimentary tools. I think this is silly - if we have the resources available and free (the very premise of open source communities!), why not use them?

I also want to stress the benefit of ’connectors’, which are new in the latest commits. These allow us to access MODx functionality from anywhere - the public side, the manager side, etc. The whole dynamic nature of it has made me wonder (and feel free to wonder with me and discuss!) whether or not the connectors/ and processors/ directories should even be in the manager/ dir at all - or separate in core/ or somewhere else, since they’re not even really connected (no pun intended) to the manager at all.

Moreso, this system allows us to do true server-side validation (avoiding nasty javascript validation) without the overhead of loading the page over again. The AJAX connectors allow for one to quickly and easily send processing requests via a Javascript class I’ve created called ’FormHandler’. This class sends the form request through an AJAX call and then returns the response in whatever form you choose (all overridable), with the option of JSON. The benefit of this is huge - try going to the Update Chunk page and setting the name to blank. What you’ll notice is now validation in MODx hits a whole new level: the field that is wrong is highlighted red and a message is displayed beside it, all without reloading the page or lots of bloated code. I think once you see this, you’ll convert.


Again, all of this is still in the early phase. If you think you’ve got a better way of doing this - speak up! None of this is set in stone, and I know there’s a lot of improvement to this that could happen (I still shudder at the huge switch statement in manager/index.php and the ghastly $_GET[’a’] number param we all love to hate).

There’s still a lot to do, but I think this will be an awesome core to work with once it’s up. True MVC, anywhere-accessible processors, and clean HTML templating...why not?