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?
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.
--To view this discussion on the web visit https://groups.google.com/d/msg/silverstripe-dev/-/aaJerTbaC-IJ.
You received this message because you are subscribed to the Google Groups "SilverStripe Core Development" group.
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.
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)
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.
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.