|Implicit base tag?||Sam Minnée||4/9/12 4:16 AM|
<% 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?
|Re: [silverstripe-dev] Implicit base tag?||Jeremy Thomerson||4/9/12 5:05 AM|
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.
|Re: [silverstripe-dev] Implicit base tag?||Sam Minnée||4/9/12 5:12 AM|
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
It probably makes the most sense to configure this stuff controller by controller, and that in addition to that there might be a default.
|Re: Implicit base tag?||drzax||4/9/12 6:57 PM|
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.
|Re: [silverstripe-dev] Re: Implicit base tag?||Hamish Friedlander||4/9/12 7:10 PM|
Yeah, I've had to do that (tweak Requirements_backend) occasionally too.
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.
How would the URL rewriter know that first argument was a URL that needed base-ifying?
|Re: [silverstripe-dev] Implicit base tag?||mobiusnz||4/9/12 7:19 PM|
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.
|Re: [silverstripe-dev] Implicit base tag?||Sam Minnée||4/9/12 8:12 PM|
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.
|Re: [silverstripe-dev] Implicit base tag?||drzax||4/10/12 4:50 PM|
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.
|Re: [silverstripe-dev] Implicit base tag?||Sam Minnée||4/10/12 4:53 PM|
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.