Google Groups

Re: [jplatform] Re: Simplified MVC.

Elin Waring Apr 9, 2012 11:07 AM
Posted in group: Joomla! Platform Development


On Monday, April 9, 2012 5:50:32 AM UTC-4, Niels Braczek wrote:
Am 07.04.2012 14:27, schrieb Andrew Eddie:
> On 7 April 2012 19:04, Niels Braczek <> wrote:

>> If
>> that means to go another way than just the pure academic one, it is ok
>> for me.
> I think we've established it's more than just academic.

Please understand me right: I'm just talking about the *naming* of the
interfaces. Everything else is just fine for me.

>> The goal for both platform and CMS should be to get rid of the legacy
>> library.
> Well, yes and no. [...] Why all the complaints about it all of a sudden?

I surely understand the need of the legacy tree, and what it is good
for, as I stated in my next sentence.

>> It is needed to get around unavoidable BC issues, but it is not
>> an invitation to break things, where it can be avoided.

> I think we are all good enough developers to acknowledge that and
> respect that we would judge such situations professionally.

I absolutely agree.

> There
> seems to be the perception evolving that Louis, Rob, Sam and I don't
> know what we are doing and couldn't care two hoots about the impact on
> downstream users just because we work at the same place.  That's a
> pretty bitter pill to swallow given our combined years of service.

I'm sorry, if that is what you read between my lines. That's not what I
tried to communicate.

>> One single issue
>> with that legacy library is that it prevents code completion from
>> working properly, because duplicate class names add ambiguosity, which
>> can't be resolved by an IDE (that problem exists in some other places,
>> too, but that should rather be fixed than be used as an excusion).
> That's actually a fair comment - not enough to move me, but fair.

I'm sure you'll agree, that duplicate class names should be reduced to a
minimum. It is a requirement of clean code.

>> So, just name the interfaces JModelInterface, JViewInterface and
>> JControllerInterface, and there abstract counterparts JModelBase,
>> JViewBase and JControllerBase. Each application (like the CMS) is then
>> able to provide their own base classes called JModel, JView and
>> JController. The CMS will just have to refactor their own three base
>> classes, and every existing extension will work *unchanged*. That's what
>> I'd call responsible improvement.
> And Rouven proposed a very simple forward compatibility strategy to do that.

Could you point me to that proposal? I must have missed it. The only
thing I found was, but that
does not solve the problem: If JModelBase implements JModel (an
interface), how can the CMS provide another JModel class which extends
from JModelBase?

> I may ultimately loose this battle, but I really dislike the
> *Interface naming because it's not the lead PHP takes itself, nor
> leading pattern architects like Martin Fowler and others I'm sure.  We
> don't do it for abstract classes and everyone seems to survive quite
> nicely.  The issue is, what we do for interfaces here, we set as the
> standard.

Well, I'm a fan of Martin Fowler, and he's always been a great
inspiration to me. But in this case, we are not free in our decisions,
since we've got dependencies. In this case, it is just a question of
naming. The 'Interface' suffix is not beautiful, but would allow a
smooth transition to the new MVC by refactoring just 3 classes in the
CMS. Without the suffix, several thousand classes and scripts have to be

> At any rate, even if the interface names didn't collide, we still need
> the legacy tree to buffer the changes in the CMS till at least 4.0 (2
> years away).

Accepted, since it is useful, even if it is not beauty. I guess we'll
always have some kind of a transitional tree, just to decouple
development cycles of CMS and platform. That makes sense.

> So I'm taking it that even if you think the code is
> good, the whole pull is a -1?

Absolutely not. I like the proposal. I'm just unhappy with the
consequences of the suggested naming.

> To me that's disappointing because it
> is a good refactor (in my opinion).  The platform simply doesn't need
> the current, very heavy and CMS centric MVC classes.

FullACK. The CMS should be able to adopt to the new MVC without pain,
and - what IMO is most important - without again forcing extension
developers to rewrite their code just because of naming issues.


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