What's the plan for extensions?

[laoneo]

I had a quick look and I really like the way this template is heading to. The problem comes for extension developers as we have to deal with BS2 and BS4.

Made a test installation of DPCalendar with no adoption:

Is there a plan to avoid having two different extension code bases for Joomla 3 and 4? I guess we should be prepared for this situation.

[C-Lodder]

I thought this is what the other J4 repo was for? Weren't you and other working on some way to allow BS2 and BS4 layouts or something?

[dgrammatiko]

https://docs.google.com/document/d/1e4XhmjyTRiQmNTjhUr-94Ikga9yOvVGn3Okj_0D-xPU/mobilebasic

No decision AFAIK

[C-Lodder]

@laoneo - I haven't yet tested any 3P components. I'll do this in the next week or 2, once I've done a merge of the staging branch. Just an FYI, I can't promise the styling working 100% on your component. BS2 and BS4 are very different, so be expected to make at least some styling changes, as this is a major version update

[laoneo]

The PLT still needs to make a decision on our proposal. So don't expect something in the closer future. Just tought, perhaps you guys were doing some stuff already into that direction. Always looking for new inspiration :wink:

[C-Lodder]

Yeah no worries. I'll chat with George today and try to find out what's going on. Cause there only so much waiting we can do, until we make a final decision :)

[dgrammatiko]

@laoneo @C-Lodder @ciar4n I think using extend for the grid and some other elements we can go away from this B/C nightmare. I am NOT proposing a full compatibility here, but for the most parts BS2 things should and must render ok (-ish)

[ciar4n]

@dgt41 I agree. At some point we should give all BS2 elements some minimal styling.

[laoneo]

This would be only a solution in short therm, what do we do when BS5 is coming out?

[dgrammatiko]

@laoneo that's gonna be fun, especially if they drop jQuery. Because in such case on top of the styling and html structure also all the javascript will be broken. Prevention is the best cure. There are few proposals but people are on a denial mode

[mbabker]

If you keep writing abstraction layers in front of everything, it makes Joomla harder to adapt because you have to reverse engineer the Joomla code to figure out how something works because documentation is the second biggest joke in Joomla. If you don't put abstraction layers in front of stuff, you either deal with big migrations or you vendor lock to one version of one framework for all of time for the sake of appeasing people who want WordPress advertised backward compatibility of things that worked in 2009 still work without issue today. Or we go back to the days of old and write the Joomla CSS/JS framework and again make it hard to use Joomla by having to reverse engineer the templates to figure out what is even there, repeat documentation joke.

I still don't agree with cluttering Joomla's configuration and code with template specific parameters and layout path lookups. Ultimately you aren't fixing the issue by any means, you're just adding more junk in front of it to make it appear less of an issue. What was trying to be done with that other template repo still creates B/C hell for extensions, and I (as an extension developer) didn't find that any more acceptable than the current state because not only were you expecting me to start supporting multiple template frameworks and creating a system where extensions could be broken if they didn't support a template's framework, you were expecting me to either implement an abstraction layer between my code and the Joomla core to be able to support 3.x and 4.x in one code base or fork my own code and maintain two versions.

It is entirely possible to support two major versions of Joomla on one code base with different layouts for each version. That is a clean solution, that is what I did in 2012. Ironically my frontend layouts (component and module) didn't need transition layers so I was able to stuff classes (mainly for the tables) into elements and create working solutions without the need for complex code. Yes, I realize that's not the case for everyone, but I chose to go for the simplest working solution without creating additional complex code.

In the end, I still see all these abstraction layers and calls to advertise the active template framework as introducing more coupling in Joomla core to template frameworks and making extension developers' lives more miserable.

[ghost]

We definitely need to consider the future while we're doing this. One reason we've been stuck on BS2 for so long is because the implementation didn't consider what might be coming next.

Hindsight is always 20/20, but we should learn from the past and try to make it as easy on ourselves as we can. We should assume it will need to be upgraded at some point and plan for it as much as possible in my opinion.

[brianteeman]

One reason we've been stuck on BS2 for so long is because the implementation didn't consider what might be coming next.

Not true - we assumed it would have some semblance of backwards compatibility. We were wrong

On 18 November 2016 at 04:02, Cliff notifications@github.com wrote:

We definitely need to consider the future while we're doing this. One reason we've been stuck on BS2 for so long is because the implementation didn't consider what might be coming next.

Hindsight is always 20/20, but we should learn from the past and try to make it as easy on ourselves as we can. We should assume it will need to be upgraded at some point and plan for it as much as possible in my opinion.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/joomla/40-backend-template/issues/164#issuecomment-261443674, or mute the thread https://github.com/notifications/unsubscribe-auth/ABPH8aCUhIkjOBRzNXk1O5lagME29Yo6ks5q_SNAgaJpZM4KyO95 .

Brian Teeman Co-founder Joomla! and OpenSourceMatters Inc. https://brian.teeman.net/ http://brian.teeman.net/

[ghost]

Fair enough. My point is that we should learn from that experience and be prepared. The same thing could most certainly happen again.

[mbabker]

It's always an issue when you're using a third party software. So the options are to either not use it (reinvent all the wheels and embrace NIH), build a middleware layer (now you're complicating the adoption of whatever you're bridging because you have to find how everything is mapped), or use it and hope for the best (quickest and easiest solution plus we can still make use of the third party's own documentation).

[ghost]

I know. All I'm saying is we should consider this while we're working and try minimize the impact a framework update will have. We can't predict the future and some things are unavoidable but we should think ahead as much as possible.

[brianteeman]

If I could do that I would be a billionaire

[mbabker]

All I'm going to say is option one is unfeasible, we don't have the community resources to essentially rewrite and maintain and document everything ourselves.

A middleware layer, while doable, makes adapting to Joomla more complex. Especially with Joomla's history of crap documentation requiring developers to reverse engineer all the things.

The "just use it" option is the most dangerous in terms of updates. Just look at the current situation.

There is no winning answer. So for me right now we lean toward answering what is going to be the least painful to this project's resources to keep up with.

[ghost]

I'm not saying we should change the direction, there is no question BS4 is the direction we're going in.

I know we can't predict the future. What I'm talking about is being as practical and sensible as we can regarding the implementation. We may not know what specific changes might come in an update, but we do know an update will be coming at some point. We should consider this during the process.

[C-Lodder]

Personally I think it's too late down the line to start having this conversation. The migration from BS2 to BS4 won't be perfect. I'll be doing my best to try and ensure that it's as smooth as possible by mapping a lot of styling.

@laoneo - I've just looked at the DPCalendar code a little. Things like the tabs (shown in your screenshot), why did you hardcode them? Cause that's something that will make your life harder. If you use bootstrap.addTab then you won't have this issue and they'll look fine on J4

[dgrammatiko]

My request for Joomla.ui JavaScript abstraction is still open. The pros overweight the cons IMHO. The JavaScript coupling with bs is really restricting for frontenders..,

[brianteeman]

And the name of this repo is?

[mbabker]

@dgt41 Just propose it. I'm not going to immediately shoot it down, there are a couple of valid cases you've pointed out where it can be useful. I just get concerned with abstracting every little thing out in a way that makes it difficult to adapt stuff (like the GDoc's proposal of the j class prefix in front of all the things which by the time you've dealt with all the mappings you're practically running a fork of Bootstrap or the rendering layer gets massively complex and memory intensive trying to replace the classes in the rendered markup).

[laoneo]

@C-Lodder because I hadn't to do it till now, it was showing up fine in J3 all the time. I'v adapted the code for the next DPCalendar major and it shows better with now using the proper tabs helper. The sidebar is probably not implemented yet?

I think we can eliminate about 80% of hardcoded bootstrap CSS classes when we would implement the same for grids, like JHtml::_('bootstrap.startGrid');. But honestly I'm not really a fan of it.

[laoneo]

Why was this one closed?

[C-Lodder]

Oops, sorry, misclick on the checkbox