Qcodo module

Hi,

I’ve started work on integrating Qcodo with ModX. For those who are not familiar with Qcodo it is a stateful PHP framework using code generation.

It has some pretty cool features and I’m thinking of using it for a project I’m currently developing.

At first I was tempted to use Templates and TVs for storing content but since it’s not possible to easily integrate new Object types with the context menus of ModX or change the tree navigation structure to use relations I decided to go with a module. Nonetheless I’ll use ModX’s database for storing custom tables.

I’m only in the beginning but I added a ModXDatabase class to Qcodo in order to reuse the existing MySQL connection.

I also had to solve a few E_NOTICEs in ModX’s code since Qcodo uses its own error handling and complains about these.

Having the ModX module include the index of my Qcodo app required a couples of changes in the generated code in order to solve the includes. I’ll try to see it its possible to change the template for this code.

I’ll post my work here as soon as possible, I’ll just try to tidy it up a bit and get code generation working before that.

If you’re interested in this or have done similar work please post your findings/requests.

See ya...

Very interesting. Just a bit of info though; I considered Qcodo when starting the rewrite of MODx from scratch, which has been going on for the past year. However, after trying Qcodo and a host of other frameworks from the pool of hundreds that exist for PHP, they all seemed rather, well, limiting, and very programmer-oriented. In particular, the major issue with Qcodo is that it only works with PHP 5. I instead chose to re-author MODx as a completely object-oriented MVC-based framework on top of another tool I authored, called xPDO, which basically does what Qcodo does, though Qcodo is obviously a little more mature and chose some different approaches. I do like their form stuff, but the PHP 5 limitation made me turn away for now.

So, again, this is just FYI and not meant to discourage your integration efforts. In fact I’m still very curious what you come up with working with MODx and Qcodo. But I just wanted to mention my experiences and the current rewrite, which is probably 80% completed on top of xPDO already, which will be addressing many other the things you might be looking for Qcodo to bring to the table.

Hi,

I’m very interested in having a look at your rewrite as I’ve also read about it when I posted about my choice to use the template and tvs for storing custom content.

Do you have any code available ?

I liked Qcodo for its stateful forms and simplified Ajax development. Prado (i think that’s what it’s called) also seemed pretty cool but I didn’t find the AJAX simplicity seen in Qcodo.

Your framework used a typical MVC approach ? I’m just trying the stateful approach seen in some newer frameworks like JBoss’s SEAM (conversation state). I’ll have a closer look at your project’s site tomorrow.

Thanks for your input

Quote from: MaDrense at Nov 20, 2006, 05:55 PM

Do you have any code available ?

The foundation of the new code is available as xPDO at http://xpdo.org/. Though I’m sure there is a lot of sugar coating to add to this, I’m using this persistence framework for some custom database-drive web application within several production MODx sites, and am very happy with the results so far. I am also working with some other core MODx developers to build their own xPDO projects in order to get used to the new framework, resulting API style, and help add more features. In the meantime, there are some poorly styled API docs at http://xpdo.org/api/ and the code is available from SVN at http://svn1.cvsdude.com/rethrash/xpdo, but otherwise, their is a lot of documentation work to do.

The rest of the new MODx core was written by extending xPDO core classes, and generating classes using xPDO (over-simplified maybe, but that is the basic approach). I’m doing some rigorous testing and finishing up a few more key features, then I’ll have a public preview soon after 0.9.5 final is out.

Quote from: MaDrense at Nov 20, 2006, 05:55 PM

I liked Qcodo for its stateful forms and simplified Ajax development. Prado (i think that’s what it’s called) also seemed pretty cool but I didn’t find the AJAX simplicity seen in Qcodo.

Your framework used a typical MVC approach ? I’m just trying the stateful approach seen in some newer frameworks like JBoss’s SEAM (conversation state). I’ll have a closer look at your project’s site tomorrow.

I wouldn’t call it typical, as it is a marraige of patterns I identified from MODx as it is today with some adaptations of traditional MVC and other important design patterns. And now that you’ve exposed me to SEAM (man I need to get my head out of the PHP world once in a while and see what’s going on ), some of these concepts are exactly what I needed to describe what I’m implementing. I am currently calling my version of "stateful contexts" a "message registry" with different registers providing the storage for different message "contexts". Very cool stuff indeed...thanks so much for your post; I have to go add a couple of things to my framework now!

Hi,

I’ll checkout your code from SVN and have a look at it.

Nonetheless, I see that xPDO is a ORB (or ORM) but how about the MVC framework you were talking about ?
I’ll try to see how the data is stored in the DB. I started an approach similar to this one a couple of months ago using RoR but since I had little time for it I had to quit.

Is MODX going to use this approach in future releases ? I’d especially like to have all objects stored like this and having Document, etc, as one of the core objects but allowing one to extend it with good integrating with the manager interface. That’s to say, I’d like to be able to have a "New Document", "New blog entry", etc ... in the right mouse button menu.

The hierarchy navigation would also have to be extended to allow for easy navigation between relations.

I really think this will be a great project! And I’d like to jump on the wagon but I have a couple of projects starting and have to decide whether to use Qcodo for module development or relying on xPDO and assuming it will be used in MODX’s core. The former provides me an interesting stateful approach with AJAX support.

If you’re trying to replicate behaviour seen in JBoss SEAM’s you’ll have a great framework for development I first learned about stateful frameworks by looking at Seaside (done in Smalltalk) which is probably another good reference for you! Just look at Dabble!

Well, I just lost the purpose of this post Just wanted to get some discussion going about this as I’m very interested in these newer approaches to Web development. I’m kind of tired of having to rely on a fixed database structure and always having to worry about mainting state information in Web applications ...

http://svn1.cvsdude.com/rethrash/tattoo/tattoo/branches/opengeek/trunk

This is closed ?! No anoymous checkout ? I’d just like to see how it is going and see if it’s usable as it is.

Quote from: MaDrense at Nov 21, 2006, 08:45 AM

Nonetheless, I see that xPDO is a ORB (or ORM) but how about the MVC framework you were talking about ?
I’ll try to see how the data is stored in the DB. I started an approach similar to this one a couple of months ago using RoR but since I had little time for it I had to quit.

Right, the MVC portion of the framework will be implemented on top of the ORB.

Quote from: MaDrense at Nov 21, 2006, 08:45 AM

Is MODX going to use this approach in future releases ? I’d especially like to have all objects stored like this and having Document, etc, as one of the core objects but allowing one to extend it with good integrating with the manager interface. That’s to say, I’d like to be able to have a "New Document", "New blog entry", etc ... in the right mouse button menu.

Exactly how it’s been done. modDocument, modWebLink, modAjaxService, modSOAPService, modBlogDocument, whatever you can imagine... they will all extend the base modResource class, which basically represents a mini application controller. In addition, multiple front controllers will be possible with the new core (i.e. multiple entry points to modx).

Quote from: MaDrense at Nov 21, 2006, 08:45 AM

The hierarchy navigation would also have to be extended to allow for easy navigation between relations.

I plan on developing a UI for xPDO that will rival the visual custom data modeling tools available in TurboGears (a popular Python framework comparable to RoR). I want to eventually make it easy for non-developers to prototype custom data models for their web-applications through this approach.

Quote from: MaDrense at Nov 21, 2006, 08:45 AM

I really think this will be a great project! And I’d like to jump on the wagon but I have a couple of projects starting and have to decide whether to use Qcodo for module development or relying on xPDO and assuming it will be used in MODX’s core. The former provides me an interesting stateful approach with AJAX support.

Understood; picking the right tool for the job is all about what’s available and works now. The implementation of our internal Ajax support featuring direct to JSON object caching (in the xPDO layer) and flexible state management via my modRegistry concept is still being worked on (and now possibly refactored a little based on my discovery and research into SEAM).

Quote from: MaDrense at Nov 21, 2006, 08:45 AM

If you’re trying to replicate behaviour seen in JBoss SEAM’s you’ll have a great framework for development I first learned about stateful frameworks by looking at Seaside (done in Smalltalk) which is probably another good reference for you! Just look at Dabble!

Well, I just lost the purpose of this post Just wanted to get some discussion going about this as I’m very interested in these newer approaches to Web development. I’m kind of tired of having to rely on a fixed database structure and always having to worry about mainting state information in Web applications ...

I’m not going to try and replicate SEAM; MODx is PHP, JBoss is Java. It’s just very validating to see JBoss taking similar approaches to addressing these issues.

Quote from: MaDrense at Nov 21, 2006, 09:06 AM

http://svn1.cvsdude.com/rethrash/tattoo/tattoo/branches/opengeek/trunk

This is closed ?! No anoymous checkout ? I’d just like to see how it is going and see if it’s usable as it is.

Yes it is and I have very important reasons for not yet sharing this code outside of the development team. But it will be available in a preview (alpha or beta) form very shortly after 0.9.5 is released. If you absolutely have to have a peek before that, contact me via PM to discuss arrangements.

Got to say I’m impressed. I’m familiar with Django and Turbogears. Django’s admin interface is pretty cool. Tubogears Catwalk is new but promising. the visual modeling seen in TG is a good approach, glad to see you’re collecting ideas from some of the projects I’ve also looked at

I extended Rail’s Streamlined with the filters seen in Django’s admin I hope you can come up with an admin interface with the features seen in Django’s added with the modeling features seen in TG

The stateful approach is a big plus. How about templates ?! I think you should try to use HTML based templates like those seen in PRADO or in Zope/Plone.

The source code in your branch is already available via WebSVN, so anyone with some time or scripting abilities can download it. It would just make it easier if anonymous checkout was available. I understand your reasons for not allowing this so how can I get in touch with you to try your MODX rewrite ?

Is this a one man project ?! Seems to me you still have some tought challenges and decisions ahead it would be great if more ModX/PHP developers joined your "quest for the holy grail"

Congrats on the work done so far. Glad to see you’re open to suggestions and able to analyse frameworks disregarding the language used, I’m kind of tired of the Rails vs CakePHP vs etc .. flame wars in some forums.

Quote from: MaDrense at Nov 21, 2006, 11:37 AM

How about templates ?! I think you should try to use HTML based templates like those seen in PRADO or in Zope/Plone.

Honestly, I’ve considered this for a long time, and my solution is to simplify everything into the Resources I mentioned, which are constructed from Elements. These elements can consist of any source content, and can be processed in any way you want to produce the output that is returned into the Resource. This leaves the door wide-open for whatever templating approach you want to take. That way, you can stick with the traditional MODx templates or implement your own Element classes to handle it the way you want.

Quote from: MaDrense at Nov 21, 2006, 11:37 AM

The source code in your branch is already available via WebSVN, so anyone with some time or scripting abilities can download it. It would just make it easier if anonymous checkout was available. I understand your reasons for not allowing this so how can I get in touch with you to try your MODX rewrite ?

Crap, that’s lovely! Oh well...the main reason I have not opened this up is simply because I’m making some changes to the SVN structure for the project and want to work that out before I open it up. Just private message me through the forums here and I’ll get you a full copy you can install and test later today or tomorrow.

Quote from: MaDrense at Nov 21, 2006, 11:37 AM

Is this a one man project ?! Seems to me you still have some tough challenges and decisions ahead it would be great if more ModX/PHP developers joined your "quest for the holy grail"

Congrats on the work done so far. Glad to see you’re open to suggestions and able to analyse frameworks disregarding the language used, I’m kind of tired of the Rails vs CakePHP vs etc .. flame wars in some forums.

It has been pretty much a one man show up to this point, yes. But I am certainly ready for collaboration from other developers interested in this, and have been spending the last week getting a few of the MODx team members using xPDO in order to become familiar with it’s inner workings. Once I have a few more avid users and contributors, I think we’ll be able to complete some more documentation and get an official release of xPDO out, while I prepare to shift the rest of the team’s attention to the new MODx code and related efforts.

Thanks for the appreciation; a little validation of my ideas and approaches goes a long way. My goal with this rewrite has been to be able to take advantage of the latest and greatest PHP features without excluding our existing user base, and to centralize data access and business logic without sacrificing performance or the ability to optimize the code to a specific platform or environment.

BTW, I actually implemented my prototype rewrite about a year ago in Propel/Creole and was not happy with the resulting performance and code size. That’s what motivated my development of xPDO.