B/C issue with renaming of JRules to JAccessRules

[Elin Waring]

Would it be possible to rename JAccessRules back to JRules as this change is causing breakage for people who are tracking assets at the item level. 

As an offender in this respect myself, I really can't encourage enough that changes with potential backward compatibility issues  without  tests  not be accepted. Just say no. 

Elin

[Andrew Eddie]

It should be fine if the CMS is using 11.4. There's are proxies for
JRule and JRules.

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

[Tom Fuller]

How does one access the proxy? Currently calling JRules() from 2.5 breaks.

[Andrew Eddie]

You should already be including a line like:

jimport('joomla.access.rules);

in your code in 1.6/1.7 to be able to access that class. Add that in
and see if it works.

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

[Herman Peeren]

But Tom is using a JTable-child. In 1.7 the whole file was jimported in the JTable-parent and so JRule(s)  could be used in a JTable-child; no need for the jimport in the JTable-child-code. But in the new JTable-parent (and in other core classes that call JAccessRule(s)) the classes are autoloaded and so the whole file is not loaded into that parent class and the proxy is not found.

A solution for BC could be to also put the JRule(s) proxies in a place where the autoloader can find them. That fix should only be necessary in the CMS (the framework doesn't need to be BC) and it can be removed in 3.0.

[Andrew Eddie]

So, realistically, the problem is temporary.

After a month or two, developers can safely change to using
JAccessRule/s directly and the auto-loader will pick it up. The
awkward period is where they want to support 1.7 and 2.5 at the same
time, which is reasonable to do for a while. The workaround is simply
to add the jimport call into the custom extension which will work for
both 1.7 and 2.5.

I guess the CMS could add it in, and since the rules are so common
(virtually every page load will use the class), I'd just add it to the
jimport to the framework.php files. That's a less painful approach
for the developer but it's a bit like using the @ symbol to hide
errors.

Either approach works but I think the first is better.

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

[Herman Peeren]

It's just a small temporary fix, but I think to add the JRule(s)-proxies to libraries/cms (so the autoloader can find them) is a better approach then adding the jimport to framework.php (for then the files are always loaded). I'll put a patch in the tracker-item  http://joomlacode.org/gf/project/joomla/tracker/?action=TrackerItemEdit&tracker_item_id=27656

If the CMS wants to be backwards compatible between 1.7 and 2.5 (that is: any extension working in 1.7 should then work in 2.5) then a fix should be applied.

[Andrew Eddie]

Sounds good.

@Tom, in the mean time, just add the jimport to your component and
everything should work file in 1.7 and 2.5 betas.

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

[Elin Waring]

It actually is not fine, Andrew, as we all know "should be" is nice but != "is."

It is simply not okay to create fatal errors in applications that have happily been using your api. When people update the CMS and get the new platform things are going to break and end users are going to have fatal errors. Fortunately Tom is one of those developers who tests on beta and picked this up.

jimport does not fix the problem as is explained in the main thread on this issue. What fixes the issue is for him to change from JRules to JAccessRules.  But people should not have to change their code if changes in the platform are made. Yes they CAN, but they should not have to, not unless there have been months of deprecation notices. This was not even added to the list of b/c issues.

There is no question that the CMS needs to be backward compatible and extensions should not break and that the platform change broke them. Obviously there will remain breakage for any other platform applications that might have been extending JTable but obviously the platform team can work with its other customers to fix just as well as with the cms if it is going to break b/c and wants to have that reputation.

Thanks

Elin

[Tom Fuller]

Thank you, Andrew - adding the jimport line does temp fix the problem. I'll continue testing now and wait for a decision from you fine folks.

Tom

[Rouven Weßling]

I have a patch ready to test here: http://joomlacode.org/gf/project/joomla/tracker/?action=TrackerItemEdit&tracker_item_id=27656

This fix is only at the CMS level but the platform could pick it up.

Rouven

[Herman Peeren]

Yep,  this patch looks better than mine. Thanks Rouven,

[Andrew Eddie]

/me slaps forehead - of course jimport won't work.

@Tom, try this in your extension until a patched beta comes out:

JLoader::register('JRules', JPATH_PLATFORM . '/joomla/access/rules.php');
JLoader::register('JRule', JPATH_PLATFORM . '/joomla/access/rule.php');

I think I got that right.

@Rouven, thanks for the patch (minor typo in it).

@Elin, I don't necessarily disagree with you, but neither do I
disagree with the autoloader change so, for me, it's less effort for
the major downstream users of the platform (Joomla CMS, maybe Molajo,
although they had a hang-up with JRules and might have thrown it out,
and possibly Square One falls into that category) to add the 2-line
workaround given 11.4 has bolted and the master branch is tainted and
the nett benefit to developers outweighs the inconvenience (my opinion
and I don't really mind if you disagree with that position). Note,
this paragraph is also longer than the actual "fix" :)

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

[Elin Waring]

Hi Andrew,

I wasn't actually necessarily saying to change the name, that was more of an opening gambit, but just please to fix it. :) 

The autoloader is great, but just as with everything we need to make sure it doesn't break stuff and it's no different than anything else in that. In this case I don't know if it was that tests broke and then  instead of fixing the code the data inputs to the tests from the content and categories tables were changed or if there was just massive copy and paste and then the idea that there are tables not in the platform that would be tracking item level assets was kind of forgotten. In this case I feel the situation was particularly bad because ACL is a centerpiece library of the Platform as well as a center piece of CMS 1.6-2.5, one we really asked developers to engage with, and that some like Tom did.  One click updating is also something we have asked our end users to embrace but if it breaks their sites, even if the fix is simple, there are going to be people who never move to 2.5 even for security issues.

All in all it's solved for the CMS and other downstream users can deal with it, but I think it's an important lesson and reminder. For example ... maybe the platform team should have sent out a note announcing the need to add those lines prior to making the merge.  I don't write libraries with 1000s of lines of code, but I am a code contributor, and I do know that the Joomla! Platform should be a platform that respects application developers and that does not make unexpected, application breaking changes and if it does happen unintentionally, for whatever reason, that it makes things right. Which is what has happened so that's all good.

There are plenty of places people can go to get php frameworks that don't care about backward compatibility.  Those of us who have been around for many years know that there have been dark days of constant breakage and of commits to the trunk that took months to recover from. We just need to be  vigilant on this, all of us.  That's why we need more and more people doing code review and commenting on pull requests in addition to writing tests.

Anyway, this shows why you do betas. 

Elin

[Tom Fuller]

I just wanted to add a note thanking all of your for your interest and diligence in this matter. It really makes us developers feel good (once again) about being in the Joomla! family.

Tom