Framework changes

[Amy Stephen]

 

Finally I'd still be interested to know all said and done are the deprecations being made in the new Framework too much for it to be introduced into Joomla 3.2/3.5?

This point came from a CMS discussion and I think it is a good one to consider.

If there are changes to a package that change it's API and result in new deprecations that are not in the platform, how will that be handled?

Will there be a list? A place to go to track this?

Thanks

[Andrew Eddie]

On 15 March 2013 06:44, Amy Stephen <amyst...@gmail.com> wrote:

 

Finally I'd still be interested to know all said and done are the deprecations being made in the new Framework too much for it to be introduced into Joomla 3.2/3.5?

This point came from a CMS discussion and I think it is a good one to consider.

If there are changes to a package that change it's API and result in new deprecations that are not in the platform, how will that be handled?

That's a good question to ask. I envisage uptake of the FW on a number of fronts:

1. People like Chris Davenport can start using it today to build the CMS's new services layer. It's opt-in and there's no risk of breaking anything so it's an ideal candidate for that.

2. People like Michael Babker can start porting parts or all of the new issue tracker to use native FW packages. Again, it's isolated, nobody relying on it; nothing to break.

3. Extension developers interested is writing an SDK should start to look at what we've done and have a long hard think about how they can design that layer to be strong and future proof (as much as anyone can do anyway).

4. CMS contributors might look at new or better features being developed in the FW and want to include some of them in 3.2. For example, say the Github package gets upgraded in the FW and is much better than the "platform version". The CMS has two choices:

a) It just upgrade it's platform code to be in sync with the FW Github package

b) It freezes it's Github package in the platform and adds the FW Github package to be opt-in for extension developers

The question is all about how long the CMS wants to keep extension developers in their comfort zone. Personally, I would go for option be and say that in CMS 4.0, we will drop any platform package where there have been a FW package added. So, for example, say Github and HTTP get added from the FW in CMS 3.2. The CMS could deprecate those packages in the CMS platform and then drop them in 4.0. But, ultimately, that is a decision for the CMS and the extension developers. I can force that decision, just imagine what I think could be a sensible approach.

 

Will there be a list? A place to go to track this?

Most package will be extremely close to their originals. I wasn't going to track the delta because we aren't forcing any developer to change, and to use the FW you have to rewrite a fair bit of code. We'll have a good set of API docs and hopefully, if developers get behind improving the README files (Joomla developers - YOU need to help with this if you are using our code for free - pick it up!), they'll have good resources to write new code.

The other aspect is that the FW is not for developers that just like to "coast" with their development practice or don't like stepping out of their comfort zone. Developers are going to have to learn some new tricks. So I don't think we need to make a blow-by-blow delta tutorial, but if someone wants to volunteer to write one, we'd be happy to include it in the repo or we can link out to blogs (if you have the information, I have no problem promoting offsite links).

Hopefully that helps a bit. But if people want more, well, you know, they are just going to have to chip in.

Regards,

Andrew Eddie