Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Expose a default Heist config #164

Open
cimmanon opened this issue Dec 22, 2015 · 1 comment
Open

Expose a default Heist config #164

cimmanon opened this issue Dec 22, 2015 · 1 comment

Comments

@cimmanon
Copy link

The heistInit initializer creates routes for all of my templates. Problem is, I never want this behavior. If I define a route that happens to overlap with the routes generated by heistInit: the raw template is served instead of processing my handler. I'm more than happy to use heistInit', but I'm forced to recreate the same config for every Snap application I write (which is extra troublesome when the API for it changes).

Snap.Snaplet.Heist.Internal creates the exact config I'd like to use, but it's inaccessible because it's hidden inside of gHeistInit. Would it be possible to expose this config?

@mightybyte
Copy link
Member

I'm conflicted about this. I see your point--I usually use heistInit' as well. Here are a few of the things I'm thinking:

  • We did change the HeistConfig API recently, but the whole point of doing that was to switch to a scheme that will be much more stable if there are more changes in the future.
  • I think you should be able to avoid the automatic heist routes taking precedence by playing with the relative order of addRoutes and heistInit.
  • Even if I do expose gHeistInit's HeistConfig, there is still plenty of room for trouble with API changes. For instance, right now it sets hcNamespace .~ "", but in the future I'd probably want to default that to "h".
  • What you're asking sounds pretty close to what is already available in heist's emptyHeistConfig
  • It's just 3 lines of code, which seems like a rather minor issue.

Given all these points I think I'm currently leaning more towards leaving things as-is, but I'm still open to being convinced otherwise.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants