*In a recent thread in the Platform list (
http://groups.google.com/group/joomla-dev-platform/browse_thread/thre...)
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!*

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:

Am 10.05.2012 18:48, schrieb Mark Dexter:

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

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

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.

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

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

No argument here.

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

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

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

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

I think the specific version of the proposal being discussed is this one
https://groups.google.com/d/msg/joomla-dev-platform/QikDqThfFN4/elGt0....
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

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

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.

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

On 11 mai, 23:55, Amy Stephen <amystep...@gmail.com> wrote:

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

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.

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.

...

read more »

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/joom...

New Model:
https://github.com/joomla/joomla-platform/blob/staging/libraries/joom...

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

On 13 May 2012 00:40, Ofer Cohen <oferc...@gmail.com> wrote:

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

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

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?

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

On 14 May 2012 08:02, Andrew Eddie <mambob...@gmail.com> wrote:

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/QSo...

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

Thanks in advance.

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

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

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

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

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

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.

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

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.

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.

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.

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

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

Correct.

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

And ditto again.

I prefer how Rouven uses a suffix.

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

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.

Hopefully I've covered it ok for you.

Regards,
Andrew Eddie

"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

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

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

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.

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

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

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

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

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.