As part of this thread, Sam Moffatt proposed a way forward that allows for a high degree of backward compatibility (b/c) but still allows the platform to use the preferred names. After discussing this in the Production Leadership Team, we believe that this proposal is a reasonable way forward. The purpose of this post is to clarify the details of the proposal and get feedback from the community before making a final decision.
Here is an outline of how this would work.
Starting with version 2.5.5 or 2.5.6, three new classes would be created in the libraries/joomla/application folder called JModelLegacy, JViewLegacy and JControllerLegacy. For version 2.5.x, these would be empty classes that simply extend JModel, JView, and JController. In addition, any core classes that currently extend JModel, JView, and JController would be changed to extend the new legacy classes. Bear in mind that this change to core is a very simple search/replace of two words in each file (the jimport line and the extends line). All 2.5 extensions will continue to work in 2.5 without any changes.
In Version 3.x, this would continue unchanged (except that all of the cms-related files will likely move to the libraries/cms folder). However, the new platform will add JModel, JView, and JController implemented as interfaces. So, for example, we will have 2 files that define JModel, one in the cms folder that defines the old (2.5) class and one in the platform that defines the new interface. How would this affect existing extensions?
- Any extension using the new legacy classes would be totally unaffected.
- Any extension using classes that extend the old JModel, JView, and JController would continue to work as long as (a) they continue to explicitly load the parent class files (which they are doing already) and (b) they are not mixing the use of the old class names and the new interface names in the same request cycle. (In other words, there would only be a problem if somehow both the old and new MVC styles were being mixed in the same page. In any case, the simple fix would be to modify the classes to extend the new legacy versions of the MVC base classes.)
Hi all
To me, the sticky point appears to be:
"(b) they are not mixing the use of the old class names and the new
interface names in the same request cycle."
gue
Hey
I read the long posts, the cons & pros. I really like the new
MVC which take us forward, but I don't understand why we push this
b/c issue, if we can avoid it easily by another name convention.
It's easy to say 3rd party developer have enough time to migrate,
but why to make them work, if we can make their life easier.
Remind for our
developer strategy for backward compatibility - it doesn't
look like we treat it as important, and more critical - we can't
use both implementations at the same request.
So the simple (technical) question that I could not find answer
in the long posts - why we don't use JXXXXInterface? I know
another frameworks use this name convention (Zend, Java).
Of course, I don't want to be the party pooper, but just want to
clarify this issue.
Ofer Cohen TP2 - The new way to manage your modules
On 10/05/12 19:48, Mark Dexter wrote:
In a recent thread in the Platform list (http://groups.google.com/group/joomla-dev-platform/browse_thread/thread/422903a9385f14de) there was a long discussion about an important pull request in the platform. The thrust of this pull request is to make significant changes to the MVC implementation in the platform.
A major point of concern in this discussion was the proposal to use the names JModel, JView, and JController for the names of the new interfaces. The concern expressed was that re-using these names would cause unnecessary backward-compatibility (b/c) issues with existing third-party extensions.
As part of this thread, Sam Moffatt proposed a way forward that allows for a high degree of backward compatibility (b/c) but still allows the platform to use the preferred names. After discussing this in the Production Leadership Team, we believe that this proposal is a reasonable way forward. The purpose of this post is to clarify the details of the proposal and get feedback from the community before making a final decision.
Here is an outline of how this would work.
Starting with version 2.5.5 or 2.5.6, three new classes would be created in the libraries/joomla/application folder called JModelLegacy, JViewLegacy and JControllerLegacy. For version 2.5.x, these would be empty classes that simply extend JModel, JView, and JController. In addition, any core classes that currently extend JModel, JView, and JController would be changed to extend the new legacy classes. Bear in mind that this change to core is a very simple search/replace of two words in each file (the jimport line and the extends line). All 2.5 extensions will continue to work in 2.5 without any changes.
It is important to understand that these changes will not affect any third-party extensions for 2.5. Extensions that use JModel, JView, and JController will continue to work without any modifications. These changes just provide 3pd�s the option to make changes in 2.5.x to prepare for 3.0. The purpose of this change in 2.5 is to allow extension developers to modify their extensions now so that they will be unaffected by platform changes introduced in version 3.0.
b/ or in effect prevent developers to use new MVC, for fear of
conflicts: development based on new MVC starts only for 4.0, a couple
of years from now
On 14 May 2012 17:17, shumisha <shum...@gmail.com> wrote:
I think you are worried about a different problem. Can you give me a
> So the discussion is relevant and the conflict will happen a lot.
code example of the conflict you perceive?