Proposal on New MVC Classes and Backward Compatibility

[Mark Dexter]

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.

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.)
• Note also that any classes that extend child classes (such as JModelAdmin or JModelList) would be entirely unaffected (since these will now be extending the legacy classes).

In version 4.x, the old JModel, JView, and JController class files would be removed and the code would be moved to the legacy versions. At that point, any extensions using the legacy MVC classes would have to change their classes to extend the legacy classes (the same simple change that was done in core for 2.5.5 or 2.5.6). At some point in the future, support for the legacy MVC might be dropped, but that decision will not need to be made until after 3.5 is released.

To the PLT, this approach seems to be a reasonable compromise between allowing a high degree of backward compatibility and still allowing the project to move forward with optimal file naming conventions. Extension developers can make a very simple change now to provide for forward compatibility. Even without these simple changes, 2.5 extensions will likely work in the great majority of situations for 3.x.

Please let us know what you think and whether we have missed some important aspect of this. Thanks!

[David-Andrew]

As a  non-developer: sounds good to me.

Thank you PLT, for opening this up for discussion!

Op donderdag 10 mei 2012 18:48:41 UTC+2 schreef Mark Dexter het volgende:

[Niels Braczek]

Am 10.05.2012 18:48, schrieb Mark Dexter:

> Please let us know what you think and whether we have missed some important

> aspect of this. Thanks!*

I was one of the people speaking against the "clear" interface naming.
Nevertheless, I've been satisfied and vote *for* the proposal.

Regards,
Niels

--
| http://barcamp-wk.de · 1. Barcamp Westküste 30./31. März 2012 |
| http://www.bsds.de · BSDS Braczek Software- und DatenSysteme |
| Webdesign · Webhosting · e-Commerce · Joomla! Content Management |
------------------------------------------------------------------

[Rouven Weßling]

On 10.05.2012, at 18:48, Mark Dexter wrote:

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.

The proposal was actually mine and I already wrote the path for 2.5 (https://github.com/realityking/joomla-cms/compare/mvc2) I just haven't had time to submit it to the CMS. I'll try to do it sometime next week.

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.

Actually no need to deal with the jimport line, the new legacy classes can just be made autoloadable (see the patch above)

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?

Here I don't quite follow or don't see how this would work.

• Any extension using the new legacy classes would be totally unaffected.

No argument here.

• 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.)

Not sure how this would work. The platform has already moved those three classes out of their old folder so current jimport() calls won't work anymore. Currently they are autoloadable but that means you won't have access to the new MVC classes. The choice is either to break backwards compatibility and require the new class names (JViewLegacy, etc.) or keep the old names and don't give developers access to the new interfaces (and thus the new classes).

Best regards

Rouven

[Mark Dexter]

Hey Rouven. Sorry if I got this wrong. I was just reading the thread on list and the first one I saw was Sam's thread, hence "Sam proposed". It was a great idea imo (and not your first great idea). Thanks. Mark

[brian teeman]

Hopefully not your last great idea either - we need great minds

[Elin Waring]

I think the specific version of the proposal being discussed is this one https://groups.google.com/d/msg/joomla-dev-platform/QikDqThfFN4/elGt0xWSP-8J. which is why Mark said Sam's. But great ideas have many parents.

One subtle point people should be aware of is that the autoloading of the new MVC actually requires changes of folder names from models, views,controllers, helpers to model, view, controller, helper.  Obviously as long as you aren't trying to use the new mvc autoload this doesn't matter and a lot of transitioning to the new MVC replaces  things like addFieldPath  so all those references are going to be touched anyway but it is something to be aware of as are a few other conventions (layouts not tmpl as the expected folder name).  You can always do other things but if you want to take advantage of the conventions those are things you will want to look for.  For these and other reasons I think it is very unlikely that you would ever combine old and new in one extension except for very limited situations.

I believe what they are trying to do with this plan is to avoid the conflicting autoloads issue by requiring everyone to do the relatively simple search and replace for the jimport and extends lines for 3.x.  We can do this in the core relatively easily even though it is close to 40 extensions because the core code is relatively well structured and there are lots of people who will check and recheck the code. The question I think Mark is asking is how much pain does this cause existing extensions to accomplish by the release of 3.0 given the advantage  that it will not require maintaining separate versions for 2.5.x and 3.x.  To me the added advantage that the CMS will be able to gradually implement a transition is a big deal, because those 37 extensions include a lot of things like com_cpanel or com_checkin that can be transitioned (I hope) relatively easily  while the content type extensions that have a ton of independent extensions relying on them can be left alone since they will eventually retire anyway when UCM is implemented. 

There's a lot of complexity involved in moving forward (once we have dealt with b/c issues) because of the switch from JApplication to JApplicationWeb among other things.  It will be good to be able to start being able to think about those exciting prospects by getting the legacy issues dealt with completely. 

Elin

[Sam Moffatt]

On Fri, May 11, 2012 at 12:16 AM, Rouven Weßling <m...@rouvenwessling.de> wrote:

> Not sure how this would work. The platform has already moved those three
> classes out of their old folder so current jimport() calls won't work
> anymore. Currently they are autoloadable but that means you won't have
> access to the new MVC classes. The choice is either to break backwards
> compatibility and require the new class names (JViewLegacy, etc.) or keep
> the old names and don't give developers access to the new interfaces (and
> thus the new classes).

So in 2.5.x, the legacy files are added extending the existing classes
(simple). In 3.x we flip it so that the files are left in place so the
jimport() statements work, add a deprecated usage notice in the old
file name (e.g. /libraries/joomla/application/component/model.php) and
update the file to be JModel extends JModelLegacy where JModelLegacy
has all of the code. As legacy extensions will explicitly jimport the
file at the top (because those classes are not currently autoloadable)
they remain unaffected in the 3.x series and have until 4.x to update
(not that updating is hard but it is time consuming).

The autoloader will kick in if you haven't explicitly jimport'd the
class however since all extension developers now have to jimport these
classes we shouldn't have a problem. Going forwards we can autoload
everything however in this case we can provide a transition pathway
for those who haven't renamed things in the 3.x series with forwards
compatibility in 2.5 for all of the changes. The only issue remaining
is mixing the two in the same request but in the short term that
shouldn't be a problem as most won't be using the new classes and in
the long run the solution is to update old code by renaming a class.

Cheers,

Sam Moffatt
http://pasamio.id.au

[Amy Stephen]

I am concerned that all of these lengthy, technical posts are going to stir up concern again about the impact of this change to Joomla CMS third party extensions, so I want to add that the impact is nominal.

Components will require one minor change -- the "extends JView" class declaration for Views will need to be changed to "extends JViewLegacy."

That minor change can be made for 3.0, it will work with older releases, and it doesn't have to be implemented for awhile (possibly a couple of years) because both will work until that time.

[shumisha]

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."

Elin seems to equate this to "...it is very unlikely
that you would ever combine old and new in one extension.."

(which I agree with) but I think such issue will appear on pretty much
any site that has one extension requiring old style and another one
using new style.
The collision will occur through modules and plugins, most of them
reusing the main component models.

This leads to either:

a/ force usage of JXXXXLegacy classes from 3.0 on: limit number of
extensions available for 3.x
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

As long as old and new MVC cannot live side by side on the same page
load, I don't see how this can be avoided. Am I missing something?

Cheers

[Elin Waring]

Yes, I guess you noticed that I was really careful not to use the word page.

I think in the end webmasters need to have the understanding of the tools that they use and people distributing extensions have to be clear about the limitations of use of their extensions. To start most likely plugins and modules using new MVC are going to be restricted to displaying on pages generated with extensions using the new MVC and vice versa.  I'm pretty sure people will work out ways to handle this. I was looking at some modules this morning where this would be an issue such as Latest Articles and I think it is be solvable although perhaps not pretty.

Elin

On Saturday, May 12, 2012 5:31:50 AM UTC-4, shumisha wrote:p

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

[Ofer Cohen]

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.

[Amy Stephen]

On Sat, May 12, 2012 at 4:31 AM, shumisha <shum...@gmail.com> wrote:

Hi all

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

Good point, but a different issue. Holding off new Joomla CMS development with the new content strategy and MVC changes until 4.0 is, in my opinion, appropriate.

Consider the new controller and model are nothing more than stubs right now. Will CRUD operations be in the Model? or are the new Content classes anticipated to take over a lot of what the Controller and Model do now?

New Controller:
https://github.com/joomla/joomla-platform/blob/staging/libraries/joomla/controller/base.php

New Model:
https://github.com/joomla/joomla-platform/blob/staging/libraries/joomla/model/base.php

If I understand correctly, a new release for the Unified Content Model is coming https://github.com/eBaySF/joomla-platform/tree/content -- when that is available it will start to be more clear where things are heading. Rushing it into 3.0 before developers have had time to play with it and consider how best to implement it would be a bad idea, asking for trouble. The "conflict on the same page" issue is only one of many problems that would likely arise.

I've said before that I believe it will help guide smoother change management processes if the CMS would select a platform release for a series, and then stick with it. If the CMS tries to keep pace with these platform improvements, especially as the UCM and new MVC changes start coming in, it's going to be a rough ride for users and developers.

Given that it's mid-May and the new 3.0 series kicks off in September, I would love to see the PLT to set a development standard that the CMS will continue with the existing MVC architecture for the 3.0 series - and anticipate it's introduction to the CMS in 4.0. That'll buy time for sensible change management.

With that said, I'll repeat my point that the existing MVC changes, already in core, are not in and of themselves significant. However, I agree that combined with adopting a new approach in the CMS in 3.0, there would be significant impact. Holding back that impact until 4.0, so that the code is available and we've had time to think things thru and make plans, seems sensible.

Note: we are *all* talking about the CMS in the platform list, responding to a PLT question. It'll take awhile to separate these code and issues. I have no problem with the overlap and hope everyone is patient with others, especially if they are posting themselves. =).

[Andrew Eddie]

On 13 May 2012 00:40, Ofer Cohen <ofer...@gmail.com> wrote:
> 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).

Louis did provide a lengthy explanation for this but I can't remember
if that was in the pull request comments or the mailing thread. The
best example is PHP itself which does not use *Interface (and I'm sure
they had a lengthy debate about that). Similarly we don't name
classes with a *Class suffix, nor would we treat traits that way. The
*Interface suffix also breaks down when you have more than one
interface type per package with respect to autoloading.

The other thing to realise is that the interface is not the only thing
that breaks backward compatibility - there is a lot of unnecessary
CMS-only and PHP4 bloat stripped from the MVC classes.

Hope that helps.

Regards,
Andrew Eddie
http://learn.theartofjoomla.com - training videos for Joomla developers

[shumisha]

Hi,

Indeed Louis explained in the pull request comments that JModel et al.
had different methods, etc and so the issue is not really about the
"Interface" naming scheme. Calling the interface JModelInterface will
not render Jmodel usable again in the way it was before.

@Amy:

"...Good point, but a different issue. Holding off new Joomla CMS

development
with the new content strategy and MVC changes until 4.0 is, in my
opinion,

appropriate...."

I was only referring to 3rd party developers. Let's assume the CMS
decide to NOT use the new MVC in 3 series, or even use it partially,
depending on resource and time. It surely is manageable at the CMS
level to avoid "same page" conflicts, by using or not the new MVC in
specific modules and plugins, and therefore the new MVC "could" be
used.

However, from a 3rd party dev standpoint, this is a no-go, because we
won't know on which page our modules and plugins will be displayed.

"To start most likely plugins and
modules using new MVC are going to be restricted to displaying on
pages
generated with extensions using the new MVC and vice versa. I'm
pretty
sure people will work out ways to handle this."

Elin, I don't buy that for a second. Users won't manage that, and even
if some do, that's a very unecessary burden to impose on them, IMHO.


I had actually "skipped" that but the future introduction of the UCM
further complicates the matter, in a way, as this will also probably
involve similar coexistence concerns. Having to handle a similar
change management only 18 month or 2 years later will be difficult, so
I would second Amy's tought of holding things a bit, until 4.0.

As a last thought, one of the technical way of solving this, mentioned
in the pull request comments, was to use namespaces. Andrew explained
we're not ready yet for that, which sounds reasonable.
As it been considered to simply simulate namespaces?

Could we stick with JView, JController, JModel for the (now) legacy
MVC, and use JxView, JxController and JxModel for the new MVC?

Autoloaders would be able to load appropriate files, old and new MVC
classes could coexists from day 1, whether used or not in CMS 3, I
don't think it's a major change in the platform code, will avoid any
change in existing extensions, keep existing documentation and
tutorial valid, etc

Obvioulsy the Jx prefix is only a suggestion. I haven't checked if any
other extension is already using it ofc.

The same Jx prefix would be used across several platform releases, as
long as the architecture is the same, and another one used when a new
major architectural change is introduced. Or else, by then, PHP
namespacing may have become a viable option.

It also make basically the whole platform pluggable, installed as:
/libraries/joomla/j
/libraries/joomla/jx
/libraries/joomla/ju (for UCM? if not using PHP NS)

It may be that I'm missing something entirely, but this is sunday
morning here, so please bear with me if so ;)

Rgds

[Andrew Eddie]

I think there's a better way to approach this looking at the practical
side of how the CMS can use the new classes without the use of interfaces.

It seems to me the simplest approach is to copy non-interface versions
of JControllerBase, JModelBase, JModelDatabase, JViewBase and
JViewHtml to the legacy tree. The reality is those are the classes
that will be used in 4.0 so there's no conflict in dropping them into
3.0. The following is an outline of how I would see these being used
in the CMS:

CONTROLLERS

JControllerBase is a single task controller. New controllers in 3.0
can be extended from JControllerBase or a multi-task controller that
emulates the old JController can be added to either the platform's
legacy tree or the CMS. I'll call this JControllerMulti for now.

The CMS needs to look at the derived controllers, like
JControllerForm, and make sure they are future proof (taking out any
deprecated API).

Instructions to developers would be:

a) Strip out deprecated functionality from your controllers and usage
(things like addModelPath, etc).
b) Note that JControllerBase does not extend JObject
c) Convert your existing controllers to extend JControllerMulti, not
JController.
d) Create new single-task controllers from JController Base.
e) Use autoloader rules to help Joomla find your extension's
controllers (maybe the CMS can do this transparently).

Your controllers are now ready for Joomla 4.0.

MODELS

All Joomla extensions would convert to using JModelDatabase eventually
and basically this is an exercise of stripping down the model classes.

Instructions to developers would be:

a) Strip out any deprecated API that is not found in JModelDatabase
(all the include path, etc).
b) Note that JModelDatabase does not extend JObject
c) Convert your existing models to extend JModelDatabase.
d) Use autoloader rules to help Joomla find your extension's models
(maybe the CMS can do this transparently).

Your models are now ready for Joomla 4.0.

VIEWS

You might be lucky, but I think JViewHtml will likely need extended to
provide all of the useful features in the old JView, so you are going
to need a JViewPage/JViewCms or similar (the CMS can haggle over what
name it needs to be). The main thing is setting up default paths for
the layout overrides.

Instructions to developers would be (like before):

a) Remove deprecated functionality from your views and code
(assignRef, adding paths, etc).
b) Note that JViewBase does not extend JObject
c) Convert your existing views to extend JViewPage/Cms/?
d) Use autoloader rules to help Joomla find your extension's view
classes (maybe the CMS can do this transparently).

Your models are now ready for Joomla 4.0.

----

To me, that would be a sane approach which will use the final products
when the old MVC is dropped. It should only take 15 minutes to put
the pull together to have non-interface versions of the new concrete
MVC classes in the legacy tree. Anyone then using the legacy tree can
use the new MVC classes by simply extending from JControllerBase,
JModelBase, JModelDatabase, JViewBase or JViewHtml without risk of
collision or backward compatibility (in fact, it makes you forward
compatible). Likewise, anyone building other platform app's uses the
same class name.

The only disadvantage with this system is that the CMS is type hinting
at the CMS level - JModel and JModelBase won't be compatible - but a
developer will be able to type hint within the confirms of their own
extension.

Does that all make sense?

[Elin Waring]

Again, while the policies for the CMS will be hammered out in the CMS I would say that the goal at this point for 3.x is progressive enhancement. Over the three year life span of 3.x it is highly likely that most developers will be switching to the newer and more powerful approaches and want to be moving to require 5.3 and so on, just as we saw with 1.0 and php 5.  Maybe I wasn't clear but, I meant that most of the time for the early days if you are using a component with new MVC you may be restricted to using modules and plugins built to work with that extension plus of course ones that don't rely on the old (which really depends on which modules and plugins you are talking about--I don't think most plugins care much about mvc) when you render that new mvc component. Of course this depends on the module or plugin in question since many will not care one way or another.   Of course those webmasters will be early adopters and more advanced in skill.  Most of the core modules that might be impacted, which is not close to all of them, can be modified to work and possibly to go either way depending on context. 

I'm pretty sure the skill level among Joomla extension developers especially for things like modules and plugins , means that they will figure out how to make it work. It's not like making a component that supports multiple versions to make a module that can render in both old and new mvc.  Have people actually looked at their modules' code to see how often they are directly calling JModel?

  Developers of modules and plugins for which the MVC version matters will  figure out what they want to do.  And then they can just not render if the environment is not right or they can be adaptive. 

If we're at the point that we're worrying about rendering modules  I think we are in good shape with more than three months to go before release. 

Andrew's point is important too but again more about the CMS. And I totally agree because it will  let extension developers proceed in a reasonable fashion rather than have to rush in at the end. As Sam said the other day changing is time consuming but not hard, so we should aim to give people time. 

Elin

[Andrew Eddie]

On 14 May 2012 08:02, Andrew Eddie <mamb...@gmail.com> wrote:
> I think there's a better way to approach this looking at the practical
> side of how the CMS can use the new classes without the use of interfaces.

And here's the pull request:

https://github.com/joomla/joomla-cms/pull/206

I decided to go against the CMS because we'd end up with multiple
classes in the platform.

Now, can I ask that further discussion about how the CMS deals with
this be posted here:

https://groups.google.com/forum/?fromgroups#!topic/joomla-dev-cms/QSoIEQFDoEQ

The platform can advise how to approach how to use the platform, but
the final decision rests with the CMS stakeholders.

Thanks in advance.

[shumisha]

Hi

Before I switch to the CMS list, and as my last proposal does (would)
affect the platform, could you take another minute to commment on
this:

I see your last proposal as quite more complex and not simpler. In
addition, I can't see in which way it is "better".
I do see that you last phrase is: "Your XXXX is now ready for CMS
4.0", but a/ that doesn't take into account UCM, so I think all those
changes will not make your models, views or controllers really ready
for 4.0, b/ considering the timeframe, getting ready for 4.0 should
probably be put in perspective with inconveniences in using 3.0, and
c/ the same is true of my proposal, except you have the lifetime of
3.x series to make them ready

In comparison, using the name change outlined above, outline of using
the proposed "namespace" in cms 3.0 would be:

CONTROLLERS

Outline for both CMS devs and 3rd-party extensions devs:

a/ want to use new MVC: use it. Don't worry about other parts or CMS
or extensions compatiblity.
(note: your new controllers will be as 4.0 compatible as possible)

b/ don't want to use right now: nothing to do


MODELS

a/ want to use new MVC: use it. Don't worry about other parts or CMS
or extensions compatiblity.
(note: your new controllers will be as 4.0 compatible as possible)

b/ don't want to use right now: nothing to do


VIEWS

a/ want to use new MVC: use it. Don't worry about other parts or CMS
or extensions compatiblity.
(note: your new controllers will be as 4.0 compatible as possible)

b/ don't want to use right now: nothing to do


PLATFORM DEVELOPERS:

a/ search, instances of JSomething, replace with JxSomething
b/ drop the legacy tree, not needed anymore (no maintenance needed on
that!)


As mentioned before, with the proposed naming convention, one (CMS or
3rd party ext) can very well mix using new and old MVC anywhere and
start converting extensions during the lifetime of 3.0, step by step.
This make it possible to eventually consider dropping the "new"
platform into a (future) 2.x release, side by side with the "old" one,
so that an extension using same code base can be used in both 2.x and
3.x. With no additional work from either the platform devs, the
extension dev and only bootstrap work on the cms (registering prefix
with the autoloader)

So please, before I just drop the idea entirely, can you expand a bit
on the "better" part of the changes you did, or the "worse" part of my
suggestion?


Cheers

[shumisha]

Hi Elin,

Modules and plugins certainly don't care much about "VC", but they do
care much about "M". Many modules will use the main component models
to fetch the data they want to display: Calendar modules fetch todays
or this week events using main model - to have all authorizations and
view restrictions applied for instance, forum modules fetch last
posts, shop module fetch on sale or top sellers, etc

Again, I'm not talking about core modules, which are simpler to handle
in a way as they are "under control" and their code can be adjusted as
needed - though it requires some work ofc

So the discussion is relevant and the conflict will happen a lot. The
discussion is therefore not about the skills of the developers, but
about

- trying to not force them to do this work immediately, if it can be
avoided, and especially as it does not bring any value to them and/ or
their users
- at the same time, try to have CMS 3.0 be launched with as many
extensions available from the start, which is always a major factor in
adoption rate.

Rgds

[Andrew Eddie]

On 14 May 2012 17:02, shumisha <shum...@gmail.com> wrote:
> Hi
>
> Before I switch to the CMS list, and as my last proposal does (would)
> affect the platform, could you take another minute to commment on
> this:

Ok, but it will probably take a little longer than a minute ;)

> I see your last proposal as quite more complex and not simpler.

It's not complex at all. All it's doing is moving the new controller,
model and view class within the visibility of the CMS without causing
complete backward compatibility chaos.

> In
> addition, I can't see in which way it is "better".

It's better because developers who want to opt into the new MVC are
using the final class names.

> I do see that you last phrase is: "Your XXXX is now ready for CMS
> 4.0", but a/ that doesn't take into account UCM,

Correct. The MVC is a dependancy of the UCM, but UCM is not a
dependancy of MVC. In other words, the MVC can be used to a lot more
than just UCM.

> so I think all those
> changes will not make your models, views or controllers really ready
> for 4.0, b/ considering the timeframe,

Yes they will. Changing:

AkeekbaModelFoo extends JModel

to

AkeebaModelFoo extends JModelDatabase

makes you "new-MVC" ready. I think most developers could manage that
simple change over a period of 18 months.

> getting ready for 4.0 should
> probably be put in perspective with inconveniences in using 3.0, and
> c/ the same is true of my proposal, except you have the lifetime of
> 3.x series to make them ready
>
> In comparison, using the name change outlined above, outline of using
> the proposed "namespace" in cms 3.0 would be:
>
> CONTROLLERS
>
> Outline for both CMS devs and 3rd-party extensions devs:
>
> a/ want to use new MVC: use it.

This is not correct. You cannot use the MVC in /libraries/joomla
simultaneously with the MVC in /libraries/legacy. This is the crux of
the problem.

As an example, if the CMS applies 12.1 of the platform 'today', and an
extension developer writes this:

class MyModel extends JModelDatabase

it should error because the autoloader looks for JModel in the legacy
tree first. It won't find the interface named JModel in the core
platform. However, if you put JModelDatabase in the /cms/ tree, and
wire it not to not implement JModel, any developer will be able to
safely use it.

> Don't worry about other parts or CMS
> or extensions compatiblity.

You do have to worry it for the aforementioned reasons. If a custom
module uses the new MVC it won't work.

> (note: your new controllers will be as 4.0 compatible as possible)

No they won't be because JControllerBase is a single task controller.

> b/ don't want to use right now: nothing to do

Correct.

> MODELS
>
> a/ want to use new MVC: use it. Don't worry about other parts or CMS
> or extensions compatiblity.
> (note: your new controllers will be as 4.0 compatible as possible)
>
> b/ don't want to use right now: nothing to do

It doesn't work that way. Same issues as above.

> VIEWS
>
> a/ want to use new MVC: use it. Don't worry about other parts or CMS
> or extensions compatiblity.
> (note: your new controllers will be as 4.0 compatible as possible)
>
> b/ don't want to use right now: nothing to do

And ditto again.

> PLATFORM DEVELOPERS:
>
> a/ search, instances of JSomething, replace with JxSomething

I prefer how Rouven uses a suffix.

> b/ drop the legacy tree, not needed anymore (no maintenance needed on
> that!)

The legacy tree is used to temporarily bridge many, many classes that
are either CMS specific, or need to be replaced. It serves a good
purpose and it won't be dropped in the near future.

> As mentioned before, with the proposed naming convention, one (CMS or
> 3rd party ext) can very well mix using new and old MVC anywhere and
> start converting extensions during the lifetime of 3.0, step by step.

As I explained, the autoloader configuration in the CMS prevents this
from happening. It loads the legacy tree first, then the core
platform. And, again, the legacy tree is used for a lot more than
just housing the old MVC classes.

> This make it possible to eventually consider dropping the "new"
> platform into a (future) 2.x release, side by side with the "old" one,
> so that an extension using same code base can be used in both 2.x and
> 3.x. With no additional work from either the platform devs, the
> extension dev and only bootstrap work on the cms (registering prefix
> with the autoloader)

You could apply my pull request to 2.x with the same effect. It would
allow extension developers to swap over to the new naming conventions
in a way that could carry through from 2.x to 3.x to 4.x.

> So please, before I just drop the idea entirely, can you expand a bit
> on the "better" part of the changes you did, or the "worse" part of my
> suggestion?

Hopefully I've covered it ok for you.

Regards,
Andrew Eddie

[Elin Waring]

"Many" really is an interesting word. You could just as easily say "many" don't (I actually looked through the core modules before posting at all on this topic. but I assume you had another sampling method ). 

 I'm thinking that if one person comes up with an adaptive approach most people will probably follow that.

Again, if we are at the point of worrying about rendering old  modules on pages rendering components using the new MVC or  new MVC modules rendering on old style component pages we  are in great shape in my opinion. I think it would be for the awesome for those components to come quickly though I don't think they'll be arriving in September.  

Elin

[Amy Stephen]

For what it's worth, I think Yannick is right to be concerned. If this name change means extensions coded to the 2.5 spec will not work on the same page as extensions that will use the new class names in 3.0, then that should concern everyone. (Especially if the problem only exists due to this name change, not new technology.)

Totally support the platform effort and I know it's tough to drag this big community behind you. You're all very clever -- I think this needs a little more thought.

Amy

[Andrew Eddie]

On 14 May 2012 17:17, shumisha <shum...@gmail.com> wrote:
> Modules and plugins certainly don't care much about "VC", but they do
> care much about "M".

Actually that's not quite true. I certainly teach people to use JView
in modules so that they only had to learn one set of rules for layouts
(whether they be for components or modules), and I've certainly
designed a few plugins with a view in my time. Plugins are also
closer to a controller than anything else.

> So the discussion is relevant and the conflict will happen a lot.

I think you are worried about a different problem. Can you give me a
code example of the conflict you perceive?

> - trying to not force them to do this work immediately, if it can be
> avoided, and especially as it does not bring any value to them and/ or
> their users

We actually went over this at length in the discussion of the pull
request. You don't have to do anything till at least 2013 and even
then it depends on what the CMS is doing (so you should REALLY be
bringing this up on the CMS list).

> - at the same time, try to have CMS 3.0 be launched with as many
> extensions available from the start, which is always a major factor in
> adoption rate.

I don't understand why 3.0 adoption would be affected at all.

[Amy Stephen]

On Mon, May 14, 2012 at 4:50 PM, Andrew Eddie <mamb...@gmail.com> wrote:

On 14 May 2012 17:17, shumisha <shum...@gmail.com> wrote:

> So the discussion is relevant and the conflict will happen a lot.

I think you are worried about a different problem. Can you give me a
code example of the conflict you perceive?

For example, this conflict would exist if a User installed a 3.0 component that uses the new MVC classes - and also displayed the "Latest News" Module for the same ItemID. Both extensions would require a different JModel class.

[Andrew Eddie]

On 15 May 2012 08:27, Amy Stephen <amyst...@gmail.com> wrote:
> For example, this conflict would exist if a User installed a 3.0 component
> that uses the new MVC classes - and also displayed the "Latest News" Module
> for the same ItemID. Both extensions would require a different JModel class.

Currently, if they use JModelBase in the CMS (assuming it's on 12.1)
it will implement from JModel, but the autoloader is going to find
JModel in the legacy tree first, which will be a class (not an
interface). It's simply not going to work - PHP will error in the
component before the developer can even distribute it. That's why I
made that pull request against the CMS to add non-interfaced versions
of JModelBase and co.

Regards,
Andrew Eddie

[shumisha]

Hi all,

@Elin: re: "sampling": yes, core is not the place you want to look at
for samples. Like I said, core is "under control", and should any
conflicts arise there, it can be easily solved before any release is
made.

I think Amy clarified that point in her last post. Looking at large
3rd party extensions, you'll find many examples. For a real life
example, here is one of the first lines of one of the numerous modules
in JCal Pro:

// Get an instance of the events model
$model = JModel::getInstance('Events', 'JCalProModel',
array('ignore_request' => true));

So if the JCal Pro module for latest events is published on the same
page as an extension rewritten with new MVC, a conflict will arise.


@Andrew: thanks for you time, I do realize it took you more than one
minute ;)

However, before going any further, it seems there is a
misunderstanding in my proposal, as evidenced by one of your initial
remarks. That needs to be cleared up first:

"...This is not correct. You cannot use the MVC in /libraries/joomla

simultaneously with the MVC in /libraries/legacy. This is the crux of

the problem...."

The very point of my suggestion is to allow this. And possibly have
more just as many platform version installed (one per prefix), though
only will be used to "run" the CMS, the others serving as class
libraries.

Talking about CMS 3.0:
platform 12.1 is installed in /libraries/joomla/jx
platform 11.x is installed in /libraries/joomla/j

All classes in platform 12.1 are prefixed with Jx - JxModel, JxView,
JxModelDatabase, whatever
All classes in platform 11.x are prefixed with J - JModel, JView, etc
ie: this is the current 11.x version, unchanged

The autoloader is not confused and knows where to find each class.

Those part of the CMS that are rewritten to take advantage of the new
MVC simply use or extend JxSomething classes
Those part of the CMS that are not rewritten to take advantage of the
new MVC are left unchanged, ie keep using JModel, JView, etc and their
descendant
Those 3rd party extensions that are not rewritten to take advantage of
the new MVC are left unchanged, ie keep using JModel, JView, etc and
their descendant, which means the 11.x platform versions of the
classes will be autoloaded
Those 3rd party extensions that are rewritten to take advantage of the
new MVC simply use JxSomething classes,

ie AkeekbaModelFoo extends JxModel

Actually the latter example would probably be
AkeekbaModelFoo extends JxModelDatabase, as JxModel is supposed to be
the interface.


The idea behind changing the prefix for a major architectural change
is precisely to allow both architecture to coexist. If that's not
possible, all my other points are invalid of course.
However I haven't see thus far anything that invalidate what I'm
saying here, so please, can I have another minute of your time?

Cheers

[Elin Waring]

Although it's possibly not the case for customers of specific extension developers, if you look at the actual range of sites in the real world--the million downloads a month of the cms that are happening-- I think you would find that mod_menu, mod_custom, mod_login, mod_breadcrumbs are in fact pretty widely used. In fact... I think you would find one or more of them in use on most sites. So yes, much as non core modules are of great import to those who create and use them, they are  in no way more important or more commonly used than the core modules. They are also in no way "under control" since they have to be able to work with old and new extensions seamlessly.  So the people who maintain those have serious and high impact  work cut out for them over the next few months which, if it can't be accomplished means that I would think  none of these ideas will be ready for release. If compatibility in the core is so easy to solve then so will compatibility for everyone else. If it is hard to solve then it will be hard for everyone else.  However once we've figured out how to make Latest News work probably many developers will be able to follow that pattern.

Anyway, I'm more into doing than  talking so I'm thinking what I need to do is to actually try out both Andrew and Sam's approaches  make a hello world new mvc component, and see how difficult solving is in reality.

Elin

[Andrew Eddie]

On 15 May 2012 10:36, shumisha <shum...@gmail.com> wrote:
> I think Amy clarified that point in her last post. Looking at large
> 3rd party extensions, you'll find many examples. For a real life
> example, here is one of the first lines of one of the numerous modules
> in JCal Pro:
>
> // Get an instance of the events model
> $model = JModel::getInstance('Events', 'JCalProModel',
> array('ignore_request' => true));
>
> So if the JCal Pro module for latest events is published on the same
> page as an extension rewritten with new MVC, a conflict will arise.

I cannot think of any way in which this can occur. The "new MVC"
extension will error making it impossible to use - that is on the
assumption that 12.1 of the platform is being used without any change.

> The very point of my suggestion is to allow this. And possibly have
> more just as many platform version installed (one per prefix), though
> only will be used to "run" the CMS, the others serving as class
> libraries.

Now I really don't understand. Above you are saying that a conflict
will arise, but now you are acknowledging that you can't use the new
MVC simultaneously. I'm confused.

> Talking about CMS 3.0:
> platform 12.1 is installed in /libraries/joomla/jx
> platform 11.x is installed in /libraries/joomla/j
>
> All classes in platform 12.1 are prefixed with Jx - JxModel, JxView,
> JxModelDatabase, whatever
> All classes in platform 11.x are prefixed with J - JModel, JView, etc
> ie: this is the current 11.x version, unchanged
>
> The autoloader is not confused and knows where to find each class.

Correct, it wouldn't be confused, but why would you not just use the
final class names (JModelBase, etc)?

> Those part of the CMS that are rewritten to take advantage of the new
> MVC simply use or extend JxSomething classes

This is really a discussion to be having with the CMS because it is a
CMS problem, not the platform's.

> Those 3rd party extensions that are rewritten to take advantage of the
> new MVC simply use JxSomething classes,
>
> ie AkeekbaModelFoo extends JxModel
>
> Actually the latter example would probably be
> AkeekbaModelFoo extends JxModelDatabase, as  JxModel is supposed to be
> the interface.

Again, why would you not just using JModelDatabase?

> The idea behind changing the prefix for a major architectural change
> is precisely to allow both architecture to coexist. If that's not
> possible, all my other points are invalid of course.
> However I haven't see thus far anything that invalidate what I'm
> saying here, so please, can I have another minute of your time?

You don't need to have a prefix variant, and even if you did, that's
something you need to lobby the CMS for. Regardless, if you have a
look at my pull request, you'll see it should work without causing
conflicts.

To conclude, I'm going to ask again that you move this discussion to
the CMS list (I already started a thread).

[shumisha]

Hi

>
> To conclude, I'm going to ask again that you move this discussion to
> the CMS list (I already started a thread).

I am proposing a change to the platform, so if we discuss this on the
CMS list, the outcome, if positive, would be "ok, let's ask the
platform guys to make that change". Better try to understand each
other here first I think.



On 15 mai, 08:54, Andrew Eddie <mambob...@gmail.com> wrote:

> On 15 May 2012 10:36, shumisha <shumi...@gmail.com> wrote:

>
> > So if the JCal Pro module for latest events is published on the same
> > page as an extension rewritten with new MVC, a conflict will arise.
>
> I cannot think of any way in which this can occur.  The "new MVC"
> extension will error making it impossible to use - that is on the
> assumption that 12.1 of the platform is being used without any change.

Yes. This cannot work with the current platform 12.1, and taht is (one
of) the problem we're trying to solve!!!

>
> > The very point of my suggestion is to allow this. And possibly have
> > more just as many platform version installed (one per prefix), though
> > only will be used to "run" the CMS, the others serving as class
> > libraries.
>
> Now I really don't understand.  Above you are saying that a conflict
> will arise, but now you are acknowledging that you can't use the new
> MVC simultaneously.  I'm confused.

Yes, a conflict will arise if nothing is done. If platform 12.1 is
modified as suggested (ie use a Jx prefix instead of J), 12.1 and 11.x
can then be used on the same page load with no fear of conflict.

>
> > Talking about CMS 3.0:
> > platform 12.1 is installed in /libraries/joomla/jx
> > platform 11.x is installed in /libraries/joomla/j
>
> > All classes in platform 12.1 are prefixed with Jx - JxModel, JxView,
> > JxModelDatabase, whatever
> > All classes in platform 11.x are prefixed with J - JModel, JView, etc
> > ie: this is the current 11.x version, unchanged
>
> > The autoloader is not confused and knows where to find each class.
>
> Correct, it wouldn't be confused, but why would you not just use the
> final class names (JModelBase, etc)?

That's what I'm proposing. Directly use the final class names. Except
the final class name is JxModelDatabase.

Because I want the final class name of any platform implementing the
"new MVC" to be JxModelBase, instead of JModelBase, so that autoloader
and programmers do not confuse them.
And because being able to keep using the "old MVC" in a platform 12.1-
enabled CMS without having to modify your extension (use JXXXXLegacy
classes) appears to me a big advantage, especially if it removes the
need for creating a Legacy tree in 12.1.

>
> > Those part of the CMS that are rewritten to take advantage of the new
> > MVC simply use or extend JxSomething classes
>
> This is really a discussion to be having with the CMS because it is a
> CMS problem, not the platform's.
>
> > Those 3rd party extensions that are rewritten to take advantage of the
> > new MVC simply use JxSomething classes,
>
> > ie AkeekbaModelFoo extends JxModel
>
> > Actually the latter example would probably be
> > AkeekbaModelFoo extends JxModelDatabase, as  JxModel is supposed to be
> > the interface.
>
> Again, why would you not just using JModelDatabase?

One more time: because JModelDatabase would be the "Legacy" class,
while JxModelDatabase is the (final) platform 12.1+ class name.

>
> > The idea behind changing the prefix for a major architectural change
> > is precisely to allow both architecture to coexist. If that's not
> > possible, all my other points are invalid of course.
> > However I haven't see thus far anything that invalidate what I'm
> > saying here, so please, can I have another minute of your time?
>
> You don't need to have a prefix variant, and even if you did, that's
> something you need to lobby the CMS for.

That might be part of the misunderstanding. No, this is a not a CMS
change.
The proposed change is to modify platform 12.1 class names.

> Regardless, if you have a
> look at my pull request, you'll see it should work without causing
> conflicts.

I must modify the module so that it works on a platform 12.1-enabled
CMS
And I must modify all extensions: introduction of platform 12.1 in a
CMS or an application would require pre-existing extensions to be
modified and use the JXXXXLegacy classes.
That work can be avoided, I believe, by this proposal. With no adverse
effect that I can see, or added work on the platfom; and probably
reduced work on the platform, as the Legacy tree can be removed
entirely. And can use old and new classes on same page load.

>
> Regards,
> Andrew Eddiehttp://learn.theartofjoomla.com- training videos for Joomla developers

Rgds
Yannick

[shumisha]

Hi Elin

On 15 mai, 05:06, Elin Waring <elin.war...@gmail.com> wrote:
> Although it's possibly not the case for customers of specific extension
> developers, if you look at the actual range of sites in the real world--the
> million downloads a month of the cms that are happening-- I think you would
> find that mod_menu, mod_custom, mod_login, mod_breadcrumbs are in fact
> pretty widely used. In fact... I think you would find one or more of them
> in use on most sites.

Absolutely correct, but that's not what matters. Problem occur if such
a web site simply uses ONE module that's not MVC.
As this "old" module will conflict if displayed on the same page as
any "new MVC" component, it has either to be modified or changed for
another one.

So yes, much as non core modules are of great import
> to those who create and use them, they are  in no way more important or
> more commonly used than the core modules. They are also in no way "under
> control" since they have to be able to work with old and new extensions
> seamlessly.

Sorry, was unclear. What I meant by that is that, like you said, I
would expect that any core module would not cause conflict, and the
required changes that you mention would be done before a public
release.
So if I am a component developer, and want to use the new MVC, I'm not
concerned that my extension will break core modules, they will be
fine. But I will be concerned using my extension on a site will
prevent people from using other peoples modules and plugins,which may
not have been updated.

So the people who maintain those have serious and high impact
>  work cut out for them over the next few months which, if it can't be
> accomplished means that I would think  none of these ideas will be ready
> for release.

I think it would be even better if the maintainers have absolutely
nothing to do to achieve compatibility, don't you think?
And instead can spend their time on maybe rewriting some core
extensions using the new MVC for instance.
This is the goal of my simple proposal. If applied, there is no need
to change nothing to current CMS code, until the time you decide to
taka advantage of the new MVC. And there is no pressure to do so, it
can be done gradually over the next 18month, introducing the new-MVC-
enabled core extensions as they are ready.

If compatibility in the core is so easy to solve then so will
> compatibility for everyone else. If it is hard to solve then it will be
> hard for everyone else.  However once we've figured out how to make Latest
> News work probably many developers will be able to follow that pattern.
>
> Anyway, I'm more into doing than  talking so I'm thinking what I need to do
> is to actually try out both Andrew and Sam's approaches  make a hello world
> new mvc component, and see how difficult solving is in reality.

Good. But please consider than no compatibility work for platform, CMS
and 3rd party developers is probably better than even simple
compatibility work.
That's the idea behind the proposal.

Thanks and rgds

Yannick

[Elin Waring]

I'll tell you the real platform thing ... if your extension really is so complex you should consider making it an application and bootstrapping it from the version of the platform you need and that you would package with the application. Make it so that the application has some ways to interact with the CMS  if you need that. That way you control what your application is doing.  Lots of us already have two versions of the platform on our servers in that we have 1.5 and 2.5 sites. You could start sending feeds from one to the other if you want simple interaction and you can skin them in a way that is seamless  and of course you can get more complex, use web services, query each other's databases, share sessions etc if you want just like you would do when you integrate the CMS  and any other external application. 

Elin

On Thursday, May 10, 2012 12:48:41 PM UTC-4, 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.

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.)
• Note also that any classes that extend child classes (such as JModelAdmin or JModelList) would be entirely unaffected (since these will now be extending the legacy classes).

In version 4.x, the old JModel, JView, and JController class files would be removed and the code would be moved to the legacy versions. At that point, any extensions using the legacy MVC classes would have to change their classes to extend the legacy classes (the same simple change that was done in core for 2.5.5 or 2.5.6). At some point in the future, support for the legacy MVC might be dropped, but that decision will not need to be made until after 3.5 is released.

To the PLT, this approach seems to be a reasonable compromise between allowing a high degree of backward compatibility and still allowing the project to move forward with optimal file naming conventions. Extension developers can make a very simple change now to provide for forward compatibility. Even without these simple changes, 2.5 extensions will likely work in the great majority of situations for 3.x.

Please let us know what you think and whether we have missed some important aspect of this. Thanks!

On Thursday, May 10, 2012 12:48:41 PM UTC-4, 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.

[brian teeman]

JCal is hardly an overly complex extension and is fairly typical

[Amy Stephen]

Andrew -

Thanks for this clarification.

Yannick - it's a good time to begin discussing this on the CMS list. If I am understanding Andrew's point, you can't use the new classes in the CMS -- unless his PR (or similar) are adopted. So, the potential for conflict between a 2.5 module that uses the existing model -- and the new MVC structure - doesn't even exist right now.

The CMS might decide to not accept his PR, and just hold off until 4.0, or take it in and use an approach like you have outlined, renaming classes so that they can be used in parallel fashion.

In any event, it really is clearly a CMS choice and now that that is sorted, discussing it on the CMS list does make sense.

In all fairness, this topic was discussed at length and even those of us with objections ended up agreeing it was okay to move forward introducing the classes to the platform. Sounds like it's now time to have the same discussion on the CMS list about how to - or if to - or when to - bring them in there.

[shumisha]

Hi Amy,

I won't have time any more for this discussion, as I am heading for
Jab.

I still think this is the place to talk about this, as the requested
change is for the platform, not the cms.

Andrew is not entirely correct on the two points you sort of quoted
him:

- conflicts with 2.5 modules (and plugins): indeed there is no risk of
conflict...if you don't use them! That's one way of looking at it. Not
mine. I'd rather be able to use existing components, modules and
plugins and still have no conflict. Especially if the estimated work
to achieve time is a few hours.

- cannot use both versions on the platform: that's only true
currently. With my proposed prefix change in 12.1, it becomes fine to
use both version of platform on the same page, on the same component,
module or whatever.

I just did that yesterday night, replaced J with JPrefix in 12.1
(about half of it actually), stuck it in /libraries/joomla/jx, changed
a couple of lines in loader.php of a vanilla Joomla! 2.5.4 instance,
and off you go, you can use classes from 11.1 and 12.1 together - in
Joomla! 2.5 actually, you don't even need Joomla! 3.0.

Took about an hour, replacing J with Jx is a bit tedious!

Now you can use code like below anywhere in your component, modules,
plugins. And when the opposite is done (adding 11.1 to CMS 3.0), it
means existing extensions will work unchanged in CMS 3.0 (not
withstanding changes in the CMS itself ofc).

// Platform 12.1
class ModelDummy extends JxModelDatabase {
}

$model121 = new ModelDummy();
var_dump( $model);

// platform 11.1
jimport('joomla.application.component.modelitem');
class ContentModelArticle extends JModelItem {
}
$model111 = new ContentModelArticle();
var_dump( $model);

No change required to anything, if you want to use 12.1, just start
using it.

This is barely a proof of concept, and unfortunately we have spend a
lot of time trying to argue about irrevelant things, while the basic
idea has not at been examined, so maybe there are bumps down the road
that'll prevent this idea to work

"...The CMS might decide to not accept his PR, and just hold off until

4.0, or
take it in and use an approach like you have outlined, renaming
classes so

that they can be used in parallel fashion...."

Understand that. What a waste though. The CMS creating its own fork of
the platform?

Cheers

[shumisha]

Hi Elin,

Like Brian says, I'm not talking about any specific application. Only
about fairly usual extensions, such as K2, JomSocial or JCal pro for
instance.
I think you'd agree those are relatively common, and they'll all have
to update their modules, while I think it could be avoided.

I am not doing applications, and am only concerned with common, mass-
distributed standard Joomla! extensions.
This is what those few hundreds of thousands of Joomla! users are
dealing with daily, not custom written application, and that's where
I'd like to help make the transition smoother, while not impending
progress.

As I have started to implement the proposed change, and it seem I can
now use both 11.1 and 12.1 in a regular J! 2.5.4 instance, I'll just
try to do some sort of new MVC hello world on Joomla 2.5, time-
permitting.

Thanks for your input,

cheers
Yannick

On 15 mai, 13:49, Elin Waring <elin.war...@gmail.com> wrote:
> I'll tell you the real platform thing ... if your extension really is so
> complex you should consider making it an application and bootstrapping it
> from the version of the platform you need and that you would package with
> the application. Make it so that the application has some ways to interact
> with the CMS  if you need that. That way you control what your application
> is doing.  Lots of us already have two versions of the platform on our
> servers in that we have 1.5 and 2.5 sites. You could start sending feeds
> from one to the other if you want simple interaction and you can skin them
> in a way that is seamless  and of course you can get more complex, use web
> services, query each other's databases, share sessions etc if you want just
> like you would do when you integrate the CMS  and any other external
> application.
>
> Elin
>
>
>
>
>
>
>
> On Thursday, May 10, 2012 12:48:41 PM UTC-4, Mark Dexter wrote:
>

> > *In a recent thread in the Platform list (
> >http://groups.google.com/group/joomla-dev-platform/browse_thread/thre...)

> >    - 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.)

> >    - Note also that any classes that extend child classes (such as

> >    JModelAdmin or JModelList) would be entirely unaffected (since these will
> >    now be extending the legacy classes).
>
> > In version 4.x, the old JModel, JView, and JController class files would
> > be removed and the code would be moved to the legacy versions. At that
> > point, any extensions using the legacy MVC classes would have to change
> > their classes to extend the legacy classes (the same simple change that was
> > done in core for 2.5.5 or 2.5.6). At some point in the future, support for
> > the legacy MVC might be dropped, but that decision will not need to be made
> > until after 3.5 is released.
>
> > To the PLT, this approach seems to be a reasonable compromise between
> > allowing a high degree of backward compatibility and still allowing the
> > project to move forward with optimal file naming conventions. Extension
> > developers can make a very simple change now to provide for forward
> > compatibility. Even without these simple changes, 2.5 extensions will
> > likely work in the great majority of situations for 3.x.
>
> > Please let us know what you think and whether we have missed some

> > important aspect of this. Thanks!*

> On Thursday, May 10, 2012 12:48:41 PM UTC-4, Mark Dexter wrote:
>

> > *In a recent thread in the Platform list (
> >http://groups.google.com/group/joomla-dev-platform/browse_thread/thre...)

> >    - 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.)

> >    - Note also that any classes that extend child classes (such as

> >    JModelAdmin or JModelList) would be entirely unaffected (since these will
> >    now be extending the legacy classes).
>
> > In version 4.x, the old JModel, JView, and JController class files would
> > be removed and the code would be moved to the legacy versions. At that
> > point, any extensions using the legacy MVC classes would have to change
> > their classes to extend the legacy classes (the same simple change that was
> > done in core for 2.5.5 or 2.5.6). At some point in the future, support for
> > the legacy MVC might be dropped, but that decision will not need to be made
> > until after 3.5 is released.
>
> > To the PLT, this approach seems to be a reasonable compromise between
> > allowing a
>

> ...
>
> plus de détails »

[Amy Stephen]

On Wed, May 16, 2012 at 3:17 AM, shumisha <shum...@gmail.com> wrote:

Hi Amy,

I won't have time any more for this discussion, as I am heading for
Jab.

Hopefully, you'll find some clarity when you speak with the PLT and folks like Louis. It's kind of hard to see where things are going. Sitting down and talking this next week will help a great deal.
 

I still think this is the place to talk about this, as the requested
change is for the platform, not the cms.

Andrew is not entirely correct on the two points you sort of quoted
him:

- conflicts with 2.5 modules (and plugins): indeed there is no risk of
conflict...if you don't use them! That's one way of looking at it. Not
mine. I'd rather be able to use existing components, modules and
plugins and still have no conflict. Especially if the estimated work
to achieve time is a few hours.

That was my initial point. I didn't believe these classes were going to be used in 3.0, which to me is appropriate at this point. If the classes are made available too soon to the CMS (before the bigger picture of the Content Model, etc., is clear) then developers will have to make a number of assumptions on even the most basic CRUD operations. That kind of sets them up for having to change, again, when things are ready.

This next release of the Content Model should help clarify how things come together. Not sure how close it is -- for all I know, Louis might demo it at JAB for you. Or, it could still be a few months off.

- cannot use both versions on the platform: that's only true
currently. With my proposed prefix change in 12.1, it becomes fine to
use both version of platform on the same page, on the same component,
module or whatever.

Also true for Andrew's PR. So, if what you want is to get this into the CMS, between you and Andrew, and as a result of this discussion, there are a couple of options on the table to do so. Now, you need to talk to the folks who make those decisions (and it's not this list -- it's the CMS list.) Better still, you'll see them (the PLT) in person, very soon. :)
 

I just did that yesterday night, replaced J with JPrefix in 12.1
(about half of it actually), stuck it in /libraries/joomla/jx, changed
a couple of lines in loader.php of a vanilla Joomla! 2.5.4 instance,
and off you go, you can use classes from 11.1 and 12.1 together - in
Joomla! 2.5 actually, you don't even need Joomla! 3.0.

Took about an hour, replacing J with Jx is a bit tedious!

Now you can use code like below anywhere in your component, modules,
plugins. And when the opposite is done (adding 11.1 to CMS 3.0), it
means existing extensions will work unchanged in CMS 3.0 (not
withstanding changes in the CMS itself ofc).

// Platform 12.1
class ModelDummy extends JxModelDatabase {
}

$model121 = new ModelDummy();
var_dump( $model);

// platform 11.1
jimport('joomla.application.component.modelitem');
class ContentModelArticle extends JModelItem {
}
$model111 = new ContentModelArticle();
var_dump( $model);

No change required to anything, if you want to use 12.1, just start
using it.

Good for you, Yannick. And also, Andrew's approach will enable these classes to be used. So, once again, this community shows it can take care of things.
 

This is barely a proof of concept, and unfortunately we have spend a
lot of time trying to argue about irrevelant things, while the basic
idea has not at been examined, so maybe there are bumps down the road
that'll prevent this idea to work

I understand.

Given this has been discussed - passionately and at length - I do appreciate Andrew's patience going through this again.

 

"...The CMS might decide to not accept his PR, and just hold off until

4.0, or
take it in and use an approach like you have outlined, renaming
classes so

that they can be used in parallel fashion...."

Understand that. What a waste though. The CMS creating its own fork of
the platform?

Initially, I also had this reaction but it seems to me the only way to enable the platform team to move forward and to protect the CMS from too frequent and large of change is for the CMS to take a release and stick with it for that series. That buys the platform team time to work and it gives CMS developers a period of time that they know the API is going to stay stable. It's not really a fork, but a version. It all syncs up then with each new series (3.0, 4.0, etc.)
 

Cheers

All of this is just my opinion, nothing more. Thanks for your efforts, enjoy JAB.
Amy

[brian teeman]

On Wednesday, 16 May 2012 10:51:59 UTC+1, Amy Stephen wrote:

On Wed, May 16, 2012 at 3:17 AM, shumisha <shum...@gmail.com> wrote:

Hi Amy,

I won't have time any more for this discussion, as I am heading for
Jab.

Hopefully, you'll find some clarity when you speak with the PLT and folks like Louis. It's kind of hard to see where things are going. Sitting down and talking this next week will help a great deal.
  

Unfortunately Rob, Louis, Andrew, Sam and Christophe will not be at JAB 

[Amy Stephen]

Oh, that is too bad. Darn it. Neither will I and I am starting to feel bad about that, too. You all have a good time.

[Elin Waring]

B

[Rouven Weßling]

Sorry it took me so long to reply - my life's quite busy right now. You'll find answers to a couple mails below.

But first of all i wanna pull the tooth that current extensions can work unchanged on 3.0 - any current extension (especially if they support 1.5) - is nearly guaranteed to use deprecated APIs that aren't present in the current platform. Also we haven't yet figured out how the changes to error handling - especially in JDatabase - will impact extensions (or the core CMS code for that matter).

On 11.05.2012, at 17:37, Sam Moffatt wrote:

So in 2.5.x, the legacy files are added extending the existing classes
(simple). In 3.x we flip it so that the files are left in place so the
jimport() statements work, add a deprecated usage notice in the old
file name (e.g. /libraries/joomla/application/component/model.php) and
update the file to be JModel extends JModelLegacy where JModelLegacy
has all of the code. As legacy extensions will explicitly jimport the
file at the top (because those classes are not currently autoloadable)
they remain unaffected in the 3.x series and have until 4.x to update
(not that updating is hard but it is time consuming).

The autoloader will kick in if you haven't explicitly jimport'd the
class however since all extension developers now have to jimport these
classes we shouldn't have a problem. Going forwards we can autoload
everything however in this case we can provide a transition pathway
for those who haven't renamed things in the 3.x series with forwards
compatibility in 2.5 for all of the changes. The only issue remaining
is mixing the two in the same request but in the short term that
shouldn't be a problem as most won't be using the new classes and in
the long run the solution is to update old code by renaming a class.

That would work but would mean we'd have to add CMS specific files to the libraries/joomla folder. If any way possible I hope we can get by without that. I'm still kinda in favor of requiring JViewLegacy & Co in 3.0. It's a B/C break but if we do eh ground work now it should have a small impact. This also avoids the whole "mixing the two paradigms" problems.

On 12.05.2012, at 17:34, Amy Stephen wrote:

Good point, but a different issue. Holding off new Joomla CMS development with the new content strategy and MVC changes until 4.0 is, in my opinion, appropriate. 

The new MVC interfaces don't require the UCM to be useful. I see no reason why we shouldn't start in the 3.x series bring extensions to use the new classes/interfaces (Also JviewLegacy could probably implement JView as well)

On 16.05.2012, at 11:51, Amy Stephen wrote:

That was my initial point. I didn't believe these classes were going to be used in 3.0, which to me is appropriate at this point. If the classes are made available too soon to the CMS (before the bigger picture of the Content Model, etc., is clear) then developers will have to make a number of assumptions on even the most basic CRUD operations. That kind of sets them up for having to change, again, when things are ready. 

They most likely aren't. Like you describe we'll need some time to figure out how to best use them in the context of the CMS. The question to me is whether we wanna keep the window open to start using them in the 3.x series or if we wanna reserve that for 4.0.

Initially, I also had this reaction but it seems to me the only way to enable the platform team to move forward and to protect the CMS from too frequent and large of change is for the CMS to take a release and stick with it for that series. That buys the platform team time to work and it gives CMS developers a period of time that they know the API is going to stay stable. It's not really a fork, but a version. It all syncs up then with each new series (3.0, 4.0, etc.)

On the flip side that would all but exclude us from any improvements made in between - including bug fixes. Not sure we can afford that. Also it would mean we'd have an even harder time to get replacements for deprecated APIs in. For example 1.7 introduced some of the replacement APIs for things that have been dropped in 12.1. If we don't add these new APIs to STS releases the .0 releases will cause even more trouble. Also the platform will eventually have to provide (completely B/C) bugfix releases. We're not there yet if we'll be successful it will happen.

Best regards

Rouven

[Amy Stephen]

On Thu, May 17, 2012 at 12:02 PM, Rouven Weßling <m...@rouvenwessling.de> wrote:

Best regards

Rouven

 If we don't add these new APIs to STS releases the .0 releases will cause even more trouble.

IMO, we should expect the.0 release to change the API and break extensions.

To me, that's when big change should be introduced to the CMS.

I don't even think users should be encouraged to migrate to .0, I'd rather see the release promoted as "the developer release." It would help to give developers "a turn" to get ready and for the community to build migration processes for users.

My sense is that being able to stabilize the API within a series would be very appreciated. I don't think "scheduled change" at the start of each series -- especially if there is time to respond - presents much of a challenge. It's more the unexpected or constant change that creates workflow issues and makes it impossible for us to give users a smooth change.

Also, it would be nice if the platform didn't have to worry about impact to the CMS all of the time. If the CMS keeps taking change in, then you'll find CMS developers freaking out all the time when the platform changes. They'll keep posting on this list, too, since there appears to be no decision point or "gate" at the CMS for change to be held back until it's time.

Anyway - just my thoughts. It's good you are at JAB -- you'll definitely have a good feel for what might work best after your time with others.

Thanks for your work, Rouven.

[Rouven Weßling]

On 17.05.2012, at 19:52, Amy Stephen <amyst...@gmail.com> wrote:

> IMO, we should expect the.0 release to change the API and break extensions.
>
> To me, that's when big change should be introduced to the CMS.

I agree. But for API where a transition occurs (think JRequest -> JInput) we should be able to get the new API in before the old one is dropped. That should make transitions much smoother.

On the other hand I'm not strictly against making small backwards incompatible changes to STS version when they're necessary to fix a bug. (like fixing mod_menu in 1.7)

Rouven