search

solidusjs / solidus

A simple server that generates pages from JSON and Templates
MIT License
28 stars 7 forks source link

Add Handlebars Helpers #72

Closed Fauntleroy closed 10 years ago

Fauntleroy commented 10 years ago

I've added the helpers from https://github.com/SparkartGroupInc/handlebars-helper to the view rendering engine. Not sure exactly what to do about using these client side, other than telling users they'll need to include Handlebars Helper there...

Fauntleroy commented 10 years ago

@pushred this should be an easy approval

Fauntleroy commented 10 years ago

@pushred I'm going to go ahead and merge this into master along with the preprocessor branch. These changes will start 0.1.x.

Fauntleroy commented 10 years ago

So, the only reason I haven't merged this in already is because I'm having trouble figuring out our relationship with client site templates. Right now we do all sorts of silly magic, like automatically include Handlebars, when users choose to use client side templates. However, as we've moved forward with RequireJS, it's becoming clear that this automatic bundling system is causing some trouble. The most obvious trouble I've seen is uncertainty when working with Sparkart.js... in the past we expected to just concat javascript files, but that's not what we're doing anymore. Now the automatic inclusion of handlebars with the templates is an anti-pattern, so we need to figure out a way to give them these templates client side in a modular way.

Here's what we've got to make available on the client side:

In the future we may switch to Browserify, or at least enable it, so we'll probably want to figure out some way to make these all available with UMD.

pushred commented 10 years ago

Yeah, I still haven't figured out how to use Sparkart.js across multiple modules. I shimmed it on Keith recently conform it to the RequireJS way of doing things rather than the global it was designed around. But since the instantiated fanclub relies upon an async call to services.sparkart.net it doesn't really work properly in other modules. They timeout I believe. This plugin addresses that problem but I haven't had time to try it out.

Rafael is using this plugin in hipster-tools, it solves some of the problems here but it would require a rewrite of Sparkart.js effectively. It has some weird caveats like partial naming restrictions that could be deal breakers. Funnily it shares your JSON-in-a-comment metadata implementation. Browserify has this.

Sparkart.js is really due for a big refactor/rewrite anyway, it could really be slimmed down. Date formatting for instance is supplanted by the helpers, and it still has remnants of the login/account/password reset plugins, Facebook login, etc. That all needs to be handled by services now due to the cross domain issues we ran into.

In the end I'd question how unique are these features offered by the library to our own API? The features it offers (resource fetching, preprocessing, template rendering) sound a lot like Solidus. The big difference for our API is that we must make requests directly in order to access the session. But the proxy isn't required to access resources in Solidus either, so it seems that the ultimate implementation could very well fall in line with #43 and related efforts.

IMO, ideally each widget would be a separate module, just as other capabilities (i.e. a Twitter feed or a photo slideshow) could be. What's so great about RequireJS and Browserify is that they manage the dependencies in a way that concatenation never could and pave the way for package distribution.