Renderer: Bootstrap 4

[universewrld]

Since Joomla 3.5 support PHP 7, i think this is right way for support new technologies. I'm read, Joomla 4.0 coming soon later this year: http://magazine.joomla.org/issues/issue-december-2015/item/2911-introducing-joomla-4

just skip Bootstrap 3.x and put Bootstrap 4 support into Joomla 4.x

i think this is no big problem just rename some words in CSS code for compatibility with Bootstrap 4.

to follow new technologies, it is the only right way.

http://v4-alpha.getbootstrap.com/ https://github.com/twbs/bootstrap/tree/v4-dev

just follow this comment https://github.com/joomla-projects/joomla-pythagoras/pull/81#issuecomment-210920120 i think i'm no need again create this thread. this is 3rd time, when i'm start this requests

[HermanPeeren]

Please reread my comments in #81. This issue is superfluous and might come from not fully understanding the power of seperating content and rendering as envisioned in Joomla 4.

[nibra]

@sanek4life, this time you picked the right place ;)

In addition what was already said on the PR#81: The plans are to provide at least two HTML renderers already in the first release. One to support the Bootstrap version, that is currently used in Joomla 3. This is needed to allow the smooth upgrade, we want to achieve. The other will be a renderer, that supports the Bootstrap version, that is current at that time; that could be BS 4, but could also be BS 5 (don't hope that it takes that long, though).

However: One big gamechanger is the fact, that output behavior, like it's added by Bootstrap, not longer is in the hand of components. The site builder or integrator is responsible to choose the JS framework, s/he wants to use, and to find (in worst case: build) the suitable renderer.

So there is not longer anything like "core supported JS framework".

@HermanPeeren Thank you for your excellent explanation!

[universewrld]

@HermanPeeren & @nibra thanks!!!

how i'm understand, when i'm install Joomla 4 CMS, i'm just choice right framework for me, like now i can choise right components on JED and easy put in on my site, like "install framework from JED" button.

this is really dope thing. any framework support revolution on Joomla cms.

this is like, i can choose only Gantry 5 framework instead of Bootstrap on my site. cool.

[HermanPeeren]

Yep, that is the idea: to more easily use extensions in any UI-framework, preferably by not having to change the extensions at all. Just take another Renderer, that can be used for ALL extensions. Nice example of Open-Closed Principle.

[Bakual]

What I don't understand yet about that renderer system. As an extension developer, I don't expect templates developers to provide renderers for my component (as it's not popular enough). Assuming my extension falls into a custom content type. Which means users will ask me to create renderers for their templates. That's certainly not something I want to do. Or are those "renderers" easy enough to do for a John Doe User? Meaning are they as simple (or even simpler) as creating an override today?

If those renders can't be created by any user, then I see it being a bigger issue than the "soft lock" to BS2 we have in J3.

Or are those existing "renderers" flexible enough to handle most extensions today in JED? I can't imagine that yet.

[HermanPeeren]

@Bakual: "Assuming my extension falls into a custom content type".

An extension (in the new architecture) is not a content type. It outputs a content tree of which a part (maybe even a tiny part) CAN be a custom content type. The whole rest of the content types that are used are common. A content type can be a compound type (which is a standard content type!) consisting of other standard content types. In fact the content tree is an interface: both input and output. How you render that in HTML is mostly the same for different components. I think if we succeed in seperating the content (used in the component) and the renderer (which can be used for ALL content trees) then most extension builders don't have to think about rendering at all and extension builders don't have to all provide a rendering of their extension, because that is all the same for different components.

A renderer is NOT specific for a component! A renderer can render content trees (= a hierarchical collection of content type instantiations). That is the big difference from how it is done right now in J!3 and earlier: there a component is made for some kind of content type and that is rendered in a specific way. That is why you are confused by this: because you compare it with the current situation.

@Bakual: "Or are those existing 'renderers' flexible enough to handle most extensions today in JED?".

No:

1. those renderers are for the new architecture, where components use the interface (input and output) of the content tree. The idea is to show how easy it is to build extensions for that, a.o. because you don't have to worry about rendering and can easily use another renderer.
2. The "existing 'renderers'" are just prototypes and a start of what they should be. A lot of work still has to be done. At the moment there is work put in defining UI-elements like you see in Pattern Lab. Work is mainly done at the presentation side (the renderers), while at the domain side (the content types) a lot is still open. I even think those two (UI-elements and content types) are being mixed up a bit. BTW this is my opinion and I might disagree with that from @nibra's view. I'm investigating this now, have been thinking about it a lot lately and hope to be able to give some more strict definitions and examples soon, although I'm not part of the official J!4 Architecture working group anymore.
3. template overrides will still work and "extensions today in JED" will continue to work, although they will not benefit from the separation of content and rendering. Probably some extensions will become superfluous, because they are easier remade in the new system.

In short: the idea is to go a big step forward, offering opportunities for better extensions, while the old stuff still keeps working. It is work in progress, not finished at all. But just imagine what a possibilities if we would succeed in seperating rendering from components. Wow...

[Bakual]

I find the idea that I don't have to deal with frontend stuff fascinating. If that really works, that would be awesome of course. I think I need more specific examples (which are yet to be done if I understood correct) to see how that is supposed to work.

Maybe you can shed some light based on my own extension (http://www.sermonspeaker.net/listings/sermons.html). It's a sermon managing component. I can see some standard elements like listings (eg a table), an action menu (email, print, download) or the info block (speaker, published date, category, series). I imagine those are the content types elements? And for the media player on the page I would need to create a custom content type (or renderer) then?

[HermanPeeren]

Thanks for providing a concrete example. I will have a look at that and come back with some comment (and maybe @nibra will do so too).

What I myself am investigating at the moment is the border between content types (the semantic elements providing a specific kind of content) and UI-elements (the presentation elements to render the content-elements). Sometimes that border is clear, but sometimes it can be vague; I'm trying to sharply define the difference, but it is work in progress.

I see a table or a listing as a presentation element: you can present different information from different components in that way. But you could also present that same information as a slideshow or provide more information when you hover a text or you could print it on different cards or present the tekst in audio or .... The content type is probably what they have in common; different presentations is the result of using different (sub)renderers. But what exactly is "the semantics" of what that information has in common? That is still a bit vague. I don't like it if the content types are almost one-on-one similar to UI-elements (that would make the seperation redundant), but sometimes there might be some overlap.

I stop for today. To be continued (and then I'll look at the extension you provided as an example).

[nibra]

@Bakual : In your example, the detail view has an AudioElement, an AuthorElement, a DateElement, a DurationElement, and two LinkElements. It is very likely, that those will be standard elements, that are provided ba every renderer. You'll need custom elements only in very rare situations.

That way, a JSON renderer or a XML renderer can serialise the same structure in a way that is meaningful in their context.

[laoneo]

This renderer architecture sounds awesome. The only concern I have is how to deal with free text elements like the description field where the admin can put in any content (which can be BS 3 HTML content). How to handle that?

Another thing is how to deal with javascript? Must the extension developer create different content trees per renderer? For example showing a table of data which is fetched trough ajax and then somehow rendered on the client side. When the HTML renderer is called. then I create a paragraph and a javascript file which fetches the data in a async ajax call. When the JSON renderer is called, do I need then to fetch the data during the request and build a different content tree?

[nibra]

@laoneo: For the description field, there is no problem, as the admin knows, which renderer and JS framework are active on his installation. I still have some hope, that the UX team will find a solution to allow renderer-agnostic content creation in those cases, so the admin can address other content elements as part of the description element.

Regarding your second question: A component creates just one content tree. The renderer is used to serialise it according to its rules. In your example, you'd add the ParagraphElement and and an AsyncElement (absolutely not sure about the name here). The HTML renderer will add the required JS (not the component!). A JSON or XML renderer would add links instead.

The main point is, that the output produced by components is JS agnostic. There is a way through the content elements to demand some behavior (that's why our pattern catalog contains behavioral patterns), that is applied, if possible.

[laoneo]

@nibra but you can use more than one renderer on your Joomla site. One for HTML output, another for API access and the third one for Cli.

[nibra]

Yes, and all of them handle the elements in a way that's appropriate for their context. AJAX fx. makes sense for HTML only, so the other renderers have to deal with it in a different way. Thus adding JS to the content tree does not make sense.

[laoneo]

Instead of closing this one, should we not rename it to "Bootstrap 4 renderer" that we don't forget it?

[nibra]

Ok for me.