krotscheck at gmail.com
Mon Jan 13 02:56:54 UTC 2014
system, then handlebars is a fine choice. I'm not certain on how complex
status.html/status.js is, however if you expect it to grow to something
more like an application then perhaps looking at angular as a full
application framework might help you avoid both this growing pain and
future ones (alternatives: Ember, backbone, etc).
tooling that is built on top of Node.js, for which current official
packages for Centos/Ubuntu don't exist, and therefore infra won't support
it for openstack. Storyboard is able to get around this because it's not
actually part of openstack proper, but you might be forced to manage your
code manually. That's not a deal breaker in my opinion - it's just more
tedious (though I think it might be less tedious than what you're doing
On Sun, Jan 12, 2014 at 5:21 PM, Monty Taylor <mordred at inaugust.com> wrote:
> On 01/11/2014 09:56 AM, Sean Dague wrote:
>> As someone that's done a decent amount of hacking on
>> status.html/status.js, I think we're getting to a level of complexity on
>> our JS status pages that we should probably stop doing this all inline
>> (probably should have stopped a while ago).
>> and start incrementally porting bits over there over time.
> Yes. I believe we're at that point. I've also been learning about js dev
> and build toolchains, such as grunt, and I've been thinking that status.js
> might want to be in its own repo.
> My current thought is - http://handlebarsjs.com/ - mostly because it's
>> only a template library, won't cause us to do a complete rewrite, and we
>> can move it in in parts. Other opinions are welcome.
> storyboard and horizon are both doing things with angular.
> But if we get an ACK on some approach, we can then start phasing it in,
>> vs. the current state of the art which is way too much string append.
> Michael - any thoughts?
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OpenStack-dev