Anything Digital Development

We're developing a new extension using Joomla native MVC right now, but are planning on re-doing it with Nooku to test the framework and review the differences and ease of development it seems brings.

My worry with any of these libraries comes from your last statement though,

but at least install the library or framework when the extension is installed, or upgrade the library if it already exists.

As the the library evolves and improves, a 'bug' that an old extension relied on may break when a new extension installs the update. For the average end user, who knows nothing of libraries and frameworks, this would be impossible to debug.

Food for thought, and something that should be thought through further.

The Joomla! framework will always be somewhat behind what developers who are pushing the envelope are doing. For example, I believe that all three extended APIs that you cite only support PHP 5.2+ which gives them a lot more power than the 1.5 framework which continues to support back to PHP 4.3.11. Having strong developers extend the Joomla API is going to be the source of future development of the framework assuming they follow typical open source processes and share their work with the core. In this we are all thrilled with the Jxtended contribution of their form libraries and other work to Joomla! 1.6. If they hadn't been pushing Joomla to new dimensions while doing their work we wouldn't have these great new libraries for all of us to use.

Sorry Vic but I really don't see the issue here. You talk about things breaking with even minor upgrades of the joomla core. The same has always been true for "regular" extensions so I just don't see the concern. In fact if you have for example installed several Phil Taylor extensions that use BF Framework and there was an issue you would only have to upgrade ONE framework and not FOUR extensions.

I agree with Vic that this does signal an issue to think about. To me, what it says is two things: the Joomla! framework is lacking (and waiting two years between releases is too long) and there is little collaboration between third party developers.

Nooku is now available under the codename of Koowa. Dioscouri has a post entitledThe Nooku Framework with an interesting link to a comparison between the frameworks for developers building Components. There appear to be big gains for rapid development.

The jxtended contributions that are indeed appreciated. It is important to look at these other libraries, too, and see if there are opportunities that should be considered for core.

IMHO, if there are really that many different "inner" frameworks that people make just for their own plugins, that points to a larger issue with Joomla! itself - and one that needs to be seriously examined. Developers wouldn't just write their own plugin frameworks on a whim if what Joomla! provides was sufficient. I have never heard of people doing things like that with Wordpress, for example.

It's one thing if you're installing libraries shared by a set of your extensions. Building code for reuse is one thing that I wish Joomla developers would pick up on.

However, it's quite another if you're building an entire framework to replace the Joomla framework, which is what Koowa seems to do. At some point, you have to decide whether you're building a library to augment what Joomla provides natively, or whether you're building yet another PHP framework.

I'm currently developing the internal new framework for NinjaForge.com that'll be our shared libraries,
at the same time I'm assigned to start using the Nookue Framework for our extensions.

First off I must remind you what rapid application development is all about.
And why it's in the absolute best interest of the end users.

When we can spend our time adding cutting edge features, radical performance enhancements and write secure database queries with lesser code than insecure Joomla equalents,
well, this means we get more time to focus on areas that are often a second priority.

This things are better user interfaces, more documentation and listeng to user feedback instead of just fix reported bugs and get it working.
A shared library like this also means everyone have less work to do in order to for example support Joomla! 1.6 (as this most likely means one new koowa plugin, instead of having to update each individual extension.)

I agree having to update 1 extra extension in addition to the one you're actually going to use is extra work. But that's nothing compared to the extra work of updating 10 heavy components that don't use any framework at all.

If the Joomla framework where progressively evolving like koowa, we wouldn't have this situation at all, but since it's very dated, you shouldn't be asking if we need more libraries, but if the joomla framework really is good enough?

If you want the type of extensions that doesn't do anything new, or don't go beyond what Joomla let you do out of the box, then by all means do so. If you want innovative, creative and exceptional software that frameworks like koowa give developers the opportunity to do, then one extra click is a ridiculous price to pay.

If Koowa was simply yet another framework, I wouldn't be using it. Besides, the nooku guys are the most capable developers to make a framework better than Joomlas. It goes without saying one of the two lead developers (Johan) is the man behind the 1.5 framework.

And if it weren't for him Joomla components wouldn't be MVC today.

You might as well ask, do you really need better software to get the job done?

The problem is not the frameworks themselves - it's that the core has no native way to manage packages and dependencies. It's only been a few months since we got the native facility to upgrade an extension without uninstalling, first (at least when using the core installer).

> but at least install the library or framework when the extension is installed, or upgrade the library if it already exists

As soon as Joomla! has decent core package management in the core, that will be "the" solution - managing the extensions as "packages". Looks like it's coming in 1.6, at least partially (still, I don't see dependency management which is critical for a library).

Right now the Joomla! installer is such that the end user must either install each package individually, or the component creator writes a "meta installer", or you use something like the Software Installer we've written (which can break when used with the Meta Installers, as they make assumptions about the core.)

I encourage the community not to look at this as "do we need need more libraries?" but at a broader view of "how can we better manage the libraries?" and other software packages (along with their dependencies) that are used by Joomla! extensions.

Seriously i think the whole idea of extending Joomla is taking a whole new meaning, if we don't describe things for what they are. We all agree Joomla is the framework here, i don't agree with the merits of having a whole new, completely independent framework inside Joomla, If the Joomla framework does not work well for developers, why don't we contribute to making it better?

I mean don't get me wrong there are some cool features coming up in this external frameworks. I see this exactly as forcing an entire symphony, cakePHP framework for a simple Joomla component. If what should be a Joomla component is so complex to require this extra large frameworks, in my opinion, It should not be a Joomla component, Maybe an entirely independent application

Ok, let's get some context and history straight shall we. Louis Landry and I developed the MVC for large projects we were doing in late 2005 and 2006 (and even that came from experiments I'd been doing for a year or so before that). Up till then it resided in an extended framework very similar to what is now the JXtended library plugin. Fortunately, our work made it into the 1.5 core and, to his credit, Johan made some exceptional improvements to the original code (including taking the patTemplate out - ok, ok, that was not one of my better design decisions). But the original version of what is now JXtended Magazine was a full MVC system for Mambo 4.5.x originally, including layout overrides. Credit where it's due please.

With regard then to the JXtended Libraries, it's probably the oldest freely available GPL frameworks around (maybe Phil's is technically older in age, not sure). The Joomla framework in 1.5 was always intended to be extended by developers. Most of what was in our plugin was considered too experimental at the time to include in the core 1.5 code. Well, it's about 2 years on from that point and a lot of code written by Rob, Louis and myself has been battle-tested in some really complex instances and has stood the test. Consequently, most of the work from our JXtended extended framework is going directly back into the core code in 1.6. This would appear to me to be unique amongst the proliferation of frameworks coming out. Those who have not looked at JForm, JQuery (no, that's not a javascript framework), JModelList, JModelItem and JModelForm need to do so. These are very simple extensions to the original code because the foundation is actually pretty good but, gosh, they make such a difference to development.

I am very happy for Koowa but it's not, in my opinion, an augmented/extended framework like the JXtended libraries. It's standalone, if not a replacement for the Joomla framework (and hey, that opens up doors in different directions - fantastic). If it works for your, great!

But the JXtended stuff has always been done with the vision that it will one day make it into core after we've belted the bugs and scaling issues out of it. Surprisingly, there's not much secret sauce that needs to be added to the 1.5 framework to make it really sing. The plugin has always been freely available for anyone else to use and it's our hope that we'll be able to put a new version out as 1.6 progresses that will assist 3PD's bridge the gap to have their 1.5 extensions as 1.6 ready as they can possibly be. In this way if you do choose to go with our framework, there is a good chance you are going to be compatible with future native versions of Joomla. The learning curve is also going to be gentler because it builds on what is already in Joomla.

In the case of the JXtended Libs, there is no cost to the end-user other than an annoying message that you need to install it if you forgot. The reasons it's there is because Rob, Louis and I like to experiment and then when we are happy with the quality, give back to the core code. Then we'll start playing with new ideas to make it even cooler to develop on Joomla and some might be appropriate to go into core, some may not.

The idea that these frameworks are a threat to market penetration is nonsense though. The reverse is true. Without innovation from experienced developers like ourselves, Joomla will not be able to grow into new areas. Stagnation in development leads to stagnation of your market. Sure some things won't work, but those not willing to embrace failure will never learn. At least that's my experience.

I would warmly welcome more expertise from the various other sources going directly into the core as well. I like playing with new ideas and code.

Hi Vic.

No, not everybody has the access I do, but I've been around long enough to accumulate it But that's the point - I'm a long-term contributor to the project. What about joe-new-developer with his own library? If he is not contributing to the projects, I'll bet he probably makes up his own thing (that's seems to be the trend). If he is contributing (or wants to) to the project, I'll bet he tries to align with his best guess of where the core code might be headed (even I can't predict that).

You can only lead a horse to water so much - can't make it drink.

The extended "frameworks" are not really a problem until you start replacing (not just extending) core functionality with your own flavour of things. So on that point, yes, that will create unforeseen headaches for the end user when I come along and try to fix their site only to find some bizarre non-Joomla native solution being used. If the extended frameworks are touching things not in the core (payment gateways, XML iterators, etc) it's not a big deal. I can tell you that only 10% of our libraries are used 90% of the time - that's a query builder and some extended models. Most of our code is natively where possible. Things like captcha are there so we don't have to add it to every extension - but that will be in 1.6 natively so we can drop it. Building for 1.6 will be really cool because we can drop a lot (if not all) our libraries for run-of-the-mill extensions. New 1.6 extensions will bring new challenges, probably new libraries to be in-situ tested and maybe make it into 1.7, and so on.

As for your challenge (i) we are moving towards transparent installation of our own libraries with extensions, and (ii) we are contributing to the core. I would dearly love to have some company on that podium.

All that said, I don't think frameworks are the biggest issue. Developers just getting good experience in the "Joomla Way" is a much bigger problem. Bring on certification I say.

I agree with Andrew, we need to start pulling developers together and share educational material on what the "Joomla! Way" means.

One challenge has been our documentation is lacking, especially in regards to the API. Matters worse is that the core code, itself, isn't up to snuff with 1.5. Free software devs look at core code as an example. That likely explains the continued use of Global Mainframe usage. 1.6 will be a giant step forward since those issues are cleaned up now.

We have to bring together our seasoned veterans, like Andrew, with our new developers, like joe-new-developer (and jody-new-developer, too). It's that blend of experience and innovation that will move us forward.

Added benefit of a collaborative environment and improved documentation is that consensus on direction and contributors emerge. Unfortunately, we don't have an environment yet in place where we can, as a larger developer community, look at and respond to, all of these libraries and ideas and concepts and collectively select and merge in what empowers developers best and provides for new technologies.

These are all evolutionary steps in a free software community and we are growing, we'll never "be there", of course, and we need to keep open minds to other perspectives.

Thank you Andrew and Amy for your comments. One thing that really stood out to me was Andrew's mention of "certification" which I think would be fantastic. Not only would it give us all at least a starting point for determining whether Joe/Jody Developer was for real, but also provide a path for making sure us developers get some standardized training, both for us (especially as new releases come out), and for our employees.

I learned how to use the Joomla framework through trial and error and looking a lot at the core code (which I now find out isn't the greatest example). But how else would I learn? What's the standard? If there are better ways of doing thing how do I find those out? I could look at the code of other 3PDs but I always considered core code as the gold standard. So some standardized base of training and Best Practices would be an awesome start/reminder for any Joomla dev.

I appreciate your contributions!

I say, why NOT ?!

I learned how to use the Joomla framework through trial and error and looking a lot at the core code (which I now find out isn't the greatest example). But how else would I learn? What's the standard? If there are better ways of doing thing how do I find those out? I could look at the code of other 3PDs but I always considered core code as the gold standard. So some standardized base of training and Best Practices would be an awesome start/reminder for any Joomla dev.