Concerns about the Joomla Platform/Framework?

[Amy Stephen]

Call it what you will ;-), the Joomla Platform/Framework has powered the CMS for years and will continue to do so for the foreseeable future.

I encourage those with concerns about the future of the platform/framework to please post in this email list and ask your questions.

To often, questions are asked of those who are not involved in the development effort and many times the answers don't always reflect what I understand to be happening. Unfortunately, it doesn't take long before misinformation leads to concern and frustration, and end up back at that "we versus them" position, which ends up stopping progress to correct misunderstanding and taking us backwards in terms of collaboration. 

Honestly, the best information we can get is by asking here. (Well, the best information we can get is by rolling up our sleeves up and helping, but most don't/can't/choose not to do that, which is a valid choice.)

If you want to follow the framework devs on Twitter, that is another good source of info. Not saying we have to treat anyone like a superstar but maybe we could avoid publicly cursing the few who are trying to advance the platform. ;-)

Don Gilbert @dilbert4life
Andrew Eddie @AndrewEddie
Michael Babker @mbabker
Rouven Wessling @RouvenWessling
Ian MacLennan @ian_maclennan

I'd have to take the log out of my eye before I could tell someone how to be a 'responsible community member.' Not judging anyone, just encouraging better approaches. We're always going to make mistakes, a quick apology is appreciated, and then get up and try again.

Thanks for considering.

[Andrew Eddie]

On 12 March 2013 02:53, George Wilson <georgeja...@googlemail.com> wrote:

Hi George.

I'd like to question where the framework is going. It's now going so far to become 'independent' of the CMS system (yes I know in some ways that it's supposed to be used separately to the CMS system e.g. ebay etc.) that I'm questioning whether this latest version will be of any use to the Joomla system.

Just a point of clarification. Joomla's mission is to provide a flexible digital publishing platform - it's not to produce the best web site building tool in the world. Basically the idea is that Joomla, the project, was always intended to be more than "just a CMS".

 

Presumably Joomla 4.0 will be the earliest version that can use the new Joomla Framework - and that will be using all the currently existing classes (and perhaps a few new ones/replacement ones for any deprecated classes that come between now and then).

That's not necessarily true. It could be as early as 3.2 BUT there have to be developers interested in starting to port code across to new ways of thinking. And for that to happen, you need solid buy-in from the extension developers. If you don't get that, it's always going to be difficult to innovate the CMS at an architectural level.

 

So whats the release cycle for the framework going to be like?

That's a really good question. I've mapped out some functional ideas on the issue tracker but that really just catches us up to where we should be now:

https://github.com/joomla/joomla-framework/issues/milestones

We do need some more planning in terms of a longer term roadmap though. I've been giving that some thought but just getting the transition from platform to framework has been consuming most of my time.

 

Is it going to be slowly incrementing versions - like the Platform currently is - for example for Joomla CMS 4.0->4.1 how are we going to make sure there aren't too many backward compatibility issues?

For a start, the new framework is absolutely backward incompatible with the platform. Namespacing does most of that but we've also taken the opportunity to clean up a lot of crazy stuff in the code (not all, but a lot). For example, I refactored the Application package yesterday to use more dependancy injection and reworked the Database package to use a PSR-3 compliant logger.

For here, we are going to be using semantic versioning for the framework and probably allow each package to control it's own development path. We haven't quite worked out the logistics of how to do that yet but that's the general idea. So what you'll probably see is packages that stay extremely stable over time and other changes that are extremely active.

The problem with our current system is that it's a one-in-all-in deal when using the platform. In the future, the CMS or any other downstream user will be able to lock into the version of the package they actually need.

As I said, I'm still not sure of the fine details but I would probably expect the version 1.0 or the framework to be a way for allowing developers to get used to Composer and just using bits of the framework. I think we can have the expectation that the time between 1.0 and 2.0 is for ironing out further issues and we might do that process quickly (over 6 months say … maybe).

 

However its 18 months till Jooma 4.0 comes out (all things staying as they are) and in that time I guess theirs a lot of time for big new developments to happen in the Joomla Framework.

One would hope there are :)

 

So how do we make sure that the Framework at least stays (roughly) on the same path as the CMS.

We actually don't. Remember, the framework is a tool that can be used by any PHP developer. Our mission is digital publishing so we are going to be focusing on things that fulfil that mission. So while the framework should be good for building a web site management tool (like the Joomla CMS), it should also be good at writing a web services application that can support not only web sites, but any other device that needs to deal with content.

So I would turn you question around and ask how is the CMS going to stay on a path that allows it to be relevant to a device agnostic world. 

 

Because if Joomla Framework goes in a different direction to the CMS the only thing to link the two things would be a name (Joomla).

I think the reality is that the framework is going to be providing technologies that the CMS will need to embrace to stay alive. The code that the CMS runs on is really dated and isn't something that would attract the best and brightest developers (unless they are looking to "fix" it, but then we get back to the question of how quickly are extension developers willing to embrace change).

 

Already with things like JError/Exceptions (Joomla 2.5/3.0), JInput/JRequest (Joomla 2.5/Magic Quotes) we've found places where the Platform team are miles ahead of the CMS team - and the CMS team have had to play catch up with extra statements and stuff that I can imagine the Framework may well accelerate this further!

Yes, that's a good example of the tensions that exist between modern developer practice and being stuck with the way the CMS does things that is at least 5 years old. Another way to look at that is to ask what is holding the CMS back and keeping it so far behind. There are at least two ways to look at that problem. But we've tried to attenuate the rate of change for the last two years and we've just got to the point where "playing nice" with the CMS got way too hard.

 

I guess chiefly my concern is that give it another cycle or two of Joomla versions and we'll find the Framework and CMS at such different stages that the Framework will split up and we'll find ourselves with half the number of developers etc. in that respect.

It's a problem because you want to be able to attract talented developers to work in a project like Joomla. But when you have two major areas (three if you count the new Tracker), and the CMS is running on code that is old and outdated, can you blame them for not being overly interested? The other problem is that we have hundreds of active extension developers out there but only a fraction of them are actively engaged in protecting their investment in Joomla. That's a concern as well.

 

My final question/issue is in what I do in terms of developing extensions. Documentation. Whilst the platform manuals are useful - I've found them to be far from complete - and there has been little on the Joomla Docs! site with the new platform features - so it's actually becoming an issue to code for Joomla 2.5/3.0 extensions in terms of limited documentation.

Documentation is a thorn in my and our side. We are playing catch up and you'll see the milestones include items for documentation in all packages. But, I have to fall back to my stock answer : you have as much documentation as people have *bothered* to write. We are enforcing that you write docs now for new work, but it hasn't always been the case - stinks but it is what it is. You know, if every extension developer took just 4 hours out at every PBF, we could have the docs finished in one sprint. It's very frustrating.

 

How are you guys proposing to build documentation for your system.

There are two levels of documentation. First is the API and that's covered by the DocBlocks. We actually do quite well in this regard and there's another theard on this list where you can see how we are going to do that.

The second level is "tutorial" style and that documentation is in the README.md file in the root of each package.

 

For example the issue I posted here ( https://github.com/joomla/joomla-platform/pull/1810 ) where JFactory::getUser has changed in some aspects means I now have to use JUser::getInstance for example - which is much well less documented - I can only find a brief summary on the API page.

JFactory is not going to be in the new framework and neither is the equivalent of JUser for now.

 

It would be really nice to have full and proper documenation for this stuff again. Rather than a class which I have to trawl through every time - and may not even have what I want in it! I'd be interested to hear your comments on this

I agree. If you have ideas about how we can entice people to write documentation for us, I'm all ears. It's all volunteers driven.

 

This sounds like massive moan - but I promise its not! I'm just (personally) feel Joomla primarily is about the CMS system (although clearly the standalone Platform/Framework has its advantages) and I'd like to see how you guys feel this is going to fit into the grand scheme of that.

They are reasonable concerns but there are also other ways to look at them. I think the CMS has got some thinking to do in terms of what it wants to be and in terms of who is going to make that happen. We (PLT) will be publishing a draft roadmap for the CMS soon and those that can put two-and-two together are going to realise that the CMS is going to have to work with the framework to be able to achieve the results. But that depends on there being people willing to do that … it's a constant problem when dealing with a volunteer workforce where you don't know who is going to show up for work on any given day :)

Regards,

Andrew Eddie 

[Amy Stephen]

On Mon, Mar 11, 2013 at 11:53 AM, George Wilson <georgeja...@googlemail.com> wrote:

I'd like to question where the framework is going. It's now going so far to become 'independent' of the CMS system (yes I know in some ways that it's supposed to be used separately to the CMS system e.g. ebay etc.) that I'm questioning whether this latest version will be of any use to the Joomla system.

If it were up to me, I'd take the work the platform is currently doing - separating each of the packages into independent, but cohesive, packages, -- and I'd immediately pull them back together into "the platform" - and put it right back under the CMS.

That way, people will get it -- this isn't about changing features or functionality - it's about addressing the lack of flexibility that has held the CMS from moving forward as quickly as it should have, following the 1.5 release.

If that approach were used, it would not take long for the community to see how much easier it is to schedule platform changes in, to swap out JDatabase for Doctrine, for using Twig instead of JDoc, all within the CMS.

Then, the happy coincidence of being able to use JDatabase in non-CMS applications would be seen as just that, a way to take the existing work and offer it to more people without more effort. Never a bad idea for the CMS to support those efforts which involve more developers -- who can code for users.

[Andrew Eddie]

On 12 March 2013 09:07, Amy Stephen <amyst...@gmail.com> wrote:

On Mon, Mar 11, 2013 at 11:53 AM, George Wilson <georgeja...@googlemail.com> wrote:

I'd like to question where the framework is going. It's now going so far to become 'independent' of the CMS system (yes I know in some ways that it's supposed to be used separately to the CMS system e.g. ebay etc.) that I'm questioning whether this latest version will be of any use to the Joomla system.

If it were up to me, I'd take the work the platform is currently doing - separating each of the packages into independent, but cohesive, packages, -- and I'd immediately pull them back together into "the platform" - and put it right back under the CMS.

That way, people will get it

Many extension developers haven't even upgraded to use JForm yet so I'm not convinced that will work as expected (basically 1.6 was "here, this is how you should write a component" ... ). However the Framework gets back into the CMS it needs to be planned and I wouldn't lift a finger without the buy-in of the majority of extension developers. They are the ones setting the pace for change in the Joomla CMS.

But, if the extension devs do want to get together and work out how to make a solid FoF-like thing on which to build components, then I would definitely advise to use the Framework as a starting point for that.

Regards,

Andrew Eddie

[Amy Stephen]

Andrew - you are right.

I guess there's pretty much nothing else to add.

--
You received this message because you are subscribed to a topic in the Google Groups "Joomla! Platform Development" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/joomla-dev-platform/4Q0eu4G7NWI/unsubscribe?hl=en.
To unsubscribe from this group and all its topics, send an email to joomla-dev-plat...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[George Wilson]

Hi Andrew,

Thanks for the detailed response first of all! 

 

On Monday, March 11, 2013 9:25:23 PM UTC, Andrew Eddie wrote:

On 12 March 2013 02:53, George Wilson <georgeja...@googlemail.com> wrote:

Hi George.

I'd like to question where the framework is going. It's now going so far to become 'independent' of the CMS system (yes I know in some ways that it's supposed to be used separately to the CMS system e.g. ebay etc.) that I'm questioning whether this latest version will be of any use to the Joomla system.

Just a point of clarification. Joomla's mission is to provide a flexible digital publishing platform - it's not to produce the best web site building tool in the world. Basically the idea is that Joomla, the project, was always intended to be more than "just a CMS".

Agreed - sorry if I didn't make this clear enough - but also I'd suggest that Joomla Platform/Frameworks biggest usage will be within the CMS system! 

 

Presumably Joomla 4.0 will be the earliest version that can use the new Joomla Framework - and that will be using all the currently existing classes (and perhaps a few new ones/replacement ones for any deprecated classes that come between now and then).

That's not necessarily true. It could be as early as 3.2 BUT there have to be developers interested in starting to port code across to new ways of thinking. And for that to happen, you need solid buy-in from the extension developers. If you don't get that, it's always going to be difficult to innovate the CMS at an architectural level.

http://magazine.joomla.org/issues/issue-mar-2013/item/1136-differences-between-the-joomla-framework-and-joomla-platformsays that the platform will be reintegrated with the CMS. So I assumed this was what was going to happen in 3.2/3.5 - now Joomla 3.1 is all but released.

As an extension developer - I'd say I'd be more than happy for this to happen BUT its developing extensions for two versions. Whilst there doesn't need to be backwards compatibility I know - I'm sure you can understand its a lot easier to have a 2.5/3.0 compat extension where you only need to fix bugs once! (I know you guys have a similar thing fixing bugs in the CMS and Platform at the same time!). I find for the majority of my simpler extensions I only have two differences to keep me 2.5.5/3.x compat - a conditional statement for JError and a conditional statement for jQuery inclusion.

This was the same when 1.5 and the 1.6/1.7/2.5 cycle was in development. However I can see Joomla 4.x starting from scratch in terms of extension development with the new JView/JController/JModel classes coming through so I'd say if you want/need to replace the JDoc/JDatabase - thats where we need to work together to target (and if this happens a crap load of documentation about building extensions needs to be prepared in ADVANCE - not as seems to happen with this rapid('ish) release cycle - 6 months after the x.0 release.

 

So whats the release cycle for the framework going to be like?

That's a really good question. I've mapped out some functional ideas on the issue tracker but that really just catches us up to where we should be now:

https://github.com/joomla/joomla-framework/issues/milestones

We do need some more planning in terms of a longer term roadmap though. I've been giving that some thought but just getting the transition from platform to framework has been consuming most of my time.

No thats fine - I know this is very early stages - so I just wondered if any thought had gone into this - I look forward to seeing updates on it! 

 

Is it going to be slowly incrementing versions - like the Platform currently is - for example for Joomla CMS 4.0->4.1 how are we going to make sure there aren't too many backward compatibility issues?

For a start, the new framework is absolutely backward incompatible with the platform. Namespacing does most of that but we've also taken the opportunity to clean up a lot of crazy stuff in the code (not all, but a lot). For example, I refactored the Application package yesterday to use more dependancy injection and reworked the Database package to use a PSR-3 compliant logger.

For here, we are going to be using semantic versioning for the framework and probably allow each package to control it's own development path. We haven't quite worked out the logistics of how to do that yet but that's the general idea. So what you'll probably see is packages that stay extremely stable over time and other changes that are extremely active.

The problem with our current system is that it's a one-in-all-in deal when using the platform. In the future, the CMS or any other downstream user will be able to lock into the version of the package they actually need.

As I said, I'm still not sure of the fine details but I would probably expect the version 1.0 or the framework to be a way for allowing developers to get used to Composer and just using bits of the framework. I think we can have the expectation that the time between 1.0 and 2.0 is for ironing out further issues and we might do that process quickly (over 6 months say … maybe).

Thanks for the information - I look forward to see this playing out over time! 

 

However its 18 months till Jooma 4.0 comes out (all things staying as they are) and in that time I guess theirs a lot of time for big new developments to happen in the Joomla Framework.

One would hope there are :)
 

So how do we make sure that the Framework at least stays (roughly) on the same path as the CMS.

We actually don't. Remember, the framework is a tool that can be used by any PHP developer. Our mission is digital publishing so we are going to be focusing on things that fulfil that mission. So while the framework should be good for building a web site management tool (like the Joomla CMS), it should also be good at writing a web services application that can support not only web sites, but any other device that needs to deal with content. 

So I would turn you question around and ask how is the CMS going to stay on a path that allows it to be relevant to a device agnostic world. 
 

Because if Joomla Framework goes in a different direction to the CMS the only thing to link the two things would be a name (Joomla).

I think the reality is that the framework is going to be providing technologies that the CMS will need to embrace to stay alive. The code that the CMS runs on is really dated and isn't something that would attract the best and brightest developers (unless they are looking to "fix" it, but then we get back to the question of how quickly are extension developers willing to embrace change). 

 

Already with things like JError/Exceptions (Joomla 2.5/3.0), JInput/JRequest (Joomla 2.5/Magic Quotes) we've found places where the Platform team are miles ahead of the CMS team - and the CMS team have had to play catch up with extra statements and stuff that I can imagine the Framework may well accelerate this further!

Yes, that's a good example of the tensions that exist between modern developer practice and being stuck with the way the CMS does things that is at least 5 years old. Another way to look at that is to ask what is holding the CMS back and keeping it so far behind. There are at least two ways to look at that problem. But we've tried to attenuate the rate of change for the last two years and we've just got to the point where "playing nice" with the CMS got way too hard.

Agreed - but as a dev - I couldn't really see what JInput has bought to the table over JRequest other than the nuisance that I have to check for magic quotes before I choose which to use in a extension!!! For example even my website (as a dev) - is on PHP 5.3 - admittedly I'm going to upgrade soon - but so many people will be on earlier versions who just aren't aware. As an extension dev I have to think of backward compatibility for the old PHP versions!

 

 

I guess chiefly my concern is that give it another cycle or two of Joomla versions and we'll find the Framework and CMS at such different stages that the Framework will split up and we'll find ourselves with half the number of developers etc. in that respect.

It's a problem because you want to be able to attract talented developers to work in a project like Joomla. But when you have two major areas (three if you count the new Tracker), and the CMS is running on code that is old and outdated, can you blame them for not being overly interested? The other problem is that we have hundreds of active extension developers out there but only a fraction of them are actively engaged in protecting their investment in Joomla. That's a concern as well.

Oh I do completely agree with this. I refer back up to my comments about perhaps introducing this in Joomla 4.x but note again - if the Joomla CMS can't physically keep up with this - then where does it go?? The CMS team has 6 months to produce something then which has a complete new set of (undocumented) API classes.

 

My final question/issue is in what I do in terms of developing extensions. Documentation. Whilst the platform manuals are useful - I've found them to be far from complete - and there has been little on the Joomla Docs! site with the new platform features - so it's actually becoming an issue to code for Joomla 2.5/3.0 extensions in terms of limited documentation.

Documentation is a thorn in my and our side. We are playing catch up and you'll see the milestones include items for documentation in all packages. But, I have to fall back to my stock answer : you have as much documentation as people have *bothered* to write. We are enforcing that you write docs now for new work, but it hasn't always been the case - stinks but it is what it is. You know, if every extension developer took just 4 hours out at every PBF, we could have the docs finished in one sprint. It's very frustrating.

Then can we put extra emphasis on the PBF day on saturday for docs! Because I guarantee that otherwise the docs will have give or take no changes but a load of Bugs will be cleaned out of the CMS list.

I know - I've been writing most the Joomla 2.5.x help screens over the last few weeks. But sometimes I might well be using antique coding practices because so many new classes are being introduced and then dropped just as quickly I struggle to keep up!!! But in many ways the documentation you guys have is focused in the wrong place for the majority of dev's. I want the most info about JUser etc - stuff used in 90% of extensions - compared to JGitHub - which i can imagine only a handful of people use!!

 

 

How are you guys proposing to build documentation for your system.

There are two levels of documentation. First is the API and that's covered by the DocBlocks. We actually do quite well in this regard and there's another theard on this list where you can see how we are going to do that.

Yes I noticed about this - however just for example compare this:
http://api.joomla.org/Joomla-Platform/User/JUser.html#getInstance

to the same thing for J!1.5

http://docs.joomla.org/JFactory/getUser

As a noob developer I'd have no clue what a "Global User Object is". But saying to returns the details of the currently logged in user in an array - I could understand! Whilst we want to encourage pro developers to use Joomla! simultaneously we need to encourage new people to Joomla as well - who may not understand optimal coding practices - but who want to learn last.

 

The second level is "tutorial" style and that documentation is in the README.md file in the root of each package.
 

For example the issue I posted here ( https://github.com/joomla/joomla-platform/pull/1810 ) where JFactory::getUser has changed in some aspects means I now have to use JUser::getInstance for example - which is much well less documented - I can only find a brief summary on the API page.

JFactory is not going to be in the new framework and neither is the equivalent of JUser for now.  

 

It would be really nice to have full and proper documenation for this stuff again. Rather than a class which I have to trawl through every time - and may not even have what I want in it! I'd be interested to hear your comments on this

I agree. If you have ideas about how we can entice people to write documentation for us, I'm all ears. It's all volunteers driven.

Yeah I know! I would write it if I knew what kinda stuff I was supposed to use! I haven't really followed the development of the platform - but just looking at how it appears when I dev'ing stuff - classes change so fast I have no clue what I'm supposed to do. Take JDatabase. Back in 1.5 you literally wrote in the MYSQL statement - then used loadObjectList etc. Awesome simple and effective - requires basic MYSQL syntax - no more. Go to J!2.5 and First version of the platform. We decide to support more databases postgre etc. Great idea. But it took until October last year for ANY documentation to be written in the wiki about how to use it - until then I was using the old 1.5 statements because they worked and I had no idea there was an alternative - until I happened to be researching a component and was looking in the default Joomla component models. Even now theirs nothing about exceptions. I'm no genius with PHP (I do this dev in my time outside my 9-5 job) and their some reasonable docs around on the web about this - but just a few examples on the Joomla Docs site would make life so much easier for me.

Now in Joomla 3.0 we have to use execute() rather than query() - WHY??????? it (to my untrained eye) seems to do the same job and just appears to be hassle. Now you want to drop it all together in the new framework. Then why keep changing it????

This is what annoys me in a way as a dev is that classes are so constantly being created and then dropped almost immediately (I mean I know web dev is constantly being improved with MySQL/PHP/HTML5/CSS3 updates but even so......)!

Another example being JLog - a brilliant class - but has nothing documented about it. I've ended up creating a wiki page for it ( http://docs.joomla.org/Using_JLog ) but I have bugger all clue how accurate it is! It works in J!2.5 and 3.0 but whether it uses the latest and best coding I have no clue.

 

 

This sounds like massive moan - but I promise its not! I'm just (personally) feel Joomla primarily is about the CMS system (although clearly the standalone Platform/Framework has its advantages) and I'd like to see how you guys feel this is going to fit into the grand scheme of that.

They are reasonable concerns but there are also other ways to look at them. I think the CMS has got some thinking to do in terms of what it wants to be and in terms of who is going to make that happen. We (PLT) will be publishing a draft roadmap for the CMS soon and those that can put two-and-two together are going to realise that the CMS is going to have to work with the framework to be able to achieve the results. But that depends on there being people willing to do that … it's a constant problem when dealing with a volunteer workforce where you don't know who is going to show up for work on any given day :)

Completely agreed. And I do sympathise with this. But the CMS (and I think rightly) is focused for 4.x on getting a restful API doc ready so mobile apps etc can be tapped in.  Again the CMS team has 6 months to work on this and component etc updates. And their constantly behind - e.g. its taken them this long to get Layouts implemented - its still mainly mootools rather than jQuery orientated in the backend. I think the PLT needs to look at a longer gap at getting the new x.0 releases supported by the CMS team - perhaps 12 months to that first 4.0/5.0 etc release - because currently going from 3.0->3.1->3.2 is almost like Beta versions for Joomla 3.5 as their just bringing them upto where Joomla 3.0 should have been to start with!!
 

Regards,

Andrew Eddie 

RE: JForm etc usage - I think many people are on the upgrade now - with J!1.5 now unsupported - their is a movement from having J!1.5/2.5 compat extensions (where JForm was only supported on 1 version vs. JParameter in both) to J2.5/3.x extensions (with JParameter removed on 3.x i think many people are upgrading to use JForm etc).

I think most dev's are prepared for new JModel/JView/JController Classes coming - so this is your time to introduce sweeping changes if they are needed. But please release them in block rather than a kinda seepage in we seem to be having at the moment - it actually makes it easier because then you can make the sweeping changes in one go - rather than constantly worrying about class changes every time Joomla gets updated (yes there will have to be changes I appreciate - but nothing too significant I would hope!)

Kind Regards,

George

[Andrew Eddie]

On 12 March 2013 12:14, George Wilson <georgeja...@googlemail.com> wrote:

Agreed - sorry if I didn't make this clear enough - but also I'd suggest that Joomla Platform/Frameworks biggest usage will be within the CMS system! 

Right, but it's a bit of a circular line of thought. We have to make the Platform work for the CMS so we can't do anything to the Platform which doesn't work for the CMS. You end up chasing your tail. The Framework, though, is actually starting from scratch - in terms of that actual code, anyone can become the biggest stakeholder.

 

 http://magazine.joomla.org/issues/issue-mar-2013/item/1136-differences-between-the-joomla-framework-and-joomla-platform says that the platform will be reintegrated with the CMS. So I assumed this was what was going to happen in 3.2/3.5 - now Joomla 3.1 is all but released.

It's missed 3.1 - just the way it's going to happen.

 

As an extension developer - I'd say I'd be more than happy for this to happen BUT its developing extensions for two versions. Whilst there doesn't need to be backwards compatibility I know - I'm sure you can understand its a lot easier to have a 2.5/3.0 compat extension where you only need to fix bugs once! (I know you guys have a similar thing fixing bugs in the CMS and Platform at the same time!). I find for the majority of my simpler extensions I only have two differences to keep me 2.5.5/3.x compat - a conditional statement for JError and a conditional statement for jQuery inclusion.

I think the ideal is for the extension developers (and I do still *just* fit into that category) to say enough is enough and we need a more reliable layer that can span Joomla versions. It may be too late for 2.5 but looking forward it would be idea for extensions to be run on a layer that is available in both 3.x and 4.x.

Agreed - but as a dev - I couldn't really see what JInput has bought to the table over JRequest other than the nuisance that I have to check for magic quotes before I choose which to use in a extension!!! For example even my website (as a dev) - is on PHP 5.3 - admittedly I'm going to upgrade soon - but so many people will be on earlier versions who just aren't aware. As an extension dev I have to think of backward compatibility for the old PHP versions!

The change was architectural. JInput allows for dependancy injection (best practice) whereas JRequest was a glorified globals container (hard to test, dev's doing naughty things with it, etc).

 

Oh I do completely agree with this. I refer back up to my comments about perhaps introducing this in Joomla 4.x but note again - if the Joomla CMS can't physically keep up with this - then where does it go?? The CMS team has 6 months to produce something then which has a complete new set of (undocumented) API classes.

It's 12 months until 3.5 and 18 months until 4.0 if I have my dates right. Should be enough time to sort something out.

 

I know - I've been writing most the Joomla 2.5.x help screens over the last few weeks.

Thanks!

 

But sometimes I might well be using antique coding practices because so many new classes are being introduced and then dropped just as quickly I struggle to keep up!!!

It actually hasn't been that quick when you follow the history, but it does feel quick.

 

But in many ways the documentation you guys have is focused in the wrong place for the majority of dev's. I want the most info about JUser etc - stuff used in 90% of extensions - compared to JGitHub - which i can imagine only a handful of people use!!

JUser comes from the 1.5 days when developers wanted to develop and didn't want to be slowed down by having to write documentation. JGithub is a product of our "new rules" :) Again, what's there is what's been contributed and we have a lot of technical debt owed to us.

 

Yes I noticed about this - however just for example compare this:

http://api.joomla.org/Joomla-Platform/User/JUser.html#getInstance

to the same thing for J!1.5

http://docs.joomla.org/JFactory/getUser

As a noob developer I'd have no clue what a "Global User Object is". But saying to returns the details of the currently logged in user in an array - I could understand! Whilst we want to encourage pro developers to use Joomla! simultaneously we need to encourage new people to Joomla as well - who may not understand optimal coding practices - but who want to learn last.

One is an API reference and there's a recognised style for that. The other is a tutorial and that's a different beast. Both are very necessary though and "lately" we've required more of contributors in terms of tutorials.

 

Yeah I know! I would write it if I knew what kinda stuff I was supposed to use!

I think the clue here is to know where to write it when you find out. Ideally, everyone can do the following when they find a "gotcha nugget":

1. Add a short note in the API documentation (probably to do with a class method).

2. Add a longer note and an example to our new README.md files at the root of each package.

 

I haven't really followed the development of the platform - but just looking at how it appears when I dev'ing stuff - classes change so fast I have no clue what I'm supposed to do. Take JDatabase. Back in 1.5 you literally wrote in the MYSQL statement - then used loadObjectList etc. Awesome simple and effective - requires basic MYSQL syntax - no more. Go to J!2.5 and First version of the platform. We decide to support more databases postgre etc. Great idea. But it took until October last year for ANY documentation to be written in the wiki about how to use it - until then I was using the old 1.5 statements because they worked and I had no idea there was an alternative - until I happened to be researching a component and was looking in the default Joomla component models. Even now theirs nothing about exceptions. I'm no genius with PHP (I do this dev in my time outside my 9-5 job) and their some reasonable docs around on the web about this - but just a few examples on the Joomla Docs site would make life so much easier for me.

I hear you. I've been wanting to find time to document JQuery but the time has just escaped me.

 

Now in Joomla 3.0 we have to use execute() rather than query() - WHY??????? it (to my untrained eye) seems to do the same job and just appears to be hassle. Now you want to drop it all together in the new framework. Then why keep changing it????

The query method has been around since Mambo 4.5 so we've only changed it once :) I can't remember exactly but in API terms `execute` is more appropriate and fits into the PDO mould better (prepare a query, execute a query).

 

This is what annoys me in a way as a dev is that classes are so constantly being created and then dropped almost immediately (I mean I know web dev is constantly being improved with MySQL/PHP/HTML5/CSS3 updates but even so......)!

You'll have to refresh my memory. I can't recall any classes added and immediately dropped. There is always a lead time before the code is actually removed from the code.

 

Another example being JLog - a brilliant class - but has nothing documented about it. I've ended up creating a wiki page for it ( http://docs.joomla.org/Using_JLog ) but I have bugger all clue how accurate it is! It works in J!2.5 and 3.0 but whether it uses the latest and best coding I have no clue.

http://joomla.github.com/joomla-platform/?chapters/packages/log.md :)

 

Completely agreed. And I do sympathise with this. But the CMS (and I think rightly) is focused for 4.x on getting a restful API doc ready so mobile apps etc can be tapped in.  Again the CMS team has 6 months to work on this and component etc updates. And their constantly behind - e.g. its taken them this long to get Layouts implemented - its still mainly mootools rather than jQuery orientated in the backend. I think the PLT needs to look at a longer gap at getting the new x.0 releases supported by the CMS team - perhaps 12 months to that first 4.0/5.0 etc release - because currently going from 3.0->3.1->3.2 is almost like Beta versions for Joomla 3.5 as their just bringing them upto where Joomla 3.0 should have been to start with!!

I think you've got your dates wrong. It's now 2 years between major releases.

 

I think most dev's are prepared for new JModel/JView/JController Classes coming - so this is your time to introduce sweeping changes if they are needed. But please release them in block rather than a kinda seepage in we seem to be having at the moment - it actually makes it easier because then you can make the sweeping changes in one go - rather than constantly worrying about class changes every time Joomla gets updated (yes there will have to be changes I appreciate - but nothing too significant I would hope!)

What I think needs to happen is for the extension developers to get together and thrash out what they want, when they want it, how fast it should roll out, etc. The PLT can certainly facilitate that conversation, but the ownership of any decisions and forward momentum, in my opinion, needs to come squarely from the extension developers themselves. Where the Framework would fit into a timeline for that to happen, I have no clue. I certainly know what I'd be doing if I was still in big-extension territory, and I'm happy to share those ideas and how the Framework fits in, but I think those ideas would be a bit too radical for most to swallow :)

Regards,
Andrew Eddie
http://learn.theartofjoomla.com - free tutorials and videos on Joomla development

[George Wilson]

On Tuesday, March 12, 2013 2:57:52 AM UTC, Andrew Eddie wrote:

On 12 March 2013 12:14, George Wilson <georgeja...@googlemail.com> wrote:

Agreed - sorry if I didn't make this clear enough - but also I'd suggest that Joomla Platform/Frameworks biggest usage will be within the CMS system! 

Right, but it's a bit of a circular line of thought. We have to make the Platform work for the CMS so we can't do anything to the Platform which doesn't work for the CMS. You end up chasing your tail. The Framework, though, is actually starting from scratch - in terms of that actual code, anyone can become the biggest stakeholder.

If I was being cynical I'd say stakeholders like ebay and ebay and ebay? (as they contribute a fair amount to the development of the Platform and presumably will to the Framework).

 

 

 http://magazine.joomla.org/issues/issue-mar-2013/item/1136-differences-between-the-joomla-framework-and-joomla-platform says that the platform will be reintegrated with the CMS. So I assumed this was what was going to happen in 3.2/3.5 - now Joomla 3.1 is all but released.

It's missed 3.1 - just the way it's going to happen.

Sure - but my point being if the platform is being reintegrated with the CMS for now - presumably the framework isn't going to be for the near future? (i.e. 3.x series)

 

 

As an extension developer - I'd say I'd be more than happy for this to happen BUT its developing extensions for two versions. Whilst there doesn't need to be backwards compatibility I know - I'm sure you can understand its a lot easier to have a 2.5/3.0 compat extension where you only need to fix bugs once! (I know you guys have a similar thing fixing bugs in the CMS and Platform at the same time!). I find for the majority of my simpler extensions I only have two differences to keep me 2.5.5/3.x compat - a conditional statement for JError and a conditional statement for jQuery inclusion.

I think the ideal is for the extension developers (and I do still *just* fit into that category) to say enough is enough and we need a more reliable layer that can span Joomla versions. It may be too late for 2.5 but looking forward it would be idea for extensions to be run on a layer that is available in both 3.x and 4.x.

See this is the issue to me - there is a difference between developers and the Joomla Core! in terms of how the versions work. Now whilst Joomla 3.0 is about to get dropped for 3.1 etc - realistically - there are always people who are going to stay behind on 3.0 - and as developers in an ideal world we need to support them as well! Some of the major extensions (Kunena, CB etc.) are gearing up extensions for Joomla 3.x and so I'd say what's in 3.x at least can't be dropped and will need to stay as is until 4.x. And to be honest I would have thought most these extensions - now nearly built will now not use these new standards if they were to be introduced in 3.2/3.5

 

Agreed - but as a dev - I couldn't really see what JInput has bought to the table over JRequest other than the nuisance that I have to check for magic quotes before I choose which to use in a extension!!! For example even my website (as a dev) - is on PHP 5.3 - admittedly I'm going to upgrade soon - but so many people will be on earlier versions who just aren't aware. As an extension dev I have to think of backward compatibility for the old PHP versions!

The change was architectural. JInput allows for dependancy injection (best practice) whereas JRequest was a glorified globals container (hard to test, dev's doing naughty things with it, etc).

 

Oh I do completely agree with this. I refer back up to my comments about perhaps introducing this in Joomla 4.x but note again - if the Joomla CMS can't physically keep up with this - then where does it go?? The CMS team has 6 months to produce something then which has a complete new set of (undocumented) API classes.

It's 12 months until 3.5 and 18 months until 4.0 if I have my dates right. Should be enough time to sort something out.

Agreed - but I feel we need to start thinking about this now rather than as soon as 3.5 is released. I think the fact that 1.6 and 3.0 have been more beta's to 1.7 and 3.x respectively than they have been an actual new usable version.

 

But sometimes I might well be using antique coding practices because so many new classes are being introduced and then dropped just as quickly I struggle to keep up!!!

It actually hasn't been that quick when you follow the history, but it does feel quick.

Fair enough - I guess especially as you only majorly rewrite your extensions for a Joomla version every 2 years (for a new cycle).

 

 

But in many ways the documentation you guys have is focused in the wrong place for the majority of dev's. I want the most info about JUser etc - stuff used in 90% of extensions - compared to JGitHub - which i can imagine only a handful of people use!!

JUser comes from the 1.5 days when developers wanted to develop and didn't want to be slowed down by having to write documentation. JGithub is a product of our "new rules" :) Again, what's there is what's been contributed and we have a lot of technical debt owed to us.

Fair enough - but can we not have a month to slow down and write this stuff (hopefully this is going to happen as you said you had it in your Github pull requests - but just thought I'd make the request explicit!)

 

One is an API reference and there's a recognised style for that. The other is a tutorial and that's a different beast. Both are very necessary though and "lately" we've required more of contributors in terms of tutorials.

I agree - but the API is literally it at the moment.

 

 

Yeah I know! I would write it if I knew what kinda stuff I was supposed to use!

I think the clue here is to know where to write it when you find out. Ideally, everyone can do the following when they find a "gotcha nugget":

1. Add a short note in the API documentation (probably to do with a class method).

2. Add a longer note and an example to our new README.md files at the root of each package.

I see - but a lot of dev's will be using the CMS and less so the Platform/Framework - so I guess there is a need to really shout out the need/ability to do this kinda stuff - I certainly had clue about this before you posted here. I looked through the API/libraries and often just ended up custom coded stuff I'm sure exists within the libraries somewhere!

   

This is what annoys me in a way as a dev is that classes are so constantly being created and then dropped almost immediately (I mean I know web dev is constantly being improved with MySQL/PHP/HTML5/CSS3 updates but even so......)!

You'll have to refresh my memory. I can't recall any classes added and immediately dropped. There is always a lead time before the code is actually removed from the code.

Perhaps not the classes themselves - but in most cases most the functions within them are deprecated (and with the JLog - a popular website can rack up a massive log file of deprecated function usage!)

 

 

Another example being JLog - a brilliant class - but has nothing documented about it. I've ended up creating a wiki page for it ( http://docs.joomla.org/Using_JLog ) but I have bugger all clue how accurate it is! It works in J!2.5 and 3.0 but whether it uses the latest and best coding I have no clue.

http://joomla.github.com/joomla-platform/?chapters/packages/log.md :)

I had seen this - but there are definitely things that confuse me/are missing. For example a category of jerror seems to apply the JApplication->enqueueMessage() function as well - displaying the error - which is nice - yet completely undocumented there! I'm also confused as to the point of the JLog priority levels - its not really explained at all!

 

Completely agreed. And I do sympathise with this. But the CMS (and I think rightly) is focused for 4.x on getting a restful API doc ready so mobile apps etc can be tapped in.  Again the CMS team has 6 months to work on this and component etc updates. And their constantly behind - e.g. its taken them this long to get Layouts implemented - its still mainly mootools rather than jQuery orientated in the backend. I think the PLT needs to look at a longer gap at getting the new x.0 releases supported by the CMS team - perhaps 12 months to that first 4.0/5.0 etc release - because currently going from 3.0->3.1->3.2 is almost like Beta versions for Joomla 3.5 as their just bringing them upto where Joomla 3.0 should have been to start with!!

I think you've got your dates wrong. It's now 2 years between major releases.

I know its 2 years between major releases - but most devs have a version that they don't want to have to edit much by x.0,x.1 of a cycle. So most new classes/edited classes should be in place by then in my opinion! (see my comment above about CB/Kunena).

 

 

I think most dev's are prepared for new JModel/JView/JController Classes coming - so this is your time to introduce sweeping changes if they are needed. But please release them in block rather than a kinda seepage in we seem to be having at the moment - it actually makes it easier because then you can make the sweeping changes in one go - rather than constantly worrying about class changes every time Joomla gets updated (yes there will have to be changes I appreciate - but nothing too significant I would hope!)

What I think needs to happen is for the extension developers to get together and thrash out what they want, when they want it, how fast it should roll out, etc. The PLT can certainly facilitate that conversation, but the ownership of any decisions and forward momentum, in my opinion, needs to come squarely from the extension developers themselves. Where the Framework would fit into a timeline for that to happen, I have no clue. I certainly know what I'd be doing if I was still in big-extension territory, and I'm happy to share those ideas and how the Framework fits in, but I think those ideas would be a bit too radical for most to swallow :)

If you don't put your ideas out there then a compromise can't be found :P There's always going be ideas on both sides of the spectrum - but we can't find a compromise in the middle unless we hear both ends of it. Again I think this talk needs to come now. Pull the big extensions (Phoca, Akeeba, Kunena, CB, JomSocial to name a few major ones) together - but we also need to look at the other end. We need to make sure this stuff will be understandable to a new programmer coming up - its not point, bluntly, having the old farts using Joomla - we need to encourage new programmers to use Joomla! as well.

Kind Regards,

George

[Donald Gilbert]

George, I understand your points and concerns, but you should check your numbers. Out of the 305 classes in the current platform master, only 12 classes have deprecated code. So, it certainly isn't "every other" class.

--
You received this message because you are subscribed to the Google Groups "Joomla! Platform Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-plat...@googlegroups.com.

[Nick Savov]

Hi George,

Joomla 3.1 is a one-click upgrade from Joomla 3.0 with backward
compatibility, so hardly anyone should/will stay on 3.0.

Also, according to Joomla's development strategy
(http://developer.joomla.org/strategy.html), big breaks in compatibility
can't occur until major versions (e.g. 4.0) so it's not really up for
debate as to whether something should be kept in or not. It definitely
should according to the development strategy.

Joomla 3.0 is not a beta version and it is very useable. It's a stable
release and intended for new sites. The proof is in the pudding :)

Hope this helps!

Kind regards,
Nick

>>
>
> See this is the issue to me - there is a difference between developers and
> the Joomla Core! in terms of how the versions work. Now whilst Joomla 3.0
> is about to get dropped for 3.1 etc - realistically - there are always
> people who are going to stay behind on 3.0 - and as developers in an ideal
> world we need to support them as well! Some of the major extensions
> (Kunena, CB etc.) are gearing up extensions for Joomla 3.x and so I'd say
> what's in 3.x at least can't be dropped and will need to stay as is until
> 4.x. And to be honest I would have thought most these extensions - now
> nearly built will now not use these new standards if they were to be
> introduced in 3.2/3.5
>
>
>

[Andrew Eddie]

On 12 March 2013 14:07, George Wilson <georgeja...@googlemail.com> wrote:

If I was being cynical I'd say stakeholders like ebay and ebay and ebay? (as they contribute a fair amount to the development of the Platform and presumably will to the Framework).

As a co-founder of the Joomla project itself, when I say "stakeholder" I literally mean anyone from the person with a single web site through to the likes of Quizilla, and would include you - that's something that comes from investing the last 10 years of myself in this community. I don't discriminate against anyone's contribution on the basis of who employs them - I hope you will learn to share that view. Let's keep the discussion professional and about the technical merits of the code shall we?

Regards,

Andrew Eddie

[Andrew Eddie]

On 12 March 2013 14:07, George Wilson <georgeja...@googlemail.com> wrote:

If you don't put your ideas out there then a compromise can't be found :P There's always going be ideas on both sides of the spectrum - but we can't find a compromise in the middle unless we hear both ends of it. Again I think this talk needs to come now. Pull the big extensions (Phoca, Akeeba, Kunena, CB, JomSocial to name a few major ones) together - but we also need to look at the other end. We need to make sure this stuff will be understandable to a new programmer coming up - its not point, bluntly, having the old farts using Joomla - we need to encourage new programmers to use Joomla! as well.

I think that's what should happen, but that's a discussion to be had on the CMS list (maybe General - hard to decide). The people interested in the Framework aren't going to tell anyone where they should be going, but we'd be more than happy to talk about how to fit into any plan of action. But you are just going to have to accept that some people want to be part of Joomla but the CMS is not the thing they want to be working on.

Regards,

Andrew Eddie

[Amy Stephen]

On Mon, Mar 11, 2013 at 11:07 PM, George Wilson <georgeja...@googlemail.com> wrote:

On Tuesday, March 12, 2013 2:57:52 AM UTC, Andrew Eddie wrote:

On 12 March 2013 12:14, George Wilson <georgeja...@googlemail.com> wrote:

Agreed - sorry if I didn't make this clear enough - but also I'd suggest that Joomla Platform/Frameworks biggest usage will be within the CMS system! 

Right, but it's a bit of a circular line of thought. We have to make the Platform work for the CMS so we can't do anything to the Platform which doesn't work for the CMS. You end up chasing your tail. The Framework, though, is actually starting from scratch - in terms of that actual code, anyone can become the biggest stakeholder.

If I was being cynical I'd say stakeholders like ebay and ebay and ebay? (as they contribute a fair amount to the development of the Platform and presumably will to the Framework).

Wow, George. Wow.

[Amy Stephen]

On Monday, March 11, 2013 9:57:52 PM UTC-5, Andrew Eddie wrote:

On 12 March 2013 12:14, George Wilson <georgeja...@googlemail.com> wrote:

Agreed - but as a dev - I couldn't really see what JInput has bought to the table over JRequest other than the nuisance that I have to check for magic quotes before I choose which to use in a extension!!! For example even my website (as a dev) - is on PHP 5.3 - admittedly I'm going to upgrade soon - but so many people will be on earlier versions who just aren't aware. As an extension dev I have to think of backward compatibility for the old PHP versions!

The change was architectural. JInput allows for dependancy injection (best practice) whereas JRequest was a glorified globals container (hard to test, dev's doing naughty things with it, etc).

 

George - not sure if you understood the implications of Andrew's point? You asked the question, he answered, but then, the discussion took a non-productive turn.

There is a lot in his short comment that you could use to understand if that's your goal, and I do believe it is your goal. Start by reviewing "dependency injection" and "static" classes. What does he mean when he says "glorified globals container?" How is it hard to test? Why does that matter? What "naughty things" can developers do with JRequest that Andrew seems to be suggesting can't be done with JInput?

Did you notice how the class name was changed, too? Is that good or bad? And, how so?

That kind of analysis will lead to learning that helps you as a developer.

I'm serious - I'd like to see your response to Andrew's answer to your question. Is that change the type of improvement beneficial to this community? Are there better ways to introduce the change, assuming you agree with the reasoning.

We could use critical thinking in this community. Takes more time but in the end you'll benefit from that approach, I promise.

[George Wilson]

On Tuesday, March 12, 2013 4:45:28 AM UTC, Nick Savov wrote:

Hi George,

Joomla 3.1 is a one-click upgrade from Joomla 3.0 with backward
compatibility, so hardly anyone should/will stay on 3.0.

Should and will are two different cups of tea. Just basing on questions on StackOverflow/Dev Forums etc. There is still a small yet significant minority who still use J!1.6 and 1.7 - now as I recall (could be wrong here one click updates arrived in 1.7 - so I guess there may be an excuse for those on J!.6 - but certainly not for J!1.7. Just asking people around on there why their on outdated versions - nearly every time it's because they think an extension and/or template will break compatibility as soon as they upgrade! I'm well aware this isn't/shouldn't be the case - but you can only tell the people who ask on there. I'm sure there are many more people who have had sites made for them on Joomla who have decided not to upgrade any aspect of their site for fear of compatibility issues.

 

Also, according to Joomla's development strategy
(http://developer.joomla.org/strategy.html), big breaks in compatibility
can't occur until major versions (e.g. 4.0) so it's not really up for
debate as to whether something should be kept in or not.  It definitely
should according to the development strategy.

I am well aware of this!! But even deprecating something like JDoc/JDatabase on a popular website could still run up a huge log file of deprecated code

 

Joomla 3.0 is not a beta version and it is very useable.  It's a stable
release and intended for new sites.  The proof is in the pudding :)

Again I know its usable and stable (as most the minor bugs seem to have been ironed out over the 3 sub releases) - however stuff like using JLayout and the backend using (give or take) Mootools for a lot of data processing (I see theirs been a move to try and get someone from GSOC to work on this) - should have been done for 3.0. I understand your working with a limited number of people - but if their available to use - I kinda feel that it would be worth delaying the release for an extra few months to allow use of them fully. I am very aware though it's easy to say this but much harder to act on it i

Kind Regards,

George

[George Wilson]

On Monday, March 11, 2013 9:57:52 PM UTC-5, Andrew Eddie wrote:

On 12 March 2013 12:14, George Wilson <georgeja...@googlemail.com> wrote:

Agreed - but as a dev - I couldn't really see what JInput has bought to the table over JRequest other than the nuisance that I have to check for magic quotes before I choose which to use in a extension!!! For example even my website (as a dev) - is on PHP 5.3 - admittedly I'm going to upgrade soon - but so many people will be on earlier versions who just aren't aware. As an extension dev I have to think of backward compatibility for the old PHP versions!

The change was architectural. JInput allows for dependancy injection (best practice) whereas JRequest was a glorified globals container (hard to test, dev's doing naughty things with it, etc).

 

George - not sure if you understood the implications of Andrew's point? You asked the question, he answered, but then, the discussion took a non-productive turn.

There is a lot in his short comment that you could use to understand if that's your goal, and I do believe it is your goal. Start by reviewing "dependency injection" and "static" classes. What does he mean when he says "glorified globals container?" How is it hard to test? Why does that matter? What "naughty things" can developers do with JRequest that Andrew seems to be suggesting can't be done with JInput?

Hi Amy, I did go and research this actually to an extent. I looked up this question on SO as I have to admit I hadn't heard the term "dependency injection before".

http://stackoverflow.com/questions/130794/what-is-dependency-injection

and this on Static classes which I'd heard of but never properly gone into before.

http://stackoverflow.com/questions/902909/php-static-function 

I've also looked at various bits and bobs on the docs site in the past - although refreshed my memory on this one in particular:

http://docs.joomla.org/Retrieving_request_data_using_JInput#Background 

However in some ways (and I know this sounds awful) I'm not all that fussed about the way the classes work - I do all my dev work around my uni work/placement job and I simply don't have time to understand everything. So as my basis - I try and make sure I understand how to use a class. Joomla Docs has facilitated this to a large extend by way of examples and a brief glance through a function every now and then to aid this. I know this isn't the best way to code in any way - but with time pressures I have its just the way I've chosen to go.

I don't dispute that JInput may well (in a internal code way) be better than JRequest - however many of it's properties seem to be give or take the same. I looked through JRequest once before to see how they dealt with magic quotes - and it seemed to be a 3 line function and a call to that function (from memory) - so I can't see why this behaviour couldn't enter JInput (especially as J!2.5 was still advocating the use of turning magic quotes on!! http://docs.joomla.org/Magic_quotes_and_security - note the advice to turn it off for J2.5 was only added in February this year). And so the only reason I can see why JInput was put in as a new class was because that it didn't make it into 1.6 and thus as it was going into 1.7 and there was a backwards compatibility feature with magic quotes and a few other of the more minor features and thus you needed to keep both JRequest and JInput in the source.

Did you notice how the class name was changed, too? Is that good or bad? And, how so? 

That kind of analysis will lead to learning that helps you as a developer.

I'm serious - I'd like to see your response to Andrew's answer to your question. Is that change the type of improvement beneficial to this community? Are there better ways to introduce the change, assuming you agree with the reasoning.

We could use critical thinking in this community. Takes more time but in the end you'll benefit from that approach, I promise.

Anyhow I feel I've completely moved off topic anyhow from Concerns about the Platform change to framework to some kind of complaints class. So I'll probably shut up here. Apologies for any offence caused by my comment about eBay - I certainly didn't mean any - I did say I was being cynical! And thanks for clearing up the questions I had. Will be interesting to see where the Framework goes from here.

Kind Regards,

George

[Amy Stephen]

George -

The point I hoped to make is that object oriented programming is pretty complicated. I am saying this with 30 years in the business as I am just now beginning to get my head around some of these patterns and approaches.

When Joomla 1.5 was written, there were great and not-so-great design choices made. Fixing problems is not easy or quick but it is done with careful thought about impact -- that's the reason for the two classes.

It's likely most people will never understand why certain changes were made, either, because understanding the reason for these changes requires one understands some pretty challenging concepts. It matters that these fixes are made.

Sounds to me like you are on the right track for learning. Anyone who is finding a way to help - like you are in the documentation area - is going to get there and your work is much appreciated.

Here are good 'general purpose' resources that explain some of the concepts that the platform team is grappling with. Sometimes, I find I have to read something, then return to it again later when my understanding has grown. Over time, some of it starts to sink in.

Dependency Injection
I think Rob Allen's post "What problem does dependency injection solve?" is excellent in simply describing the purpose and value of this approach. It helped me start to get a better grasp on the topic.

http://akrabat.com/zend-framework-2/what-problem-does-dependency-injection-solve/

Deeper study:
http://martinfowler.com/articles/injection.html
http://picocontainer.codehaus.org/

Static Methods
Chris Hartjes, goes by Grumpy Programmer,
https://github.com/chartjes/grumpy-phpunit/blob/master/phpunit-for-grumpy-developers.markdown#managing-global-state

PHP Unit author
http://sebastian-bergmann.de/archives/883-Stubbing-and-Mocking-Static-Methods.html

Must read for any PHP dev
http://www.phptherightway.com/

Others may have more links - lots of good material out there.  Other areas to explore include usage of Interfaces,  the concept of coupling vs cohesion.

Appreciate your comments, George.

[Viktor Iwan]

Hi.. I am bit new in platform.. But have been with the cms for 2 years.. I just dig deeper with joomla since i bought "joomla! programming book" last year. It took a quite learning curve to get a grip with the mvc, design pattern, etc.. But for now i can already made few simple extension and stand alone apps with platform

One of my concern, will new framework (which likely  writing from scratch)  will using entirely new approach to build things (design pattern, mvc, etc)?

I believe the one that been planed will give more robust feature... Will this make devs write codes shorter and quickers ?

If this will be entirely new... Is it the same as if you stop current joomla development (perhaps up to 3.1) and you build entirely new framework and by coincidence you re-brand it as joomla again since all main devs is the same devs that build joomla (up to 3.1) and the devs will offer the migration between 'old' joomla to 'new' joomla ?

Sent from my iPad

[Andrew Eddie]

On 13 March 2013 05:48, Viktor Iwan <vic...@doxadigital.com> wrote:

One of my concern, will new framework (which likely  writing from scratch)  will using entirely new approach to build things (design pattern, mvc, etc)?

Hi Victor

You will still be using an MVC approach in applications that you will build, and in the future extensions. But, as Amy has already pointed out, one of the new principles that the Framework will pivot around is dependancy injection. What we are doing is removing things like JFactory and JRequest, which are more or less super-global containers, and injecting objects into the classes.

You can see this in recent changes I've made to the database Driver class (setting a PSR-3 logger rather than calling the static JLog methods) or the Model\Database class (you must inject a database Driver - it won't let you default to some mysterious Factory::getDbo method).

All this is done, as Amy points out, so we can one day swap out chunks of code. It also makes individual packages infinitely easier to write tests for.

 

I believe the one that been planed will give more robust feature... Will this make devs write codes shorter and quickers ?

It's still early days and I've got to be honest, I think the interest in the Framework leans towards building web services than building components or modules. However, that does not mean to say the code, or strategies we will be developers will not be useful for components in the future, or even now.

For example, if I was writing a component now, knowing what I know about building web services, I would be building all my models and controllers to be isolated from the application that was calling them. In other words, the logic that handles my data can easily be plugged into a web services framework, or a Joomla component. That's the type of thinking we are developing at the moment. It's early days though so we don't have all the answers - it's going to take quite a but of experimentation.

[Andrew Eddie]

Sorry, my mail app. had a crazy moment.

On 13 March 2013 05:48, Viktor Iwan <vic...@doxadigital.com> wrote:

If this will be entirely new... Is it the same as if you stop current joomla development (perhaps up to 3.1) and you build entirely new framework and by coincidence you re-brand it as joomla again since all main devs is the same devs that build joomla (up to 3.1) and the devs will offer the migration between 'old' joomla to 'new' joomla ?

What I hope to see, over time, from making all these changes is this:

1. That making the Framework available on Composer generates interest in the wider PHP community and people who wouldn't normally think about using Joomla code at all.

2. That breaking the Framework into isolated packages will allow each package to evolve more easily than if all packages are tied to a single, monolithic release.

3. That breaking the Framework into packages will allow the CMS, in the future, to just upgrade the parts of the Framework it needs at the time. At the moment, the CMS needs to take a single version of the Platform and you can't upgrade it in previous versions of the CMS. For example, wouldn't it be great if Joomla 2.5 and Joomla 3.0 could run on the same version of the Platform?  That's impossible to do now but is possible in the future with the new arrangement.

4. That removing all the deprecated code and the last remaining "CMS code" allows us to concentrate on doing things better rather than constantly battling with the question of "will this break the current CMS". It was going to be impossible for the CMS to upgrade to 13.1 anyway, so it makes sense to make a major break in compatibility now.

5. That using Composer and more modern development practices will attract new developers to Joomla project itself, including to the CMS.

6. That when the CMS is ready to do a technical refresh on its architecture, all the experimentation and work we are doing on the Framework now will be ready and tested for the CMS to embrace.

That's my grand vision of what we will be seeing hopefully over the next year or two. This is not going to happen overnight - it's going to take some time.

My hope would also be that the conversation about FoF recently on the CMS list will continue and galvanise many extension developers to start working together (and I emphasise "working together") to work out a system where they can have a new layer, a reliable layer that sits between the Joomla CMS application and their extensions and that can be upgraded across major versions of the CMS - that is, you can put that layer in 2.5 and 3.x or 4.x and upgrade it in each version. That makes it trivial to allow extensions to run on difference major versions without changing a line of code (template frameworks could still be a problem, like the change to Bootstrap, but hey, you have to start somewhere).

So taking that thought further, it would seem obvious to consider using the Framework for this "new thing", this new layer that extension developers should come to rely on. Yes, the code itself will be new, and you'll have a lot of rewriting to do, but the prize at the end of doing that, IF the extension developers work together on this, will be worth it. If you make it so this layer allows your extension to work in the Joomla CMS, or in a web services layer also without changing a single line of code, then that will be an amazing feature of engineering. Joomla becomes known not only for a way to builds web site, but it becomes a name synonymous with being the best way to deliver content to any type of device or client.

If we can achieve that in the next three years, that will be pretty darn cool :)

This is just the first step. Not much is going to change tomorrow or the next day or even in Joomla 3.1. It's business as usual. But by the middle of the year, we'll have a good code base with many issues ironed out and we can start talking about what's next for the Joomla project as a whole.

Hopefully that helps paint one version of the big picture that I think is possible :)

Regards,

Andrew Eddie

 

[Nick Savov]

Thanks Andrew! That was a good overview :)

Kind regards,
Nick

[Viktor Iwan]

I guess this is where the root of a lot of disagreement occurs.... VISION

 

Like me, and probably lot of other 3rd devs in Joomla is they don't get the VISION from the core devs. Up till now, i'm thinking that the main objective of joomla is to deliver the best experience and flexibility to build CMS based website, and the Platform is born to 'attract' more dev that has no experience in the CMS to build the solution in 'the CMS way'.

 

This is why many dev comparing  development in joomla with wordpress, coz  in build 'extension'  in wordpress is quicker and easier , especially when devs using custom post type (eventhough the scalable and standard is pretty bit awful).... but now i see wordpress and joomla have very different vision.

 

This is also reason why by default joomla don't have built-in CCK/Custom field, so some of my 'old joomla' friend now moving to cms like processwire ... because it has build-in custom field to build website easier.. but this is just because it has different vision from joomla.

 

In the future, i'm seeing Joomla as a system with tons of flexibility (cms, stand alone, web services, mobile apps. you name it...) with recent technology and best practices (through new design pattern, dependency injection..). One of the big cons is joomla will have lesser community as i believe a lot of devs doesn't require that advanced concept as they simply making money by create company profile/catalog/portfolio website for their client.

Brand positioning is very important and i think there will be shifting in the future...

 

if you take a look at our 'marketing ads' here http://www.youtube.com/watch?feature=player_embedded&v=Qjnc0H8utks#!

we brand joomla as one of the most world popular CMS platform, while i see in this discussion, you don't wanna people have mindset to  see joomla as CMS alone...

 

 

 

 

 

So taking that thought further, it would seem obvious to consider using the Framework for this "new thing", this new layer that extension developers should come to rely on. Yes, the code itself will be new, and you'll have a lot of rewriting to do, but the prize at the end of doing that, IF the extension developers work together on this, will be worth it. If you make it so this layer allows your extension to work in the Joomla CMS, or in a web services layer also without changing a single line of code, then that will be an amazing feature of engineering. Joomla becomes known not only for a way to builds web site, but it becomes a name synonymous with being the best way to deliver content to any type of device or client.

 

If we can achieve that in the next three years, that will be pretty darn cool :)

 

This is just the first step. Not much is going to change tomorrow or the next day or even in Joomla 3.1. It's business as usual. But by the middle of the year, we'll have a good code base with many issues ironed out and we can start talking about what's next for the Joomla project as a whole.

 

Hopefully that helps paint one version of the big picture that I think is possible :)

 

Regards,

Andrew Eddie

 

--

[Andrew Eddie]

On 13 March 2013 14:55, Viktor Iwan <vic...@doxadigital.com> wrote:

I guess this is where the root of a lot of disagreement occurs.... VISION

This is very true.

 Like me, and probably lot of other 3rd devs in Joomla is they don't get the VISION from the core devs.

It depends on what you mean by "core devs". They haven't actually officially existed since 2009. The best way to find a "core dev" nowadays is to look in the mirror - you'll find at least one potential candidate.

Up till now, i'm thinking that the main objective of joomla is to deliver the best experience and flexibility to build CMS based website, and the Platform is born to 'attract' more dev that has no experience in the CMS to build the solution in 'the CMS way'.

I would imagine many people would agree with you, but it's actually not the mission as stated by the project. The mission is not to "exclusively" build the best CMS in the world. That can be an outcome but we should not be giving those developers a hard time about wanting to do more with the Joomla code. If that's the case, then we should be telling Michael to stop work on the new Joomla issue tracker because it's not a CMS. I will certainly need to go look for a new project to contribute to :)

This is why many dev comparing  development in joomla with wordpress, coz  in build 'extension'  in wordpress is quicker and easier , especially when devs using custom post type (eventhough the scalable and standard is pretty bit awful).... but now i see wordpress and joomla have very different vision.

I actually can't find WordPress's published vision or mission but I suspect WP would revolve around making a really cool website for publishing content. That's quite different from Joomla's mission. 

This is also reason why by default joomla don't have built-in CCK/Custom field, so some of my 'old joomla' friend now moving to cms like processwire ... because it has build-in custom field to build website easier.. but this is just because it has different vision from joomla.

We don't have a built in CCK because nobody has ever contributed one. 

In the future, i'm seeing Joomla as a system with tons of flexibility (cms, stand alone, web services, mobile apps. you name it...) with recent technology and best practices (through new design pattern, dependency injection..). One of the big cons is joomla will have lesser community as i believe a lot of devs doesn't require that advanced concept as they simply making money by create company profile/catalog/portfolio website for their client.

One of the great things about Mambo is it made complex things seem easy. I think we've gone off-track in recent years. Access control is one example where a few people asked for it and it made things infinitely more complex (I did warn everyone that would be the case). Does that mean things can't change? Of course not, but I believe part of the solution is for users and extension developers to work together more than they are now.

we brand joomla as one of the most world popular CMS platform, while i see in this discussion, you don't wanna people have mindset to  see joomla as CMS alone...

Sure, but there seems to be this mindset that the Joomla developer community can only work on one thing - the CMS and the Platform/Framework is like some cancer that needs to be lanced to get us back on the one true path. Nobody here is stopping anyone from improving the CMS. The existence of the Platform or the Framework or whatever we call it is not stopping people from making pull requests against the CMS. It's up to you guys that are investing in the CMS to protect your investment. The CMS is lacking a strong developer pool at the moment - it's time for some new people to step up and fill that gap and cast their own visions for what the CMS could become. We on the Framework will be around when you find you need better code to make it all happen :)

Regards,

Andrew Eddie

[George Wilson]

Having said I'm not going to comment - I thought this was too interesting to not make a comment on (sorry!). I think what Viktor said was exactly what I was trying to say - just with much better wording!!

On 13 March 2013 05:43, Andrew Eddie <mamb...@gmail.com> wrote:

On 13 March 2013 14:55, Viktor Iwan <vic...@doxadigital.com> wrote:

Up till now, i'm thinking that the main objective of joomla is to deliver the best experience and flexibility to build CMS based website, and the Platform is born to 'attract' more dev that has no experience in the CMS to build the solution in 'the CMS way'.

I would imagine many people would agree with you, but it's actually not the mission as stated by the project. The mission is not to "exclusively" build the best CMS in the world. That can be an outcome but we should not be giving those developers a hard time about wanting to do more with the Joomla code. If that's the case, then we should be telling Michael to stop work on the new Joomla issue tracker because it's not a CMS. I will certainly need to go look for a new project to contribute to :)

You can't have the best CMS system without a way to report bugs and request new features! Just saying.

This is also reason why by default joomla don't have built-in CCK/Custom field, so some of my 'old joomla' friend now moving to cms like processwire ... because it has build-in custom field to build website easier.. but this is just because it has different vision from joomla.

We don't have a built in CCK because nobody has ever contributed one. 

But what I've found hard to find is what DOES Joomla want?? Elin said the other day on the CMS group that "Who knows what code there will be contributed to the CMS in the next 3 months and what people will do with it or what will come after that. I think what she says there is important - in that Joomla (CMS anyhow) seems to have lost track of a direction. In terms of new features you submit something and more than a couple of people want it it will be included. I'm seems from the CMS group for example that there are 2/3 teams all working on a UCM model for Joomla - 1 for framework perhaps 2 on the CMS team - and whoever finishes first gets it put in - without looking at what everyone else is doing and pooling all the resources together!

The good thing about the core devs before was that it meant Joomla had a definite path. I haven't been to the conferences - and I know that a lot of things do get discussed there. But sometimes you feel that Joomla CMS decides on something when the github pull comes through - not saying to a group of people - this is what we want - go off research it and come back with a base layer of code that we can work on. I'm sure if we sent off a volunteer group of devs to build a CCK editor it could be done before 3.5 comes out! Instead we're sitting around saying well perhaps a UCM model etc.

In the future, i'm seeing Joomla as a system with tons of flexibility (cms, stand alone, web services, mobile apps. you name it...) with recent technology and best practices (through new design pattern, dependency injection..). One of the big cons is joomla will have lesser community as i believe a lot of devs doesn't require that advanced concept as they simply making money by create company profile/catalog/portfolio website for their client.

One of the great things about Mambo is it made complex things seem easy. I think we've gone off-track in recent years. Access control is one example where a few people asked for it and it made things infinitely more complex (I did warn everyone that would be the case). Does that mean things can't change? Of course not, but I believe part of the solution is for users and extension developers to work together more than they are now.

Actually I'd say ACL is the one big thing that has bought Joomla on BIG time since Joomla 1.5!! It makes things so so much easier as a extension dev

 

we brand joomla as one of the most world popular CMS platform, while i see in this discussion, you don't wanna people have mindset to  see joomla as CMS alone...

Sure, but there seems to be this mindset that the Joomla developer community can only work on one thing - the CMS and the Platform/Framework is like some cancer that needs to be lanced to get us back on the one true path. Nobody here is stopping anyone from improving the CMS. The existence of the Platform or the Framework or whatever we call it is not stopping people from making pull requests against the CMS. It's up to you guys that are investing in the CMS to protect your investment. The CMS is lacking a strong developer pool at the moment - it's time for some new people to step up and fill that gap and cast their own visions for what the CMS could become. We on the Framework will be around when you find you need better code to make it all happen :)

I don't disagree that the Platform/Framework is important to Joomla! But only if the two groups work together - if they are not working together - there seems little point in having the Platform/Framework and just spinning it off as its own thing (as most people know Joomla for the CMS not the Platform/Framework). The reason I got into Joomla in the first place was it made making stuff simple. Making a database query was easy in 4 lines your could retrieve give or take anything you want from the database:

$db=JFactory::DBO();

$query="SOME MYSQL QUERY";

$db->setQuery($query)

$row=$db->loadRow()

If I wanted to get the details of a user:

$user= JFactory::getUser()

Point being it was so simple - in just a few lines of code I could do anything (admittedly by using an awful lot of JFactory which I can believe has a lot of dodgy code in. Now I've got to dig through the JUser class (or its replacement) to find details on a user. Start grabbing the database from a load of injections and sifting through (a potentially new) JDatabase class. Now it seems less so and I feel at the expense of bringing in complex coders we're alienating your average Joe from being able to make a simple extension to finish a website they might be creating or even getting into Joomla! in the first place. One of the best things with Joomla 1.5/2.5/3.x is that it is so simple to be able to jump on-ship and I fear the direction of framework is going to mean we will loose this at some point in the not too distant future!

Just on a side note out of interest when you said you were using "PSR-3 logger rather than calling the static JLog methods" does that mean we'll be deprecating JLog in the near('ish) future??

Kind Regards,

George

P.S. Amy thanks for the links - I'll defo be reading through them when I get some spare minutes!!!

[Andrew Eddie]

On 13 March 2013 20:10, George Wilson <georgeja...@googlemail.com> wrote:

We don't have a built in CCK because nobody has ever contributed one. 

But what I've found hard to find is what DOES Joomla want??

David Hurley, if all goes well, will be announcing a draft roadmap at the Boston Joomla Day this weekend. Whether people agree with it or not is another matter, but hopefully we score one point for trying.

 

Elin said the other day on the CMS group that "Who knows what code there will be contributed to the CMS in the next 3 months and what people will do with it or what will come after that.

You don't remember the days when the community could not do that and you were at the mercy of two or three devs with commit access :)

 

I think what she says there is important - in that Joomla (CMS anyhow) seems to have lost track of a direction. In terms of new features you submit something and more than a couple of people want it it will be included. I'm seems from the CMS group for example that there are 2/3 teams all working on a UCM model for Joomla - 1 for framework perhaps 2 on the CMS team - and whoever finishes first gets it put in - without looking at what everyone else is doing and pooling all the resources together!

If you say so, but I'm not aware of three separate teams working on UCM. We have a "version 1.0" cut that eBay pushed out last year. It's "ok" and you could certainly use it as a basis for a content extension if you wanted - but I wouldn't recommend it. I'm working on the 3rd generation version and hope to have something to look at by mid-year. If people use it, great.

 

The good thing about the core devs before was that it meant Joomla had a definite path.

The bad thing is nobody else could contribute. It's why 1.5 took 3 years to develop (yes, 1.6 took about the same time the historic reasons why are different).

 

I haven't been to the conferences - and I know that a lot of things do get discussed there. But sometimes you feel that Joomla CMS decides on something when the github pull comes through - not saying to a group of people - this is what we want - go off research it and come back with a base layer of code that we can work on. I'm sure if we sent off a volunteer group of devs to build a CCK editor it could be done before 3.5 comes out! Instead we're sitting around saying well perhaps a UCM model etc.

Again, that's something to address on the CMS list. I sympathise with what you are saying but the purpose of this list is not to solve all the CMS's logistical or contribution problems.

 

I don't disagree that the Platform/Framework is important to Joomla! But only if the two groups work together - if they are not working together - there seems little point in having the Platform/Framework and just spinning it off as its own thing (as most people know Joomla for the CMS not the Platform/Framework).

Who says they are not working together, or going to work together? Not I, said the fly. What we have said is that we need to make some major changes because of namespacing and because of new developments in the PHP community at large. I can understand that if you are not familiar with or aware of these things it can sound scary, but it doesn't mean the world as we know it will come to an end.

 

The reason I got into Joomla in the first place was it made making stuff simple. Making a database query was easy in 4 lines your could retrieve give or take anything you want from the database:

$db=JFactory::DBO();

$query="SOME MYSQL QUERY";

$db->setQuery($query)

$row=$db->loadRow()

If I wanted to get the details of a user:

$user= JFactory::getUser()

Yep, and when you learn about unit testing and dependency injection you'll know why we are running away from that kind of format very, very fast. Unfortunately for you some people in the community had the vision that the CMS should run on something other than MySQL.

But you realise I'm the guy that wrote a lot of the database layer in the first place to make it easy for dev's to use? Have some faith that I and others will get it right a second time :) I'm a lazy developer at heart and I really don't like making things harder than they need to be.

 

Now I've got to dig through the JUser class (or its replacement) to find details on a user.

*sigh* JUser and JFactory are still very much alive and in the CMS core. I can't stress enough that your extensions are still going to work when we published FW1.0 (there's no magical quantum entanglement happening here to suddenly break your code). What happens after that is really up to the likes of you. Do you want the new Framework code or not in the CMS? - the choice is yours.

 

Start grabbing the database from a load of injections and sifting through (a potentially new) JDatabase class. Now it seems less so and I feel at the expense of bringing in complex coders we're alienating your average Joe from being able to make a simple extension to finish a website they might be creating or even getting into Joomla! in the first place. One of the best things with Joomla 1.5/2.5/3.x is that it is so simple to be able to jump on-ship and I fear the direction of framework is going to mean we will loose this at some point in the not too distant future!

And you wonder why we are in no hurry to push this into the CMS. That is not a signal that we are not prepared to work together, it's just a reality that we need time to sort out how to "package" (pun intended) this stuff so extension developers will get it and not break it :)

 

Just on a side note out of interest when you said you were using "PSR-3 logger rather than calling the static JLog methods" does that mean we'll be deprecating JLog in the near('ish) future??

You need to ask the CMS about what it's going to do with any of the platform code. As far as the Joomla\Log package goes, for now it will be published and hopefully "someone" (I believe Rouven is having a crack) will make it PSR-3 compliant.

George, can I please ask that you defer questions about the future of the CMS to the CMS list where the people that are more closely involved in that piece of software can address your concerns (they are valid, they need to be talked about, we this is the wrong place). At the moment, we really want to focus on getting the Framework right. If you aren't ready for namespacing and Composer and all that stuff, that's fine - we'll be here when you are ready. You really need to be getting together with other extension developers and working out what "you" want for the Joomla CMS. When you do, I hope the Framework will fit into your plans and we'll be here to help you over the line (but it not, we aren't going to force the code down your neck).

Regards,

Andrew Eddie

[Viktor Iwan]

 

 

From: joomla-de...@googlegroups.com [mailto:joomla-de...@googlegroups.com] On Behalf Of Andrew Eddie

I actually can't find WordPress's published vision or mission but I suspect WP would revolve around making a really cool website for publishing content. That's quite different from Joomla's mission. 

[>>] Yes, i fully understand now that joomla by its vision never tried to  'compete' with wordpress or drupal in term of content publishing.. this is where many dev mislead right now...

 

We don't have a built in CCK because nobody has ever contributed one. 

[>>] There are people from france, octopoos team, who did a very great job to "extend" joomla with CCK with component named SEBLOD, they are my time saver as they build great gui for custom field to make drag 'n drop system for authoring when  build sites, it using #__content.... Well, to be honest, i'm bit concern about the component existence in future for two reason : need to recompile/recode and the CMS part is lack of support since all the geniuses is working on the framework right now

 

One of the great things about Mambo is it made complex things seem easy. I think we've gone off-track in recent years. Access control is one example where a few people asked for it and it made things infinitely more complex (I did warn everyone that would be the case). Does that mean things can't change? Of course not, but I believe part of the solution is for users and extension developers to work together more than they are now.

[>>] I believe what you preparing here is what it required in the future, i begin to receive calls from prospect where they need to port their site with web service rather than php-mysql db calling , or convert site into mobile apps... this is where the CMS can't answer those needs... but again this "status quo" vs innovation is more like "comfort zone" vs innovation...

 

The CMS is lacking a strong developer pool at the moment - it's time for some new people to step up and fill that gap and cast their own visions for what the CMS could become. We on the Framework will be around when you find you need better code to make it all happen :)[>>]

[>>] Ahh bad news... the challenge to create Rich, Powerful, Flexible and Robust  CMS/Publishing content... doesn't look sexy anymore for majority here.. :) ... i still dream  there will be front-end editing, include drag 'n drop layout structuring, etc.. something that will make end user drop their jaws and i will simply said it with my coolest voice tone "well, it's joomla".. kaching !... ha ha ha... wish i can contribute in CMS sooner or letter, but consider me as the beginner/"user" developer... i tried to see the CMS source code, and its all beyond my mind...

 

 

[Amy Stephen]

It's always fun to talk about the future of Joomla, especially to get Mr. Joomla's take on things. But, it gets to be a time issue, too, so let's not turn this into a philosophical discussion that doesn't end and requires long responses from Andrew.

Mainly, I wanted to make certain extension developers remember that if they have questions - like why are you doing XYZ?, or how come you are deprecating A? That we all get back into a habit of asking those quick questions on list instead of assuming bad things and feeling like there is no sense in trying to ask a question.

If you are an extension developer who has a concern or specific question on an API change, etc., just post in and ask your specific question. It will be answered.  Business, as usual. =)

--
You received this message because you are subscribed to a topic in the Google Groups "Joomla! Platform Development" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/joomla-dev-platform/4Q0eu4G7NWI/unsubscribe?hl=en.
To unsubscribe from this group and all its topics, send an email to joomla-dev-plat...@googlegroups.com.