Registration link while browsing the forums: fixed. Thanks!

Links on the forum_drafts.php: added an explanation that should help.

QSoapService example: fixed. Thanks!

On architectural changes: we understand how important it is to stay backward-compatible, and require as little work as possible for upgrades.

Unfortunately, the directory structure that QCodo had - and QCubed 1.0 has - is not conducive to security, maintainability, and any kind of plugin system. We had to redesign it. You probably already saw the results. We are very much committed to the new structure, and have no plans on changing it in the future (after 1.1 is released, of course - for now, it's still in a little bit of a flux).

The largest change coming in 1.1 will be the plugin ecosystem. You can read about it in detail here. The main goal is to keep the QCubed core lean, while creating a powerful platform for the community to have their own extensions. We are shooting for one-click install/uninstall experiences, and we're well on our way towards that goal. If you get the latest QCubed 1.1 bits from the SVN today, you'll be able to play with what we have so far.

It sounds like a very cool project, and we're in very close to the same situation at our company, with the same kinds of clients, installation setups, and customization needs, so I'm excited to hear any progress you have made in these areas, and would be happy to share any insights I have as well. :)

I'd be especially interested in the approaches you come up with for multi-lingual support and skins, since the .po approach is sorely lacking when needing to translate user-provided strings.

If you want help designing systems to solve these limitations or add these features, we (or at the very least, I) would be flattered if you would create forum posts to discuss the various issues, and accept the communities input in exchange for revealing the final solution (in concept, if not in code). :)

I'm also interested in multi-lingual support!!

Especially German Kommas: , instead of english komma .

I have o QI18NFloatBox flying around here. I'm pretty sure it have some rough edges, but i works pretty well in two of our projects.

If there is any interest, i'm more than willing to share. I have no clear idea what would be the best way so. Any suggestions from the gurus?

fcool, would you be willing to share your QI18NFloatBox as a plugin for v1.1? The infrastructure for plugins is already there, and so is the documentation.

Yeah! I was eager to try out the new plugin-interface anyway. So i will have a try. I'm a bit busy now, but expect something at the beginning of the next week.

Well done alex!

I must say that the uneeded change of the path of configuration.inc.php and prepend.inc.php prevents me to update my project. Who decided that? Plus, the change from qcodo to qcubed... etc is a pain in the ...

I will continue to use an old update of the 1.1. In the future probably I will avoid to use Qcubed or I will continue with my version.

rtacconi,

First of all, I'd encourage you to be a bit more constructive in your feedback. "unneeded change" and "who decided that" is somewhat disrespectful - you don't want to come across that way in a community where you've been helped multiple times. I'd instead encourage you to just ask why this change was implemented.

The reasoning here is to allow for easy upgrade-ability from v1.1 to v1.2. We want to make it as easy as "replace this core folder with that one"; with the old qcodo structure, it was impossible. With the new structure, it's absolutely easy. The core contributors group has been working on that change for a long time, and lots of people have provided feedback: http://trac.qcu.be/projects/qcubed/wiki/Qcubed%201.1%20Proposed%20Direct....

If you have concrete recommendations, please do share them.

I have to ask, since it seems like "moving" prepend.inc.php is such an issue in your project, would keeping a prepend.inc.php in /includes that simply includes the one in the new location be an acceptable workaround for you? If not, why not?

We want to ensure we address upgradability concerns such as yours, so any feedback you can provide would be appreciated.

My concrete recommendation is to put back prepend.inc.php. I still belive that there is not any reason to move it.

I cannot use the framework with your changes. I hope that in the future I will be able to do that.

Please be more explicit. What about the new directory structure is providing difficulties in the transition? What benefit does prepend.inc.php have in /includes rather than in /includes/configuration?

Sorry guys, probably I need a rest and relax a little bit, forgive me.

Any file, in my project, has the framework included, so prepend.inc.php.Since I have many files I have to change any one by hand (I have a lot of files!).

Second you can update everything in the framework having prepend.inc.php in includes file.

Third, I have written custom code that uses __QCODO__ constant. So for backward compatibility we should have even the old __QCODO__ variables (well it is not a big issue).

Fourth, I think that Qcodo is based on the needs of Mike Ho, Qcubed on more than one person, but probably nothing more than 6.

Fifth, while I am learming new thinks, reading articles in architectures and new thrends, I see that the way of Qcubed is the old way of developing web app. No DDD, no tests, no orientation the business requirements.

Sixth, today I had written the solution to have a QQ::Like case insensitive even for Oracle, but I have deleted everything because I know that cannot work without have Oracle in the core; but Oracle should be a plugin, since the core contributor said that.

Seventh, I do not like how the QPlugin has been developed but I will not go into the details since I won't use it.

Eight, no clear agreement to write the documentation.

Sorry for what I said, but it is what I think. I have found in Qcodo a great help and a chance to improve myself. But since I am evolving and getting new information, I see that this community has different ideas from me and from what is going on now around us (see Fowler, infoq, Ruby on Rails, Grails, other frameworks). I see that this framework has started to blocking me instead of helping me to what I want to do. So I think that is the time to modify the framework for my needs.

rtacconi - you have had multiple chances to influence where the framework is going. We've continuously asked for feedback on the directory structure and plugin ecosystem (http://qcu.be/content/qcubed-11-plugin-and-directory-structure-plans-com...).

QCubed is a framework that's designed by TEN core contributors. We very much welcome community feedback - there are numerous companies using QCubed to build their business on today. Our main goal is to do things that the entire community finds useful; moreover, since this is an open source project, we tend to work on things that matter for our own businesses.

We have several core principles, one of which is "lean core and excellent extensibility", which is why the plugins system is in place. We have a goal to create an easily maintainable, upgradeable platform - which is why we have performed the serious directory modifications in QCubed 1.1. I definitely agree that migrating EXISTING applications into QCubed 1.1 is a pain today - but note that 1.1 is not out yet. If you want to play with it, use it for your new applications. For things that are already in production, stick with 1.0.

Your comment on "no agreement to write documentation" is simply false. Core contributors have written at least ten examples since the project started, and documented a number of classes through PHPDoc.

We encourage community contributions - and we welcome you to the community - but only if you are willing to be respectful. If the tone of your messages continues to be destructive and offensive - like the last two have been - I'm certain the the flow of good will towards you will stop.

The goal of QCubed is to be community-driven. Right now there are about 6 vocal members of the community, yes. But should you voice your concerns, suggestions, and improvements, I fully expect the rest of us to embrace them as well.

We want what's best for the framework. Some of that is going to be ensuring that the framework is capable of handling the jobs that we personally need it to fill. The hope is that everyone will voice their own job's requirements so that we can create a framework that accomplishes them _all_.

So my biggest recommendation for you is to speak up. We're not trying to drive the framework in a specific direction, and if there's a reason you don't want it to go a way we are proposing, we're willing to listen and work with you to try and accommodate what you need and hopefully improve the framework in the process.

That said, I'll try and address your concerns in a point-by-point manner as well:
1) Yes, updating existing files to point to the new prepend.inc.php sucks. I think the reason it was placed in configuration was more for organizational purposes, and we may be willing to re-evaluate that. Even if we decide the best approach is for it to stay in configuration though, is there a downside to having a secondary prepend.inc.php that lives in /includes, just so your old code can still find it?

3) I agree this sucks, but I think it's necessary to ensure a clean break from QCodo. Hopefully this is a one time global search/replace on your codebase, and not a major time sink.

4) QCubed is driven by the community. By lack of any other way to do it, this is restricted to the _vocal_ community. If you want to help drive direction, please speak up when you are concerned. The more detailed and complete reasons and descriptions you can give, the better the rest of the community can be convinced to do things your way. We're not trying to be unreasonable or ignore useful feedback. If you get active enough, we'll probably even invite you to become a core contributer.

5) We mostly don't see the benefit of DDD. That said, the plugin framework should be flexible enough to allow that to be added separate from the core. If it's not, please let us know where it falls down so that we can improve the plugin framework.

I know that Mike Hostetler was working on getting a full test bed out for QCubed, and that _is_ one of the few things on our roadmap, so we definitely want to get there.

I'm not sure what you mean by not oriented around business requirements. I'm unsure how a framework could be. That's your application code's job. QCubed does provide an easy place for business logic though, in the data objects and meta control code.

6) Agreed, QQ isn't flexible enough. If you have a suggestion on how to make QQ::Like DB agnostic, please post it in the ticket system (http://trac.qcu.be/projects/qcubed/ticket/278 may be appropriate).

7) Please do go into the details. There has been significant work done, and it would be a shame to throw it away, but if there is a better approach, we'd really like to find it _before_ 1.1 is released.

8) There's no "agreement" to write the documentation, because anyone that wants to can. One of the reasons it's so slow is that the community (primarily the core contributers) aren't reviewing ticket code as quickly as desired. If we had more people like you willing and able to QA it, people like fcool would be putting out documentation faster to keep up.

Again, we would love to hear about any suggestions, or even complaints you have, but for us to be able to do anything about them, we'll need more details.

My last post: I will anwser to point 5 only: if you do not find the benefith of DDD, you just not understand what's going on and you do not understand what will happen in the future.

If you think that you simple plugin system might be useful, or you do not understand or you are trying to avoid the reality.

For me Qcubed is dead.

If wish you all the best, I think you are good guys.

Alex, I do not wnat to be offensive, this is what I just think. From your list of companies I will remove one, the one I am working for, a FTSE 100 company, one in the top 100 in the UK. For me you are history.

I'm sad to see you going. You have made an extremly usefull (and in my opinion more than necessary to open up for newcomers) job with the start of the documentation!
http://trac.qcu.be/projects/qcubed/wiki/wiki%3AQCubed%20Manual

I always wanted to give qualified feedback and involve myself, but probably you know how unceratain ones workload can change; bad to hear you are that upset with QCubed; i do not understand exactly how that could happen so suddenly. I love it to see QCubed - Development speed up. That 1.1 will break the compatibility with old folder structures is perfectly ok for me. You have to make a break if you want to have a clear structure in the future. I don't have the feeling not to be listened to in this community; i do not find to go deeply in all planned features either. So you have to decide whats more important for you. QCubed makes my (and our) programming much more sophisticated than ever before.

Adressing DDD:
I used QCubed to do a kind of DDD as nobody realy spoke about: After all you create your data model first. If you want, you can make a domain model before your entity model. Your entitiy model becomes your code generated data model. The Business - Logic can reside in the deriven data-classes or Aggregates self written dataclasses. The forms don't need to carry that many code. I think QCubed (formely QCodo) supports separation of Business Logic and a lightweight DDD perfectly don't making a buzz of it.

You can stick to the principles of techniques, just because they are good practise, without even having a name for it or knowing what you exactly doing.

That said: If you really leave, we sill surely miss you (at least do I! and future users searching for documentation)!

to say qcubed is dead is pretty offensive to the large bunch of people that have done so much great/hard work! It's about as alive as it's ever been if you ask me.

With regards to 1.1 breaking backwards compatibility...by all means! Go ahead and break it. It's silly to upgrade old production systems to 1.1 - but for new systems from scratch, backwards compat is no issue.

Rtacconi,

I will reply to you using a Linus Torvals quote: "Talk is cheap. Show me the code."

If you feel unconfortable with some decitions in the QCubed core please let us know how you would do it and code it please. If your code is good it will surely be integrated in the core.

If you feel unconfortable with QCubed to a point that you can't even try it. Well, it's time to switch or create your branch (You have to code this time again :) ). I'm pretty sure that most of us will take a look at your progress if you create an open source fork or branch.

Saying "Qcubed is dead" is offensive and we don't really care if the best company in the world is using the framework or not. We try to do our best in what we can.

Cheers,

Marcos

Rtacconi,

I too am sad to see you go. The QCubed community was birthed out of a vision to create a more open and inclusive group of developers who cared about Qcodo, now QCubed.

However, the authenticity and health of a community can be easily poisoned by negativity. I won't repeat what others have said above about soliciting feedback. The proof is there.

The only additional point I will make is that this community has been built on "action", not "words". We've all experienced enough talk, and it took the courageous leadership of a few core contributors to stand up and make the change. We've experienced steady growth since then, and this proves that we're on the right track. Can improvements be made? Yes, and we are open to hearing about them.

So, we are sad to see you go. Negativity doesn't have a place in our community and trolls won't be tolerated. You're always welcome, if you can positively contribute.

Since I am the API docs guy, I want to respond here as well.

Between myself, a LOT of work from fcool, and others, the API docs are coming along. Yes, it is much slower than most people would like, but it must be remembered that we are volunteers. I happened to have been caught up in my job, but I assure you that I am still reviewing code.

Right now there are only three API doc tickets open. I am reviewing QControlBase right now and that should be done shortly. After I finish that and compile the documents, it is my goal to release what we have so people can see the new information and also see what is lacking and hopefully help out.

So Rtacconi, I am am sorry that you find some things to be lacking. But as has been said, there are MANY ways for you to contribute and effect change. Supplying docblocks to the source is just one way (thanks fcool!).

On a side note - DDD: To me, this is just ONE way of doing something. Just because something is new does not mean it is the best way to do something. If a framework decides to embrace every new idea that comes along, it will never develop cohesion; it needs to stick to an idea. We are trying to develop a strong stable platform and it seems that the majority of people do not need DDD as part of it. We liked the predecessor, QCodo, and seek to improve upon that.

On the side note of DDD - Domain Driven Design,

I have to say after 23 years in IT this seems to me to be just another way for large consultancies to pocket more dosh.

Though I do do love playing around with the concepts and drawing nice architecture diagrams and giving powerpoint presentations (Visio is my fave!).

I personally think that solutions should be technology specific especially if it is something as practical and useful as php.

So I don't talk domain model, when I can talk Oracle Database Design and I don't talk domain logic when I can talk rapid development with Qcubed, and so forth.

Also I know from my experience that most companies are so dymamic and fast moving these days that Data Models let alone Domain Models are a low low priority - if they even make the list.

I have nothing against DDD or XXX but my preference is for rapid practical development using tools that I know can do the job.

To this end I am documenting a simple method that expands on my rant above in some detail. When its finished you can have a look and then probably have a good laugh :-)

cheers
Tony