Support

Hello Yannick,

sh404SEF support was removed, you should exclude ATS component from its list.
Regarding your URLs question, we have changed them because we updated the library used to power ATS (basically we rewrote everything from scratch).
There's no plan to change (or rewrite) the whole component in the near future. However you should watch out for the version number, since we are adopting Semantic Versioning: if the first number changes (ie from 1.x to 2.x) this means that the changes are not B/C.

Finally, CRON jobs are still the same: the filename and the accepted options are still the same, only the code inside them changed.

Hello Yannick,

First some generic observations regarding architecture.

None of the URLs produced by our core SEF router (router.php) has changed at all. I actually spent a lot of time making sure that the URLs remain the same. Moreover I made sure that throughout the 2.x version series all 1.x non-SEF URLs can still be parsed.

The only change that did occur is at the lowest level, i.e. at the non-SEF URLs. The view names did change from an all lowercase mashedtogetherwords scheme to a CamelBackedAndMoreSensible scheme. We made this change after a decade(!!!) of following Joomla!'s all-lowercase convention because, quite simply, CamelBacked is easier for everyone to read than mashedtogether.

Regarding the existence of View and views, it's not my choice actually. When you are creating menu items Joomla! expects to find the metadata.xml and the associated layout XML metadata files in the views subfolders. It uses those names to create the URLs stored in menu items. It's a very inefficient system that dates back to Mambo. That's why you think these folders are "stubs". They are not, they only contain the files Joomla! doesn't let me put elsewhere. As for the View folder, it has to be named like that to have PSR-4 autoloading.

PSR-4 autoloading is part of a bigger picture put forth with FOF 3. Until now Joomla! components have been isolated islands. If you wanted to use a model of my component in your component you'd have to include the file directly. When I refactored my code your component would break. As you know this is called tight coupling and we both know that this is why it's a Bad Thing. So FOF 3 does away with this by introducing the concept of the Container (which is in fact more of a service locator but the term "Container" was already used by Pimple and I decided to stick with it). Now, when you want to call a model of my extension you just have to do \FOF30\Container\Container::getInstance('com_ats')->factory->model('Tickets')->tmpInstance() and there you go. I can change which model extends what, the internal API, everything except the public API and your code will still work. You don't have to know which classes to preload, they are handled by the component's autoloader which is registered –if not already present– when you spawn the component's container per the configuration in the component's fof.xml file.

Moreover, if you really DO take a good look into the code you'll see that FOF 3 fixes the major design flaw in Joomla! 1.5 which was inherited by FOF 1.x/2.x: the separation of Model and Table. This –and the implied existence of ONLY a data-aware model and controller variant– was the source of the majority of bugs we fixed in all of our front-end software last year. FOF 3 follows a more logical approach. You have generic Controller and Model classes for non-data views and DataController and DataModel classes for data views. DataModels represent whole rows and return collections (instead of dumb arrays), making it possible to have actual relations. In short, you get an ORM. When you have complex, interconnected data an ORM saves lives and the developers' sanity.

Simply put, we had reached a point where any small change in ATS would cause an avalanche of bugs due to the precarious architecture that dates back to early 2013, when I wrote ATS as a quick proof of concept. It had to be rewritten or dropped. I decided to rewrite it.

Now to answer your questions precisely:

1 - Does it make sense to try fix the legacy template overrides. Are those legacy views going to be around for long? if yes, how can I ensure things like F0FTemplateUtils are properly loaded?

Legacy view templates will not work with ATS 2.x since the templates have been rewritten and the views refactored. We were doing a lot of WRONG things in ATS 1.x's view templates. The code was utter crap and I was truly ashamed to have published that.

2 - Same for URLs: can ATS 2.0 handle both old style (ATS 1.6) URLs and the new ATS 2.0 ones? how long will this last?

All ATS 1.x non-SEF URLs can be parsed perfectly by ATS 2.x.

SEF URLs created by our core router (router.php) are identical in both versions. WARNING!!! You MAY have to update your ATS menu items, i.e. edit each one of them and set the menu type to the new one. Our router.php tries hard to find menu items no matter if you use old or new view names but I may have missed a spot somewhere.

SEF URLs generated by our sh404SEF plugin should be identical to the ones created by the SEF router. I dropped the sh404SEF plugin because you told me a couple of years ago that this is no longer necessary, sh404SEF can use the component's router.php. If that's not the case we can rewrite that plugin. You're the expert on that.

3 - More generally, how does legacy views and URLs handling works and how long do you plan on maintaining this B/C?

Throughout version 2.x.

There are no plans for version 3.x yet and I consider it unlikely to have version 3 in the next two years. That would imply me writing a major version of FOF. I don't see that happening soon.

Disclaimer: if Joomla! 3.6 radically changes the routing and/or a new major Joomla! version is released that has nothing to do with the way any Joomla! extension currently works all bets are off. Of course in this case you;d be more affected than us in your main line of business.

4 - Are all cronjobs the same (from 1.6.1)?

Yes, completely the same. The idea was that the server and site setup should be as minimally impacted as humanly possible to ensure that I can update ATS within 5' flat.

If you do indeed make a B/C change (and yes, increase major number), we still have to update our sites and usually spend quite some time on it.

Yes, I understand that. We did everything in our power to make sure that the only impact to our users like you is in the view template files. They were really, REALLY badly written.

The URLs DO remain the same. We'd never tell our users "tough luck, all your URLs are invalid", more so when we're talking about public support tickets. That would be suicidal. What Davide meant with his comment is that in case you're listing somewhere on your site that ATS has a native sh404SEF integration you should remove that listing because it's no longer true. His comment on changed URLs was about NON-SEF URLs.

What matters is the decision to make a B/C break, not really the version number.

It was either that or discontinuing the software. It had reached the point where it was impossible to maintain. By introducing the container, PSR-4 autoloading and ORM we made it possible to maintain ATS again.

Since it's a public ticket I have to lay out the background for anyone who might stumble upon this ticket :)

I had thought about the Joomla menu requirements, but what puzzled me was that some of those legacy "views" views have also a tmpl folder, with some actual code in them (views/ticket, views/categories , view/buckets), but I guess this is an overview maybe and that code should be removed?

Hm, the installation script is removing the view classes and old view templates from these old folders. In fact, it's trying to remove the old folders completely. I'm not sure why these files were left behind. Ownership or permissions? Maybe leftovers from a very old 1.x (pre-1.4) release?

URL compatibility issue is just a bit trickier. You were right in that sh404SEF can use router.php (it actually always was able to do that), but removing the sh404SEF entirely can cause issues on existing sites, specifically if users "purge" URLs, for whatever (bad) reason.

Oh, crap! I wasn't aware of that :s I guess the only workaround is reinstating the sh404SEF plugin?

I never listed ATS has having an sh404SEF plugin (I don't maintain such list actually).

OK, thank you for the clarification!

1 - Templates: I actually disabled my overrides, and things are not bad, it's mostly CSS again (but a lot of it I'm afraid)

The view templates use the same hybrid Bootstrap 2 / Bootstrap 3 structure. However, in ATS 2.0 we made it easier for our CSS to NOT get into your way. Go to ATS, Options, Front-end and set Use Strapper to None. This will no longer load our namespaced Bootstrap 2.4 instance. I believe this will make your CSS work much easier.

2 - What matters is the non-sef, so if existing non-sef/SEF pairs are good, we're good. I'll redo my sh404SEF plugin anyway, so new URLs will be good as well (already done actually)

Yup! There's also a 1:1 mapping between old and new views (the tasks are deliberately the same). If you want me to give you the mapping so your plugin can work with either set of view names let me know.

Also let me know if I should be rewriting our old sh404SEF plugin or you intend to make yours available to our mutual clients.

I'll leave the ticket open. Do note that after 15 days of inactivity it will close automatically. If that happens and you want it reopened shoot me an email.

OK, I guess we'll have to get that plugin back :)

Please note that I said that the SEF router can handle old style non-SEF URLs to produce SEF URLs. What you describe is something else. You have an old style non SEF URL that you expect the Dispatcher to follow. That isn't guaranteed to work. View mapping is something I've only been playing with the last three weeks. We can talk about it tomorrow at the Joomla! Day.