Implicit base tag?

[Sam Minnée]

<% base_tag %> is the one piece of boilerplate that we have in templates. It is included to provide a way for sites to be portable, able to run in subfolders as well as different domains without links breaking.

However, it would be easy enough to have this automatically added at the top of the head tag, without the need for the "<% base_tag %>" text in the template.

This has two advantages:

* Less boilerplate in templates.

* It would open the door for experimenting with other link handlers. For example, rather than creating a base tag, we could rewrite all the links to start with "/", putting the relevant prefix in if a site was running in a subfolder. There are some edge-cases (static publisher, badly coded proxies and search spiders, #-links) where the base tag is a pain, and, although we need to keep site portability, we're not wedded to the base tag.

It has the disadvantage of adding another piece of magic, but we're doing that with Requirements anyway, so I don't see that as a big deal.

What do people think?

[Jeremy Thomerson]

I'd want whatever we do to be configurable.  I'm not a big fan of using the base tag and would prefer a pluggable / configurable absolute link alternative.

Jeremy Thomerson

[Sam Minnée]

> I'd want whatever we do to be configurable. I'm not a big fan of using the base tag and would prefer a pluggable / configurable absolute link alternative.

Yeah, my thinking is that we could turn the following pieces of functionality into a list of output post-processors:

- Adding Requirements JS and CSS
- Adding <base> tag or rewriting links as appropriate
- 2.3-style XHTML content negotiation (still in core but disabled by default; a little obsolete now that HTML5 is favoured over XHTML)

It probably makes the most sense to configure this stuff controller by controller, and that in addition to that there might be a default.

[drzax]

The automatic injection of Requirements has been a real thorn in my side for a long time (so much so that I've written my own class to replace it on the front end of all sites we build). I've been considering for a while the possibility of redeveloping my new classes to match the Requirements API so it can properly be a replacement, but that's a big job.

So, that's a round about way of saying I'm strongly against anything that automatically injects code into my HTML.

[Hamish Friedlander]

Yeah, I've had to do that (tweak Requirements_backend) occasionally too.

Maybe a good compromise is that you _can_ add explicit tags into your templates (and we can add support for explicit tags for where javascript & css requirements go), and then if they aren't called anywhere in your template, auto-inject them.

Auto-injection is a pretty big performance hit on big pages (build the whole page as a string, inject something into that string is a pretty heavy operation), but having it gives a definite "it just works" advantage. Part of a lot of modern framework design is to reduce the amount of boilerplate that's always the same but which is required by the framework.

I don't think we can replace the base tag with clever-er link processing though. I have had situations where we can't add a base tag at all (firefox has a long standing bug with the base tag and inline svgs with partial fragment URLs), so I'd love to get rid of it, but consider this javascript:

   my_custom_ajax_method('a/base/relative/url');

How would the URL rewriter know that first argument was a URL that needed base-ifying? 

Hamish Friedlander

--
You received this message because you are subscribed to the Google Groups "SilverStripe Core Development" group.

To view this discussion on the web visit https://groups.google.com/d/msg/silverstripe-dev/-/aaJerTbaC-IJ.

To post to this group, send email to silverst...@googlegroups.com.
To unsubscribe from this group, send email to silverstripe-d...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/silverstripe-dev?hl=en.

[Al Twohill]

In my view <% base_tag %> is such a tiny insignificant amount of boilerplate I don't think it's worth the effort to remove it. Are you planning to automagic other extraneous* plating like <html>?

I'm all for making things easier, but not for things that tunnel SS into being only suited for generating html markup. One of the things I love about the .ss template language is it can be used for xml, js, json... I think you get my point.

- Al

*(normally)

[Sam Minnée]

The base_tag is unique in that it's the only piece of boilerplate unrelated to the HTML itself. We wouldn't remove <html> because that's not SilverStripe boilerplate, it's HTML, and as much as possible we want to leave people in control of their HTML. We work on the assumption that people writing .SS templates know HTML already.

Although it's small, removing it reduces our SS-specificboilerplate by 100%, which was why I was keen to do it.

Refactoring both base_tag and Requirements into output processors, if anything, would make it cleaner to use the template engine for non-HTML. I agree that we should maintain that ability.

Ultimately, what's "worth the effort" depends on who's going to do the pull request. ;-) I was keen to hear about whether people thought a shift to making it implicit was a better or worse architecture.

[drzax]

In that case, my view is implicit = worse. Implicit is probably okay if there is an option to turn it off. As you mentioned, I want 100% control over the output generated by the templating engine, and implicit output breaks that.

The only two areas that currently break that are requirements and forms, it would be best not to add another.

S.

[Sam Minnée]

I see your point - 'remove implicit magic' might be a better goal than 'remove boilerplate'.

Note that in the current SS3 beta, forms don't break that. Form HTML is templated, and you if you want to do one off forms it's pretty straightforward by doing <% with Form %> rather than $Form.