Whatever the project name I think that's a great idea, and I for one would love to see QDrupal back to life. I have not used it before, but it was not because of lack of desire. Rather, because QDrupal was not really available for Drupal > 5, and now of course it's not even available for QCubed 2. So if you can manage to migrate it to QCubed 2 as well as Drupal 6 (and hopefully also forward compatible with Drupal 7), it would really be awesome.

-Vartan

Beware, long post follows.

I wrote much of the original code, and have several hacked versions running on some client's servers here and there with both more and less functionality. For example, I greatly extended the module adding all kinds of functions but in the end none of that made it into the official repo.

I'm actually facing a deadline right now in a couple of days to put a project management application I wrote into drupal, so I will need to dust it off again and get it running with drupal 6.17 and qcubed 2.0.1. So there's that.

I have mixed feeling about it though, overall.

On the one hand, it is really handy to have the integration, and they complement each other well (for the most part).

On the other hand are a lot of issues, some related, some not.

First, it's hard to keep up with Drupal changes and Qcubed changes to make the module current. It's also hard to make the module 'easily' installable. This is because there are a number of changes that need to be made to qcubed to make it work, and we can't include a modified version of qcubed with the module due to the restrictive nature of Drupal licensing.

This could be satisfied with some simple scripts, but then it would only likely be easy to install on linux-like environments, so we would be leaving some Windows users behind.

Next there is the issue of the direction of the module. The module actually has a convoluted history in my personal code repositories. At various points, it's actually had a much larger set of functions that never really made it back into the official version. For example, I have a version that has custom drupal content types defined that represent qcodo pages where the actual form code and the templates exists in the database, and there is a provided syntax-highlighting code editor to edit the pages. This was dumped from the official version in preference for the qcodo_link content types where drupal merely points to an existing qcubed page that exists on the FS.

The front controller has also had more functionality in the past, defining drupal paths for every codegen'd item, so you could do (after codegen) something like /admin/qdrupal/front/[object_name]/[edit] for each object.

One reason I haven't been motivated to re-roll many of these features and update the module is that I often get very frustrated by drupal. I feel it kind of sucks you in to this ideal of creating without coding and you end up wasting a TON of time searching for modules and configuring modules and cck and views and then applying patches to get something you could have written in 100 lines of code. You trade coding for configuration, and it isn't clear to me that configuration is quicker or produces better results. Plus then you end up with a page that produces 1300 SQL calls to render and loads 34 stylesheets. All so you didn't have to write a line of code.

That said, one reason people like to use it is that it has the Content Managent stuff out of the box, and it has user auth and roles/permissions ready to go. Most web devs seem loath to re-write user auth/roles/permissions, so it seems a good compromise.

One approach I have been thinking about is to perhaps create a custom drupal install profile that installs drupal and installs configures qcubed in one swoop with install profiles. This is a recent trend in Drupal....making custom drupal packages of core+modules. This would be a custom Qdrupal-Drupal install.

Another approach I fantasize about is just rewriting the core drupal functions _in Qcubed_. This would require two components:

1) Write a proper Qcubed admin interface. The admin pages for Qcubed are lacking, IMO. It's nice that you can codegen from the web and see some drafts, but it really is not very useful, especially when compared to something like Django. Much of this could be made better by spending some time with the codegen templates, and then putting together an index page that is laid out better with links to the various functions. For example, right now we have an index page that has a few links to the drafts and codegen, but none of those pages link back to the index, so it becomes hard to jump around between drafts, codegen, etc. There is no real navigation.
Plus, it is ugly. I have a _lot_ of updated codegen templates that make this better, but it will take some time to get them into core.

2) develop a framework CMS that has simple CM, user/role/permisisons. Also included should be a good URL alias engine, like drupal, and a simple theme engine.

Doing those 2 things would satisfy most of the requirements of using Drupal with Qcubed, IMO.

We occasionally have a client who wants CMS and community features above and beyond what we offer in our product, and we like the idea of being able to tie our existing QCubed app into Drupal, but the work we've had to do to accomplish this ended up being exorbitant, requiring us to re-create every single form in a drupal-friendly manner, and splitting the code-base.

I'm still very much interested in the integration, but am not sure the current module's approach is the best one. And I'm too unfamiliar with Drupal to speculate on a better one.

Cliff,

This was one of the best (and short) critiques of Drupal I've read in a long time, and I fully agree with you.
I also really like you're proposed minimal CMS solution: everybody wants a simple (but hopefully extensible) user authentication/authorization system. But this suggests we should standardize on a convention for Controllers. I was thinking to take some ideas from the blog articles that Shahways Romani published for QCodo a couple of years ago (his blog articles seam to have vanished, but a copy is still available here: http://ap-project.org/Russian/Article/View/22 ). We can rework the directory structures and conventions he proposed to bring them more in-line with the current QCubed structures. Once the basic MVC conventions are setup, it would not be difficult to hook a simple authentication/authorization to it. Your "URL alias engine" idea would also go well with his ideas about SEO.

-Vartan

Vartan, We actually currently use Shahway's approach in our QCubed projects. I have been meaning to update his tutorials for QCubed but have had little time to do so. His tutorials are also available on the Qcodo site Buzzouka MVC.

not a bad article, but I think it makes the common mistake of confusing MVC with a front controller. Qcubed is already MVC, with or without a front controller. I agree that if we go the route of updating the admin interface, a good front controller is essential, but I often find pure front controller interfaces are a bit limiting.

One thing I like about drupal is that their index.php acts as a great front controller, and it has a robust system for URL aliases and laying out all of their content and functions with 'Clean' URLS.

I think it would be very useful to copy that system in Qcubed, and to make a front controller that, by default, maps to all the form drafts (as a start). This would be a function of core Qcubed, instead as a component of the Qdrupal plugin (as it is now). In other words, qcubed/index.php should be a lot more than listing a few links to a codegen page and the plugin page and the form draft page. It should route traffic.

I put the automatic JSON code in core some time ago, so it would also be nice for the front controller to expose the objects as json, so you could do something like /qcubed/models/[object name]/id/json and get a json representation of the object.

Although, truth be told, even that is pretty limiting. I would rather have the codegen generate a rest api automatically for your app that would expose functions so you could do /qcubed/services/rest/?method=Projects.LoadAll

or /qcubed/services/rest/?method=Projects.Load&id=24

This would generate a rest API very similar to the Flikr REST API, which is used as a model by many, many sites..

I think what I should do is create a wiki page to discuss these issues. I would cover things like the reasons for a drupal integration, the problems with it, a few different suggested approaches, discussion of revamping the qcubed 'admin' interface, a bare framework for auth/roles/permissions/acl, and a suggested front controller.

Maybe even some discussion of what a bare bones cms would need, and how that could be integrated into a new qcubed admin interface.

My approach to the Qdrupal module in the past was to make it heavy weight, and include in it all the things I wanted in a qdrupal admin interface with web based editing of codegen settings, web based editing of database settings, and a good front controller (for starts)

Now I think a better approach is to put as much of that stuff in a qcubed admin interface as possible and make the qdrupal module as light as possible.

Cliff - I think the ideas you propose are absolutely sound. I would love to see QCubed go in this direction. Basically, if I was to summarize the plan:
1) Provide support for front controller / clean URL's. Map it to form drafts.
2) Use the codegen as a mechanism for generating simple REST-based web services.

I love both of these ideas. Do you want to take a stab at making a patch to the core that does one of these? It looks like you have many of this stuff already implemented in your prior projects. We, of course, will be right here to help.

Absolutely. It may take me some time though. I'm currently a freelance slave.

Cliff,

Thanks for your input on QDrupal. I found your post to be very useful in getting a better perspective on some of Qdrupal’s past with your authoring contributions as well as your thoughts and insight on how you’d like to see the project move forward within the scope of Qcubed and the development of a sustainable migratory pattern amongst the projects. Your idea about setting up the wiki is great; Count me in as a reader/contributor if you decide to go forward with it.

I’ve been exposed to drupal for several months and from the beginning took the route of understanding custom module development because I knew I would need to work with external schemas (Your segment on trading coding for configuration is right on par). On the current project I’m working on and having made the decision to utilize Qcubed and Drupal, I’m still working through some challenges. My constraints are:
1. Use Drupal for the CMS.
2. Leverage some sort of ORM, code gen’r, and a MVC framework for getting off the ground with UI development.
Qcubed answers #2.

Now that I’ve completed the technology discovery aspect as far as what tools to use, I still face issues with setting up a satisfactory proof of concept so I can establish a baseline for development with these projects.

Can You??

Since you mentioned that you are dusting off Qdrupal (not to mention your significant contribution and knowledge of the project) can you provide me with a zip of any version of Qcubed that works with Drupal 6.1X??? I don’t need anything more than to work with even a stripped down version of Qdrupal that will allow me to code gen the MVC and use the node linker to build links that invoke view rendering in Drupal.

How Can I Avail Myself (How Can I Give Back?)

As I originally stated, I have (now 3) developers who are interested in using Qcubed with Drupal and would like to complete my baseline this week so I can turn them loose. I now have about 130hrs into this and have been dilligent in working toward a usable Qdrupal module.

Obviously, I would also like to see Qdrupal come alive and better than before. I can make a more significant contribution if I can work with a version that will get me off the ground.

Let me know your thoughts.

Sashman

Any movement on this project progressing to the latest version?

I have just found QCubed and would prefer to use the latest version if possible on my Drupal project. If this is not going to happen soon, can I get some feed back on the current QDrupal and the QCubed version that needs to be used with it and how well it works in production?

Sashman, did you ever make any progress on your request? Count me in as supporting this project to be updated and continued with Drupal. I think this is the only missing element to make Drupal a complete solution for any situation.

I wanted to bump this because it is relevant to what we are talking about now in v3.0.0 of QCubed. A trac ticketing system will be made for each issue in discussion.