Drop <jdoc:include

[dgrammatiko]

<jdoc:include type="whatever" /> is just a wrapper to a simple echo blabla

Check https://github.com/joomla/joomla-cms/blob/staging/libraries/joomla/document/html.php#L652-L706

This is what I use in my templates:

<?php echo $this->getBuffer('modules', 'slideshow', array('slideshow', 'html5')); ?>

which is the same as joomla's:

<jdoc:include type="slideshow" />

But is freaking faster as I don't parse/check/replace (of course I override all the renderer part of joomla but that's not the point here)

[tonypartridge]

I think the idea of it was to make it simple and easy to understand.

If there is a performance benefit then I see no reason why we can't refactor the documention on how I should be done, but I don't think we can drop it since every template pretty much uses it. Maybe push it as deprecated? But as 4.0 is a new release of course we can make a BC change.

[dgrammatiko]

@tonypartridge but every template will need at least some minor adjustments (BS2/3 won't cut it)

[tonypartridge]

But whilst J4 will be BS4 we won't be forcing BS4 on the frontend and as most of the DEVs these days load in their own or a vanilla version of jQuery anyway I've found they don't call the Joomla! jQuery/Bootstrap library in and instead use their own.

[ghost]

@dgt41 I see what you're saying, I agree with @tonypartridge - the syntax is much easier to understand. I think the view file syntax is a little overcomplicated in general already.

As I've said, I think a front end API is necessary at some point, and I think that would be the time to make a change like this. I personally don't think we should mess with it right now, but it should be addressed in the future.

[mbabker]

Honestly, I don't think you can get the layout files (anything loaded in component, module, JLayout, or JDocument scope) much more simple than they are. The ones that are overly complex are trying to do things like support dynamic grid widths or ACL checks in the layouts for things like "register to read more"; the grid one by its nature can't be simplified much. In general, the only way to make them less complex is to take PHP logic out of them, but how much of that logic is really stuff that can/should be moved away from the rendering layer?

You can "hide" some of it by implementing a "real" templating system that might give an environment people are more comfortable in (the folks I work with have had an easy time adapting to Twig layouts in our current Symfony builds, actually one of my coworkers found Twig's structure and integration into Symfony easier to work with than Joomla's rendering layer) but that's honestly just overhead on top of what we already have; unless you're running an environment where you have a compiled cache it really isn't efficient to try to use Mustache or Twig (even Blade goes through a compiling process and it's mostly PHP already, check your cache directories if you're using any Akeeba products).

Just for a visual comparison, here is our joomla.org template as:

• JDocumentHtml index.php (so a normal CMS install)
• Twig layout
• Plates layout

As for replacing the <jdoc> tags with their native PHP equivalents, any time you can replace a preg_* call with native PHP you're helping your performance out a fair bit. It might be "easier" to follow for non-PHP folks if the getBuffer method were named something less technical (getSection perhaps?), but that doesn't change the fact you're in a PHP environment.

[ghost]

I agree it's fairly simple now in terms of , what I'm saying is we should not it make it more complex if we can avoid it. We'll be looking at huge documentation changes if we change that format, we need to think about that side as well.

I am in favor of a "real" templating system, I like twig as well. I'm in favor of anything that helps users tap into the functionality easier. I think a lot of people struggle with the relationship between template view files and layout files, since some views come from the core and some come from the template. I understand it, but a lot of people don't.

One thing that's been on my mind is the modules.php / chroming implementation. That's one of the few places we still use static functions, maybe that becomes an object and opens some doors to other possibilities. The development of that is a little over my head and may be outside the scope of J4, but I know we could do something more with that functionality. It kind of seems out of place and "old-school" compared to everything else in Joomla. That's just my opinion.

[tonypartridge]

I completely agree, let's be honest documentation isn't a big issue since it's a mess and needs an overhaul. Maybe we do a whole new docs section too ;-)

On Wed, 7 Dec 2016 at 20:38, Cliff notifications@github.com wrote:

I agree it's fairly simple now in terms of , what I'm saying is we should not it make it more complex if we can avoid it. We'll be looking at huge documentation changes if we change that format, we need to think about that side as well.

I am in favor of a "real" templating system, I like twig as well. I'm in favor of anything that helps users tap into the functionality easier. I think a lot of people struggle with the relationship between template view files and layout files, since some views come from the core and some come from the template. I understand it, but a lot of people don't.

One thing that's been on my mind is the modules.php / chroming implementation. That's one of the few places we still use static functions, maybe that becomes an object and opens some doors to other possibilities. The development of that is a little over my head and may be outside the scope of J4, but I know we could do something more with that functionality. It kind of seems out of place and "old-school" compared to everything else in Joomla. That's just my opinion.

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

[dgrammatiko]

any time you can replace a preg_* call with native PHP you're helping your performance out a fair bit

This is performance driven request (for comments). We can make this so it supports both syntaxes (I think, have to check that)

[mbabker]

You could possibly throw a flag into JDocumentHtml that tells _parseTemplate() to not run the regex otherwise I don't think you really need to make any changes to say "I'm not using <jdoc> tags, don't even bother doing this". Can't say I've ever tried it though.

[ghost]

Documentation is a huge issue, it's better than it's ever been, but it is the way it is mainly because we don't have enough people to help write it. My feeling is the more simple we make the operations the more simple the documentation can be and the faster it can be written. The easier it is use, the easier it becomes to document.

@dgt I think supporting both forms of syntax is a fair compromise. People can use the old way if they want to, it's BW compatible, and we can introduce new concepts at the same time without throwing the documentation and translation teams under the bus. That seems like a very reasonable solution to me.

[dgrammatiko]

@mbabker do you have a PR for breaking up the head.php to meta, styles,scripts?

[mbabker]

Nothing I could find in any resources I have right now, and even if I did, my last "messing around" work was before Andre's changes in JDocument and JHtml so they'd have to be redone anyway. You're better off starting from scratch.

[mbabker]

You might be thinking of https://github.com/mbabker/joomla-next/commit/5df35cafedb0854d27692ceb31504ff93ea59ec4 where you did it. We could still do it with 4.0, the <head> renderer would have to remain and just be a proxy to calling each of the individual sections in order.

Though as an overall concept it still needs work (we still need to be able to define through JHtml and JDocument whether script elements should be loaded in the head or body as an example).

[dgrammatiko]

Can I introduce open graph and twitter card tags in the meta as well? I think I have something for the scripts as well

[brianteeman]

Personally that should definitely be a plugin and not something for the default. but also that makes no sense in the admin ;)

On 7 December 2016 at 21:35, Dimitri Grammatikogianni < notifications@github.com> wrote:

Can I introduce open graph and twitter card tags in the meta as well? I think I have something for the scripts as well

— 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/261#issuecomment-265580712, or mute the thread https://github.com/notifications/unsubscribe-auth/ABPH8Z_A6RVx8q9s8t_QVC5g4tQEAKf1ks5rFya0gaJpZM4LAIrx .

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

[dgrammatiko]

og and twitter cards are like an extension of html standard tags... Everybody uses them

[brianteeman]

Everybody doesnt. Not globaly ;)

On 7 December 2016 at 21:45, Dimitri Grammatikogianni < notifications@github.com> wrote:

og and twitter cards are like an extension of html standard tags... Everybody uses them

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

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

[mbabker]

Out of scope for this repo but we do need to improve our metadata handling in general. You can still only set one tag with the setMetaData() method and have to rely on custom tags if you're doing something that supports multiple tags (i.e. OpenGraph's og:image tags).

[Joomv]

OG and Twitter Cards in a backend template .... why?

For Frontend, I agree we need much better Meta Handling, but why would you want those tags loading in the backend?

[tonypartridge]

As above, it's ;pointless in the backend!

Sent from Nylas N1, the extensible, open source mail client.

On Dec 8 2016, at 10:06 am, Rowan Hoskyns Abrahall notifications@github.com wrote:

OG and Twitter Cards in a backend template .... why?

For Frontend, I agree we need much better Meta Handling, but why would you want those tags loading in the backend?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

[dgrammatiko]

@tonypartridge @Joomv @brianteeman the whole conversation in this issue is not bound to admin template, since the changes suggested are one level above the template, at the JDocument class. Obviously I am not suggesting og and twitter cards for the atum template...

[wilsonge]

I'm going to close this. I don't see any need for us to remove the <jdoc:include type="whatever" /> stuff right now. it's change for change sake