Global configuration about fortitude HOT 2 CLOSED

Aha. Yeah, the “docs” need a ton of work. (I think of it as “I need to write docs!”. :)

The configuration system is actually really flexible and I think will let you do anything you want. It’s actually quite simple underneath: any configuration changes you make to any widget class — whether that’s Fortitude::Widget (the base class), Fortitude::Widgets::Html5 (which inherits from Fortitude::Widget), some common base class you define that all your widgets inherit from, or an individual view — apply to that class and all classes that inherit from it, period. (Unless, of course, a subclass itself has a different setting for that configuration option.) You can even create a module that uses ActiveSupport::Concern and included do … end to apply configuration changes when included, and that'll work fine, too.

So, in short, you can do it any way you want:

Option 1 — global, just like Erector:

Fortitude::Widget.class_eval do
  doctype :html5
  start_and_end_comments false
end

Every single widget in the entire Ruby process, unless it overrides these, will use a doctype of :html5, and will have start_and_end_comments disabled.

Option 2 — your own base class:

class Views::Base < Fortitude::Widget
  doctype :html5
  start_and_end_comments false
end

If you now inherit all your widgets from Views::Base, they'll all inherit these settings, but if you included other code (yours, or someone else's) that inherited from Fortitude::Widget through a different path, your configuration settings wouldn't affect their widgets, by default. (Of course, you can just send the appropriate doctype or start_and_end_comments messages to their class, and it'll change that configuration, too.)

And, of course, there are plenty of other possibilities. Personally, I would recommend that people use option #2 — define your own widget base class (of any name you desire at all), and inherit from that. I like it because it encapsulates your configuration settings, if for some reason there are other, unrelated Fortitude widgets that get used in your system for something different; and I like it because it gives you a convenient place to override behavior, include or define global “helper” methods (using Erector/Fortitude-style helpers — i.e., just methods/modules/etc., rather than the completely-different-style Rails helpers), and so on.

But it’s really completely up to you. If you don’t like making a Views::Base class, feel free to subclass Fortitude::Widget everywhere and just apply configuration changes to it directly (with the one caveat that there isn’t a great place to include helpers — you can definitely do it on Fortitude::Widget directly and it will work fine, but it’s, yeah, a bit messy).

The only things I wouldn’t necessarily recommend are inheriting from Fortitude::Widgets::Html5 — it’ll work fine, but these “doctype-specific” widgets are really just intended as quick little helpers for one-offs, not things you should necessarily build significant systems on. And I wouldn’t recommend defining a Fortitude::MyWidget, just because that's in Fortitude's own namespace and hence could potentially conflict with something in the future.

Does that help you out?

from fortitude.

Yup, thanks for this! I'm pretty sure that once you respond to enough issues, it'll just be a matter of aggregating all of these fine answers and you'll have your docs written!

from fortitude.