Widgets and Plugins

OK... here’s my honest and open assessment of where we stand today. I can build a site in MODx really fast in a bunch of different ways. It’s flexible and pretty robust! It’s certainly different enough and it would see a lot of folks all over the world feel the same way. The ideas that Raymond’s talking about will continue to make it easier for folks like me to build sites on — even faster and more flexible in the (hopefully near) future.

Now it seems that Raymond will be off adding his ideas to his own "internal fork" of MODx while we wait for an OO version of MODx (Tattoo) to come out. For all practical purposes, the things Raymond’s mentioned and sound really cool (but I reserve ultimate judgment until I work with them) seem like they’ll be out there in Raymond’s version. Not a part of the project.

The things that Jason talks about are incredibly cool sounding, but as I’ve said time and time again, I can’t really comment on the implementation until I get my grubby paws on it. Built-in/automatic versioning and more robust handling of internationalization issues make me drool. As does a more easily extensible core architecture where you can remove and replace bits more easily. MODx is certainly great but everyone agrees it can be better!

The recursive parser is a great example of a huge leap in flexibility we could gain, and an area that at least I would call pretty essential to starting to clean up the rest of the code. As is the manager structure as a whole s a massive priority too. Followed concurrently with a general cleanup of the API and event model for more consistency, etc.

And we have a lot of very strong opinions and personalities here. The most prevalent two being Jason and Raymnd when it comes to code as you two are the ones doing the "future work" now albeit going down separate paths it seems. If it’s not OO/Abstracted/Federated/Persistent 100% Jason looks down his nose at it, or at least that’s the way I’m confident folks interpret some posts. Raymond tends to be very self-effacing and a bit inflexible when it comes to trying something you might not be comfortable with (OOP). In the end, it results in a lot of frustration and friction for everyone, and a tremendous amount of uncertainty for the folks on the sideline.

After chatting with Raymond for more than an hour, I think I finally get where the real conflict stems. Raymond’s ultimate goal and desire is to outdo Microsoft by creating a "system that would make developing apps very easy as would ASP.Net". And guess what guys, we’re never going to convince him that Microsoft isn’t the reason the sun shines, and that MS is the ultimate be-all in models to follow. Regardless that that opinion would convince any jury in the world that the man is clearly insane, it’s what he wants to do and where he’s going to go, and we need to RESPECT that. He’s also very slow and methodical in the way he codes and apparently doesn’t like to show the real stuff until it’s done, nor is he one for talking through ideas, rather he likes to go with the flow and code through them: demonstrate vs. discuss.

While that personally tends to drive me crazy, and I like to go 999 miles per hour and make decisions quickly, it’s probably good there’s a bit of the opposite preference here. It also brings up a good point that Adam brought up:

Maybe what we need to do is decide on a core development philosophy that we can all agree on that will govern how we do things.

So, given that, I’d like to start by proposing that we keep it really simple, really civil, and respect everyone’s differences. The next major steps (I propose) we should take (outside of bug fixes) should be to get the recursive parser into the world, and then get the manager revamped. We’ve talked about those two items a lot. When they’re done and happily being enjoyed by the community, we might think about merging some of the things as we’ve discussed all along. Personally, I don’t get how a merger of some things in MODx, which inevitably would lead to a smaller DB structure, would affect an OOP version in Tattoo, but that’s also because I don’t code. And deciding on what resources we have, is not only the original topic of this thread, but also really important to both paths.

And honestly, there is no reason in the world we can’t have a PHP4-targetted MODx where the current base continues to be refined and works more for the "procedurally-oriented" developer, and an enterprise-grade PHP5-only Tattoo, that is abstracted to the nth degree and serves a more "pro-level" audience. It would be nice, however, if the basic DB structure from MODx and Tattoo is built in such a way that the content could be "upgraded" if and when a user chooses.

Can’t we just all get along!

Back on the subject of the core and overall philosophy, let’s discuss what should and should not be in the core, as this is a point of difference in overall philosophy. As a new Joomla convert put it:

I think the philosophy of keeping the core simple and small and robust, and the rest are modules or plug-ins or whatever they are called , is the "right thing" to do. 

Obviously, I completely agree. So in my idealized hopes for where we can take the system, the core would really be pretty slim:

• Recursive Parser
• Event handling system for overriding almost anything
• User authentication (with NO address book like stuff) of a unified user system
• URL re-writing system
• Plugin/module system
• Robust caching system
• Installer/upgrader system
• Debugging mode to show what’s going on (more robust event reporter)
• Tagging
• Versioning
• Internationalization
• Extendable API that’s more consistent currently

Core Modules/Plugins out of the box:

• The Manager itself -- with the ability for a module to install a menu anywhere in the tree
• QuickEdit
• File Manager
• An RTE
• User stats (and probably Slimstats from wettone.com at that)
• Manager audit trail
• Mark’s new drag-and-drop sorting system for menu indexes (maybe even integrated into QE...)
• Better backup system (also copies images and other external files) and supports alias paths for those that want it
• Lots of Widgets/Controls (currently the pop-up list, datagrid, etc.)

Again, keep in mind that this is an idealized view. The point has been brought up about things being in the core vs. in a plugin due to speed concerns. If something’s too slow implemented as a plugin, though, that seems to me that we might need to consider a more efficient plugin system that’s faster and less memory and/or processor intesive.

Implementation details about what goes on the filesystem vs. what goes in a database are also probably candidates for this discussion, but the above points seem more important to me.

What do you guys think?

I update the list slightly to include user stats, manager audit trail (plugins) and a debug mode (core).

He’s also very slow and methodical in the way he codes and apparently doesn’t like to show the real stuff until it’s done, nor is he one for talking through ideas, rather he likes to go with the flow and code through them: demonstrate vs. discuss

Have I not talked through ideas before? Have I not changed my way of doing things to accomodate new thinking before?

Ever since MODx became a fork there has always been a struggle for control of the source. Some wanted it to go this way while others want it to go that way. And if it’s not done their way then it’s plain silly! But yet I’m amazed at how the silly ideas have helped to make popular and easy to use.

I don’t believe anyone has any idea as to the amount of time and research I’ve put into try to make it simplier, extensible and modular. Modular here does not mean adding more layers of complexity.

I do not object to OO designs but I don’t think everything should be OO. But then again what do I know? Java has taken the OO idea to next level and they are doing great, right? Everyone loves there OO structureed designs!

In light of all of this I would like to recommend that the team comes up with a solid and consistent structure. The ideas that I’ve put forward in the past I’ll be releasing as a hack to the QA team. Why a hack? This is because some of these ideas might not make it into the core and I would not want for users to think that they will be.

I’ll will however continue make contributions to the core but will not put forward any new ideas as these will most likely conflict with future designs. The model that I’m going after is not purely OO and has different goals and objectives in mind. The model that I’m going after will be similar in function to ASP.Net, Ruby and SharePoint which will allow the system to be more that just a website content manager.

I’ll also be keeping the name "MODx" since future plans are to rebrand to "Tattoo".

I don’t think anyone has a source-control issues or desires, and I think everyone is taking what’s been posted as a personal attack. It’s not on anyone’s part!

I think all, Jason was asking for is whether or not what Raymond is working on might possibly fit more closely with what he’s been working on with a revised Data Model. Just because the data model might change doesn’t mean the MODx code base has to go Propel/OO to the Nth degree.

(BTW the previous consluion and the next are after a lot of re-reading and offline chatting, and are only my latest interpretation of what teh heck is going on here!)

Likewise, all Raymond is asking for is patience, as he doesn’t really know how it’s going to ultimately be coded until he works through it. He calls it a "hack" because it’s not going to instantly be committed as the new core (but it could all or partially become the core later). It’ll all be committed in his branch: the parallel parser, Manager Template Engine, new stuff in the core, some merged things, new features, etc.

There’s lots of strong opinions and everyone feels their way is the ultimate way. And hopefully we can all wind up smiling somewhere in the middle, and look back and laugh at this ... soon!