We need to look into Git submodules for the plugin repo. Having each plugin as a repo would be cumbersome. Documentation could be generated and committed through jenkins (or anything of that nature really) with the examples easy enough, but I want to ready, aim, fire - not fire, ready, aim so let's take an issue over to github about it.
Github has pages, I have deployed a simple starter page at qcubed.github.com - we need a place to actually run a qcubed installation for examples so being able to deploy to qcu.be is still going to be a requirement, but most of the other systems can be consolidated on github. I would like to see examples go into how to set up basic web apps (like a todo) with qcubed and sort of merge tutorial and example code together... still just a thought right now.
I may also take some time today to convert that buzzouka article into the github wiki, and maybe start migrating some of the tutorials from TRAC and updating those.
I do not know what specifically coined @mikederfler .... Or maybe it means that all @buzzouka materials? There are exactly 8 pdf ... I put an attachment here, just in case ...
Ok just checked the frontcontroller documentation I found. It is about QCodo but can be applied to QCubed. It consists of 8 pdfs. If someone wants it I can
provide them in some way
I too am one that has simply been so busy that I have not been able to work on this, but HAVE been working on and improving QCubed with the intent of merging changes back in to the core soon.
The Github move looks great. Looking forward to helping (I am spekary there, would love to contribute).
Can I suggest that we have some kind of Blog or Recent Announcements off the home page to officially announce the following changes?
The repository has moved to GitHub . You can still get to the old repository , but it is no longer being maintained. Future development will all be at the GitHub site.
All issue tracking has moved to the Github site. Old issues can be viewed , but will not be copied over to Github at this point. Feel free to repost an issue that is important to you there.
This site is currently still the place for various efforts at documentation, including the wiki, API Doc, Examples, Screencasts and Forums. We know that our documentation is kind of a mess, but if you are here and you want to see what QCubed can do, start . If you are ready to get started, you should go to the Examples site, which is really a tutorial that will walk you through how to start QCubed and do some of the big things you might like to do. The nice thing is that once set up, QCubed does a lot for you.
Anything else we might want to include on the home page? I can make the changes.
I know someone wanted to highlight some sites that are actively using QCubed. If anyone wants to reply to this post, I can add a true Examples page with links to public QCubed sites, (though I know most developers use it for inhouse stuff).
I like this thread! Sorry I am late but better late than never. Here my thoughts for what they are worth:
I too have been using QCubed for a long time now in a not so small project (2000+ hours of development on my part) and felt like merging back or just sharing changes is too difficult often, especially if they are extensive and/or dramatic. But to me QCubed is not at all dead, it can't be!
Git seems definitely the way to go and I vote for 3.: Do not transfer any tickets at all. Let people create what they think is important manually!
Also git would allow everyone to cherry pick from anyone the things they like. Just make as much branches for every new or changed feature as possible so its easier to merge stuff selectively.
On github I am "koopa" ( https://github.com/koopa ), feel free to add me vakopian - however due to the nature of git I think it is not really necessary as everyone can clone and make pull requests anyway. But maybe it's a good thing when there are a handful people assigned to the project in the beginning - so I leave the decision up to you :)
Also very awesome work with jqcubed, you are the man! It seems awesome and my vote would definitely be to merge it back into qcubed. Personally I would use all those plugins that are required anyway and it looks like you did a great job so far.
@scottux I totally agree that we should move off of the scatter of systems.
I think we should have a qcubed version of the site and we can indeed deploy the documentation and the examples with jenkins (or anything of that nature really). Bug tracking can be handled in github.
I am very concerned about the state of the documentation for qcubed. The quick-start guide is in desperate need of an overhaul and the current examples, while sufficient enough to get many people including me started, could be expanded upon greatly. The phpdoc documentation on the site is missing quite a bit as well. My question at this point would be do we want to move the docs and examples into a separate repo for development/deployment, and how do we want to tackle it?
I think it could be beneficial to have a docs/examples repo that can be merged into the main repo for packaging a download, but can be maintained and deployed separately. On the other hand, I suppose either answer to this question has its pros and cons. I would be glad to help out in setting up deployments/ working on a new site however we decide to do it. I really think that updating the docs and examples would help encourage developers to take a closer look at this framework. Also, I think it would be good to have an automated system that can update docs and examples and package/deploy for us each time we release an update. Not sure if we already have something like this, but if we do, I would love have a look at it. If not, I would be glad to build it for us.
Edit: Git has a neat feature called "submodules". We could package examples/docs as a submodule, that way it could have a separate bug-tracker and readme, but still be packaged easily enough with the framework.
Added. Yeah it would be nice if we could group projects - each plugin could be a project under a group. That is a downside to Github that we could overcome by having our own private repo, but that would just introduce the overhead of infrastructure maintenance again... nothing is ever simple :)
I used to have complete access to the infrastructure when we were hosting this site. Since it moved to mediatemple, I have not had access to the filesystem. This site is terrible, while it has served to get us this far - I am also convinced it has driven many people away. Github is able to keep the code and issue management and wiki together, leaving just the examples which could easily be deployed through Jenkins. (The CI suggestion is a good idea, we deploy all of our QCubed projects from Jenkins.)
Git is a different from SVN in all the right ways, and github makes it pretty easy to get started with Git. Forks are not traditional forks, they are personal branches that are meant to be merged back if successful. This means we can fork for a feature and if it is awesome we pull it, and if not we just ignore it. jQCubed is a good example, we can choose to merge it back very easily or just leave it as a fork.
I would like to see everyone on github providing comments and suggestions and forking, fixing, and submitting pull requests. This is much easier for a project like this, and it removes the need for maintaining a spam-free forum and bloated drupal installation and separate TRAC installation, and well you know how it's been.
I expect once everyone gets used to the Git model that development will go through the roof, but I have concerns about code being developed to accomplish things that QCubed already does, just lacks documentation about.
Documentation is the biggest hurdle to overcome - I had plans at one point to build pQuery from QCubed with more jQuery-esque API (like $control->On("click", "function_name") and $control->Append($otherControl)) and just stick with the front controller pattern that everyone seems to use and not care about backwards-compatibility. This would reduce the learning curve by providing a familiar interface, but I stopped because I felt that it would be more detrimental to QCubed and I have hope now that people are interested in seeing QCubed move forward and evolve.
@MattinLA
I created /includes/panels and added it to the autoload routine just to separate things like LoginPanel or HeaderPanel. So I have /includes/controller which are the 'pages' and /includes/view as well. This has worked for years. index.php is the only QForm - everything else is a QPanel. There are many different takes on this and I guess I should switch all my projects to using the app_includes folder - but I haven't needed to yet.
@Vakopian,
I'm using version 2.1 for the project I'm working on right now. Now I might have just completely replaced the config.inc file in the includes directory with one from another of my projects that was pre-2.1, but I don't think I would have done that. Usually I just copy and paste database and docroot sections, then modify them accordingly (it saves typing). Still, I will go and try and add that override.
In all my development work, there is nothing I find more frustrating than having to deal with .htaccess files. No matter what I do, I can never seem to get them to work (they always return 500's on me). I'll see what I can do to get this to work.
@MattInLA,
Have you used QCubed after we switched to php based templates (I think in v2.1)? The older versions used to use the QCubed special template language, which did not require set_include_path() to work. The current version of QCubed (and therefore jQCubed as well) uses php templates which require it.
So the error message is probably correct, your server settings are probably not letting you override include paths. You should contact the hosting company to see if they will change these settings.
Well, I cannot say anything about that! That is not how QCubed is designed to work currently. Please open an issue at gitHub. we will try to look into it!
I for myself moved all my created panels and controlls out of the qcubed folder. I used the frontcontroller pattern (I found a quite good documentation
here a long time ago).
So my folder structure looks like this.
application / controllers / user / register.class.php / user / ... / product / select .... /controls / loginPanel ..... /views / user / register.tpl.php qcubed / ...
We override the QApplication::AutoLoad in prepend.inc ~15 lines of code
so we have no problem loading different panels from different forms/controllers and we have about 90-100 controls.
I had some troubles in the same. All i did was to use app_includes and the problem was over. I guess the other way is to specify the template file with absolute path.
For what it's worth I didn't find installation to be all that difficult. The hardest stuff for me involved dealing with QPanels. I just got fed up the other day while trying to put a QPanel in a "shared" folder while keeping the calling controller in a different folder. Just made more sense to have another page entirely. Actually ended up being cleaner that way too.
I am already working on a installer script so that it gets easier to install the framework easily for the beginners. Let's see how that one turns out to be! :)
I think the best thing to add would be more interest. :) I frankly like the platform for 90% of what I would do. The notation isn't quite as nice as you see in other languages, but that's a PHP issue, not a QCubed issue per se.
I would like to make a modest proposal, whether to add GitHub @Vaibhav good tutorials http://www.thetrozone.com/category/qcubed. They are an excellent guides for beginners? It should also be there as well http://trac.qcu.be/projects/qcubed/wiki/Tutorials Wikisource together and organized etc... What do you think?
@jamescmunro
We need to look into Git submodules for the plugin repo. Having each plugin as a repo would be cumbersome. Documentation could be generated and committed through jenkins (or anything of that nature really) with the examples easy enough, but I want to ready, aim, fire - not fire, ready, aim so let's take an issue over to github about it.
Github has pages, I have deployed a simple starter page at qcubed.github.com - we need a place to actually run a qcubed installation for examples so being able to deploy to qcu.be is still going to be a requirement, but most of the other systems can be consolidated on github. I would like to see examples go into how to set up basic web apps (like a todo) with qcubed and sort of merge tutorial and example code together... still just a thought right now.
I may also take some time today to convert that buzzouka article into the github wiki, and maybe start migrating some of the tutorials from TRAC and updating those.
EDIT: Tell me what you think so far:
https://github.com/qcubed/framework/wiki/Front-Controller-Pattern
thanks both :)
@kukrik: Thanks you were faster than me. That's exactly what I got.
I do not know what specifically coined @mikederfler .... Or maybe it means that all @buzzouka materials? There are exactly 8 pdf ... I put an attachment here, just in case ...
@mikederfler please do :)
Ok just checked the frontcontroller documentation I found. It is about QCodo but can be applied to QCubed. It consists of 8 pdfs. If someone wants it I can
provide them in some way
@mikederfler
No one mention that qcubed has no example of MVC with qcubed, nor suggested user project structure with MVC support.
IMHO it is a must. It seems that everyone is reinventing the qcubed MVC wheel.
@sp, I added you as a core contributor to QCubed on github.
@Kon, I added you as a core contributor to QCubed in github.
Yeah that sounds nice :) My site is not a closed one and is based on QCubed!
I too am one that has simply been so busy that I have not been able to work on this, but HAVE been working on and improving QCubed with the intent of merging changes back in to the core soon.
The Github move looks great. Looking forward to helping (I am spekary there, would love to contribute).
Can I suggest that we have some kind of Blog or Recent Announcements off the home page to officially announce the following changes?
Anything else we might want to include on the home page? I can make the changes.
I know someone wanted to highlight some sites that are actively using QCubed. If anyone wants to reply to this post, I can add a true Examples page with links to public QCubed sites, (though I know most developers use it for inhouse stuff).
I like this thread! Sorry I am late but better late than never. Here my thoughts for what they are worth:
I too have been using QCubed for a long time now in a not so small project (2000+ hours of development on my part) and felt like merging back or just sharing changes is too difficult often, especially if they are extensive and/or dramatic. But to me QCubed is not at all dead, it can't be!
Git seems definitely the way to go and I vote for 3.: Do not transfer any tickets at all. Let people create what they think is important manually!
Also git would allow everyone to cherry pick from anyone the things they like. Just make as much branches for every new or changed feature as possible so its easier to merge stuff selectively.
On github I am "koopa" ( https://github.com/koopa ), feel free to add me vakopian - however due to the nature of git I think it is not really necessary as everyone can clone and make pull requests anyway. But maybe it's a good thing when there are a handful people assigned to the project in the beginning - so I leave the decision up to you :)
Also very awesome work with jqcubed, you are the man! It seems awesome and my vote would definitely be to merge it back into qcubed. Personally I would use all those plugins that are required anyway and it looks like you did a great job so far.
Hat tip! :)
@scottux I totally agree that we should move off of the scatter of systems.
I think we should have a qcubed version of the site and we can indeed deploy the documentation and the examples with jenkins (or anything of that nature really). Bug tracking can be handled in github.
I am very concerned about the state of the documentation for qcubed. The quick-start guide is in desperate need of an overhaul and the current examples, while sufficient enough to get many people including me started, could be expanded upon greatly. The phpdoc documentation on the site is missing quite a bit as well. My question at this point would be do we want to move the docs and examples into a separate repo for development/deployment, and how do we want to tackle it?
I think it could be beneficial to have a docs/examples repo that can be merged into the main repo for packaging a download, but can be maintained and deployed separately. On the other hand, I suppose either answer to this question has its pros and cons. I would be glad to help out in setting up deployments/ working on a new site however we decide to do it. I really think that updating the docs and examples would help encourage developers to take a closer look at this framework. Also, I think it would be good to have an automated system that can update docs and examples and package/deploy for us each time we release an update. Not sure if we already have something like this, but if we do, I would love have a look at it. If not, I would be glad to build it for us.
Edit: Git has a neat feature called "submodules". We could package examples/docs as a submodule, that way it could have a separate bug-tracker and readme, but still be packaged easily enough with the framework.
Added. Yeah it would be nice if we could group projects - each plugin could be a project under a group. That is a downside to Github that we could overcome by having our own private repo, but that would just introduce the overhead of infrastructure maintenance again... nothing is ever simple :)
I used to have complete access to the infrastructure when we were hosting this site. Since it moved to mediatemple, I have not had access to the filesystem. This site is terrible, while it has served to get us this far - I am also convinced it has driven many people away. Github is able to keep the code and issue management and wiki together, leaving just the examples which could easily be deployed through Jenkins. (The CI suggestion is a good idea, we deploy all of our QCubed projects from Jenkins.)
Git is a different from SVN in all the right ways, and github makes it pretty easy to get started with Git. Forks are not traditional forks, they are personal branches that are meant to be merged back if successful. This means we can fork for a feature and if it is awesome we pull it, and if not we just ignore it. jQCubed is a good example, we can choose to merge it back very easily or just leave it as a fork.
I would like to see everyone on github providing comments and suggestions and forking, fixing, and submitting pull requests. This is much easier for a project like this, and it removes the need for maintaining a spam-free forum and bloated drupal installation and separate TRAC installation, and well you know how it's been.
I expect once everyone gets used to the Git model that development will go through the roof, but I have concerns about code being developed to accomplish things that QCubed already does, just lacks documentation about.
Documentation is the biggest hurdle to overcome - I had plans at one point to build pQuery from QCubed with more jQuery-esque API (like $control->On("click", "function_name") and $control->Append($otherControl)) and just stick with the front controller pattern that everyone seems to use and not care about backwards-compatibility. This would reduce the learning curve by providing a familiar interface, but I stopped because I felt that it would be more detrimental to QCubed and I have hope now that people are interested in seeing QCubed move forward and evolve.
@MattinLA
I created /includes/panels and added it to the autoload routine just to separate things like LoginPanel or HeaderPanel. So I have /includes/controller which are the 'pages' and /includes/view as well. This has worked for years. index.php is the only QForm - everything else is a QPanel. There are many different takes on this and I guess I should switch all my projects to using the app_includes folder - but I haven't needed to yet.
@Vakopian,
I'm using version 2.1 for the project I'm working on right now. Now I might have just completely replaced the config.inc file in the includes directory with one from another of my projects that was pre-2.1, but I don't think I would have done that. Usually I just copy and paste database and docroot sections, then modify them accordingly (it saves typing). Still, I will go and try and add that override.
In all my development work, there is nothing I find more frustrating than having to deal with .htaccess files. No matter what I do, I can never seem to get them to work (they always return 500's on me). I'll see what I can do to get this to work.
@MattInLA,
Have you used QCubed after we switched to php based templates (I think in v2.1)? The older versions used to use the QCubed special template language, which did not require set_include_path() to work. The current version of QCubed (and therefore jQCubed as well) uses php templates which require it.
So the error message is probably correct, your server settings are probably not letting you override include paths. You should contact the hosting company to see if they will change these settings.
Well, I cannot say anything about that! That is not how QCubed is designed to work currently. Please open an issue at gitHub. we will try to look into it!
I for myself moved all my created panels and controlls out of the qcubed folder. I used the frontcontroller pattern (I found a quite good documentation
here a long time ago).
So my folder structure looks like this.
application / controllers / user / register.class.php/ user / ...
/ product / select
....
/controls / loginPanel
.....
/views / user / register.tpl.php
qcubed / ...
We override the QApplication::AutoLoad in prepend.inc ~15 lines of code
so we have no problem loading different panels from different forms/controllers and we have about 90-100 controls.
I had some troubles in the same. All i did was to use app_includes and the problem was over. I guess the other way is to specify the template file with absolute path.
For what it's worth I didn't find installation to be all that difficult. The hardest stuff for me involved dealing with QPanels. I just got fed up the other day while trying to put a QPanel in a "shared" folder while keeping the calling controller in a different folder. Just made more sense to have another page entirely. Actually ended up being cleaner that way too.
I am already working on a installer script so that it gets easier to install the framework easily for the beginners. Let's see how that one turns out to be! :)
I think the best thing to add would be more interest. :) I frankly like the platform for 90% of what I would do. The notation isn't quite as nice as you see in other languages, but that's a PHP issue, not a QCubed issue per se.