2

I want to apply this fix to an IE 10 problem. The thing is you could argue this fix should be applied to all controllers. I was thinking of having a base controller putting it in that and then all my controller extending that.

Anyone see anything wrong with this approach?

  • 1
    Not enough to warrant inheritance imho, inheritance is great when you want to reuse massive amounts of logic, for just a line of code, it might be overkill. Another motivation I reckon is you want to build an 'interface like contract' to force implementation. Wondering if an interface is lighter and cleaner. – techtrekker Apr 2 '13 at 19:50
  • How'd you go with this @MoreThanFive? – bigassforce Apr 15 '13 at 8:16
2

Why not use an apex:composition containing your template, whose controller serves that header. Then your pages can use that as a template, without needing to duplicate that logic into their own controller. Here's clarification:

IeTemplate.page

<apex:page
docType="html-5.0"
showHeader="false"
standardStylesheets="false"
controller="IeTemplateController">
  <head><title><apex:insert name="title" /></title></head>
  <body><apex:insert name="body" /></body>
</apex:page>

NiceComposition.page

<apex:page docType="html-5.0" standardStylesheets="false" showHeader="false">
  <apex:composition template="{!$Page.IeTemplate}">
    <apex:define name="title">your title</apex:define>
    <apex:define name="body">your app here</apex:define>
  </apex:composition>
</apex:page>

IeTemplateController.cls

public class IeTemplateController { 
  public IeTemplateController() {
    Apexpages.currentPage().getHeaders().put('X-UA-Compatible', 'IE=edge');
  }
}

This may be preferable for a couple of reasons:

  • a site with many pages or an app with many screens may use a composition anyway,
  • instead of dirtying the inheritance model, the HTTP header is coupled into the view instead,

But really, it must be frustrating that the meta tag approach doesn't work in the first place :-(

| improve this answer | |
  • don't fully understand. And why is this approach any better? – More Than Five Apr 2 '13 at 16:51
  • Can the pages still have their own controller? – More Than Five Apr 3 '13 at 15:00
  • @MoreThanFive yessir – bigassforce Apr 3 '13 at 15:13
1

Absolutely nothing wrong with it, IMO. The canned "this isn't what inheritance is for" response doesn't apply here. In fact, if anything, this is what inheritance is for - you want all child controllers to inherit this behavior from the parent. The fact that you're only reusing one line of code is your business and does not affect the validity of using inheritance here.

I would go for it, primarily because it will make it harder for developers and maintainers to forget it. If every controller has to extend your base controller, it will look obvious when you open a non-inherited one. It is MUCH less obvious when you look at a class without a constructor, especially if your team doesn't always put constructors at the same spot.

As a teeny side benefit, it's a bit less typing than calling out from the constructor, at least in the cases where you wouldn't otherwise need an explicit constructor.

There is no counter argument I can see, unless you have some edge case where the IE header is undesirable (maybe a non-html content type?). It also does not preclude you from using additional layers of inheritance for your controllers, since if you needed a couple controllers to inherit from a "different" base class, you'd just make that new base class inherit from your main base controller.

| improve this answer | |
0

I'd be inclined to just put the line into a static utility method in another class, and then have all controllers call that.

Yes you'd need to put it in every controller, but on the other hand if the content ever needed to change you'd only need to change it once. Even if you use inheritance you'll need to include a line for the base class in every class so this is much the same, just with a 'cleaner' (in the eyes of some) structure.

| improve this answer | |
0

Food for thought: add the X-UA-Compatible header by leveraging a Visualforce component. If you squint, it looks like the meta tag ;-) not perfect, but maybe preferable to inheriting controllers. You can genericize it for other headers, too.

NicePage.page

<apex:page>
  <apex:sectionHeader title="herp derp" />
  <c:httpHeader key="X-UA-Compatible" val="IE=edge" />
</apex:page>

HttpHeaderController.cls

public class HttpHeaderController {
  public String AttributeKey {get; set;}
  public String AttributeVal {get; set;}
  public void getSideEffects() {
    ApexPages.currentPage().getHeaders().put(this.AttributeKey, this.AttributeVal);
  }
}

HttpHeader.component

<apex:component controller="HttpHeaderController">
  <apex:attribute name="key" type="String" assignTo="{!AttributeKey}" description="HTTP header" />
  <apex:attribute name="val" type="String" assignTo="{!AttributeVal}" description="String value" />
  {!SideEffects}<!-- Do not depend on a setter method being evaluated before a constructor. -->
</apex:component>

http header via component

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.