Joomla 2.0
Just posted this to the Joomla! General Development List (http://groups.google.com/group/joomla-dev-general/browse_thread/thr...). Hope you don't mind I repeat it here:
Joomla! 2.0
I know: 1.6 is still in Alpha-2 today (or did I miss something: just saw a tweet, from 12 hours ago: "trying out Joomla 1.6 beta"). Some people think 1.6 will come soon (this book is supposed to be released half of February: http://www.computerboek.nl/boek/9789012581301/basiscursus_joomla_1....). You can even win a "very special prize" predicting the exact release date (http://brian.teeman.net/joomla-gps/when-will-joomla-16-be-released....). There has been some talking about 1.7 during the Joomla! Developers Conference December 5th, whereupon I saw a Twitter-comment "Get 1.6 done. Then talk 1.7" (http://twitter.com/johanjanssens/status/6409910105). But still, we can think ahead: where do we want to go, what is the horizon, the direction, the aim. Not in detail, but the big picture.
Some ideas I, as a developer, have about Joomla!:
1. once we have ACL, there is no need anymore for the distinction between frontend and backend.
2. we need some fundamental OOP-redesign for better code reuse.
3. extensions should only be allowed if they strictly use an API to the Joomla!-Framework.
4. the central role of the menu could be revised
* ad 1. It is a trend in CMS-land (e.g. DotNetNuke in the transition from version 4 to 5). Drupal is closer at home as an example here. If you have rights to edit something, it doesn't matter if you come the frontend, backend... or the sideline.
* ad 2. I think these symptoms are related: 'cannot override everything', 'cannot extend a component' and 'so many static methods'. You can now only override the html-templates of a view. And even then: you'll have to copy the original file if you want to preserve some of the original functionality. If you want to add something to a component, you'll have to make a new component, copying the original one and adding/changing the things you need. That is a bad "code smell": extending and reusing should be something else than copying. That there are so many static methods in the framework could be a symptom that the original design was more procedural than OOP.
Thinking about a RESTful API for Joomla! I realised, that RESTful-thinking is not just a fancy way to add webservices to your application, but also an architectural choice: you minimise the tasks ("verbs") to CRUD and make resources ("nouns") of the rest. Ultimately it is about restructuring the objects.
* ad 3. A lot of the vulnarabilities in Joomla!-extensions (http://docs.joomla.org/Vulnerable_Extensions_List) are caused by SQL-injection. If all database access and user interaction would only be possible if it is strictly done via the Joomla!-framework, then we can avoid those weaknesses. The use of filters for JRequest::getVar() should be obligate. The new JDatabaseQuery (or how was it called?) could become a database-layer that shields all database-access; if an extension has to use that layer in stead of making direct sql-statements, then some vulnarabilities can be totally solved by the framework.
* ad 4. Some modules depend more on articles than menu-items. Sometimes the distinction between components and modules gives all kinds of problems. There are several extensions trying to fix issues with modules/components/menus. Maybe we should have a look at it again and think about other ways to organise the content. Maybe tagging content and then use those tags to structure menus? My thoughts about this are still vague, but maybe someone has a bright vision.
More ideas?
If you have any ideas about those subjects or have other opinions about where Joomla! could go to, I'm very interested: please post it. This is certainly not meant as critic, but as a look from some distance, to see in what direction I would like to contribute. It is also not meant as dogma: these are just my ideas at the moment, but I would be glad to change them for better ones.
Joomla! 2.0
I know: 1.6 is still in Alpha-2 today (or did I miss something: just saw a tweet, from 12 hours ago: "trying out Joomla 1.6 beta"). Some people think 1.6 will come soon (this book is supposed to be released half of February: http://www.computerboek.nl/boek/9789012581301/basiscursus_joomla_1....). You can even win a "very special prize" predicting the exact release date (http://brian.teeman.net/joomla-gps/when-will-joomla-16-be-released....). There has been some talking about 1.7 during the Joomla! Developers Conference December 5th, whereupon I saw a Twitter-comment "Get 1.6 done. Then talk 1.7" (http://twitter.com/johanjanssens/status/6409910105). But still, we can think ahead: where do we want to go, what is the horizon, the direction, the aim. Not in detail, but the big picture.
Some ideas I, as a developer, have about Joomla!:
1. once we have ACL, there is no need anymore for the distinction between frontend and backend.
2. we need some fundamental OOP-redesign for better code reuse.
3. extensions should only be allowed if they strictly use an API to the Joomla!-Framework.
4. the central role of the menu could be revised
* ad 1. It is a trend in CMS-land (e.g. DotNetNuke in the transition from version 4 to 5). Drupal is closer at home as an example here. If you have rights to edit something, it doesn't matter if you come the frontend, backend... or the sideline.
* ad 2. I think these symptoms are related: 'cannot override everything', 'cannot extend a component' and 'so many static methods'. You can now only override the html-templates of a view. And even then: you'll have to copy the original file if you want to preserve some of the original functionality. If you want to add something to a component, you'll have to make a new component, copying the original one and adding/changing the things you need. That is a bad "code smell": extending and reusing should be something else than copying. That there are so many static methods in the framework could be a symptom that the original design was more procedural than OOP.
Thinking about a RESTful API for Joomla! I realised, that RESTful-thinking is not just a fancy way to add webservices to your application, but also an architectural choice: you minimise the tasks ("verbs") to CRUD and make resources ("nouns") of the rest. Ultimately it is about restructuring the objects.
* ad 3. A lot of the vulnarabilities in Joomla!-extensions (http://docs.joomla.org/Vulnerable_Extensions_List) are caused by SQL-injection. If all database access and user interaction would only be possible if it is strictly done via the Joomla!-framework, then we can avoid those weaknesses. The use of filters for JRequest::getVar() should be obligate. The new JDatabaseQuery (or how was it called?) could become a database-layer that shields all database-access; if an extension has to use that layer in stead of making direct sql-statements, then some vulnarabilities can be totally solved by the framework.
* ad 4. Some modules depend more on articles than menu-items. Sometimes the distinction between components and modules gives all kinds of problems. There are several extensions trying to fix issues with modules/components/menus. Maybe we should have a look at it again and think about other ways to organise the content. Maybe tagging content and then use those tags to structure menus? My thoughts about this are still vague, but maybe someone has a bright vision.
More ideas?
If you have any ideas about those subjects or have other opinions about where Joomla! could go to, I'm very interested: please post it. This is certainly not meant as critic, but as a look from some distance, to see in what direction I would like to contribute. It is also not meant as dogma: these are just my ideas at the moment, but I would be glad to change them for better ones.
Views: 291
Tags: Development, Joomla!, future
-
Comment by Peter Russell on January 24, 2010 at 6:08am -
Louis Landry was seeking ideas last June. I can't seem to find anything beyond this post.
-
Comment by Herman Peeren on January 24, 2010 at 7:04am -
Some interesting replies in the General Development List on this. E.g. in short Hannes replied everything is allready planned or in place.
@Peter: do you mean you cannot find anything more about this subject after Louis was asking for input?
-
Comment by Herman Peeren on January 24, 2010 at 7:17am
-
I didn't mean a distinction between frontend and backend functionality, but an apart administrator-folder with their own objects. Now, when writing frontend fuctionality and you want to use some logic that is also used in the backend, you have to use your backend model or copy code. Or am I doing that the wrong way?
-
Comment by Peter Russell on January 24, 2010 at 7:17am
-
Yes, Herman. Was looking in the wrong place. Thanks
-
Comment by Peter Russell on January 24, 2010 at 7:19am
-
@ Brian, did you mean "increase" or "decrease"?
-
Comment by Amy Stephen on January 24, 2010 at 9:00am
-
Excellent question, Herman - thanks!
1. once we have ACL, there is no need anymore for the distinction between frontend and backend.
Definitely agree, although I think this will take awhile for everyone to see why this is true.
When you consider the redundancy of code in Joomla!, a great deal of the duplication is due to the separation of presentation for frontend and backend. While there will always be a need for someone (or a group of people) to look at content in it's entirety and to configure stuff - there is no reason for a completely separate set of programs to provide for that capability.
So, in that sense. 2.0 should unify that code. I completely agree with that.
2. we need some fundamental OOP-redesign for better code reuse.
Absolutely. In a *big* way.
The MVC architecture is not implemented ideally in Joomla!. The pattern should be better abstracted so that it is only stated once in the code. Then, subclasses with far leaner code should drive that code by passing in variables and table names, etc. The code needs to be significantly DRYed. We are seeing many working on this problem, already. Needs to be resolved in the framework for 2.0.
3. extensions should only be allowed if they strictly use an API to the Joomla!-Framework.
Agree completely. Happily, I think this will be a natural bi-product of the previous change. If components are driven much more by a unified and centralized code base, writing Extensions will be little more than adding parameters and pluggable functions. I can see a point where the core is better positioned to handle DB and file processing, completely, and therefore force filters, escaping, etc. and lock down security.
4. the central role of the menu could be revised
It's interesting that you raise this as a 2.0 need. I have long felt that the menu system in Joomla! is the root of all evil. The ItemID problems are our biggest challenges. As with most things, simplifying is what solves problems and the biggest problem with Joomla! is that it doesn't have single, permanent URLs for content. Menu Items should do nothing more than point to pattern-based URLs. Menu Items should not create URLs. So, if that is where you are heading with that thought, then, I couldn't agree more.
I want to add a few ideas of my own. But need to run for a bit.
Thanks Herman - great discussion and excellent ideas.
-
Comment by Herman Peeren on January 24, 2010 at 9:43am
-
I didn't know there actually were plans for a 2.0 version...
Hannes wrote about the menu-structure revision: "Its planned for 2.0. But before 2.0, we will have 1.7, 1.8, 1.9, maybe 1.10, 1.11, etc.".
Júlio Pontes also wrote some good ideas for future development; he put some links on de General Development List discussion.
-
-
There is talk about v 2.0. I know Louis was going to work on it, but I have not seen any formal planning process or documents. Some of Julio's ideas were pulled into 1.6 by Andrew in terms of chaining for the JDBClass, I believe.
-
-
Some ideas of my own...
A single, common content table so that all content, including articles, images, links, messages, comments, etc., can be treated the same and processed by common treatments, including categorizations (ex. tags, URIs, geo-tagging, meta); protection measures (ex. ACL, spam treatments, bad word filters, filters, threshold measures); broadcasting (ex. pinging, tweeting, email), workflow (ex. archiving, version management, alerts) and response elements (ex. comments, rating, bookmarking, etc.)
Pattern-based URLs for content that result in a single and permanent URL (pretty or otherwise).
A page - portal based presentation that allows single transaction refresh or AJAX-driven updates in modules/portlets.
-
Comment by Herman Peeren on January 24, 2010 at 10:16am
-
Haha, yeah. And then two more years and I'll join you in the Alps... Sharing memories with other pensionados who still know how punchcards looked like 30 years ago (and that sound when you put them in the machine).
It's good to realise how fast it all goes. Internet is only 15 years available outside universities here in our country (yes, phoning with with a 24Kbit modem), PHP was released 13 years ago, Mambo started 10 years ago, .NET is 8 years old and Joomla! is 4.
So let's look at the future, before we are past.
© 2012 Created by Amy Stephen.
You need to be a member of All Together, As A Whole to add comments!
Join All Together, As A Whole