Re: [openstack-dev] [infra] javascript templating library choice for status pages

2014-01-14 Thread Sean Dague
On 01/13/2014 04:28 PM, Michael Krotscheck wrote:
 On 01/13/2014 01:12 PM, Sean Dague wrote:

 Well, as an expert in the area, particular recommendations would be
 appreciated. I don't feel like we necessarily need one answer, but it
 would be nice knock some of the options off the table.
 
 I'd say: Start with handlebars, unless you want to lay application
 groundwork, in which case you should try angular.js.
 
 The former will be much, much faster, and have a shallower learning curve.

Awesome, thanks for the great brain dump, and explanation of the space.
Much appreciated.

-Sean

-- 
Sean Dague
Samsung Research America
s...@dague.net / sean.da...@samsung.com
http://dague.net



signature.asc
Description: OpenPGP digital signature
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [infra] javascript templating library choice for status pages

2014-01-13 Thread Sean Dague

On 01/12/2014 09:56 PM, Michael Krotscheck wrote:

If all you're looking for is a javascript-based in-browser templating
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).


Honestly, I've not done enough large scale js projects to know whether 
we'd consider status.js to be big or not. I just know it's definitely 
getting too big for += all the html together and doing document.writes.


I guess the real question I had is is there an incremental path towards 
any of the other frameworks? I can see how to incrementally bring in 
templates, but again my personal lack of experience on these others 
means I don't know.



Quick warning though, a lot of the javascript community out there uses
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 right now).


I'd ideally like to be able to function without node, mostly because 
it's another development environment to have to manager. But I realize 
that's pushing against the current at this point. So I agree, not a deal 
breaker.


-Sean

--
Sean Dague
Samsung Research America
s...@dague.net / sean.da...@samsung.com
http://dague.net

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [infra] javascript templating library choice for status pages

2014-01-13 Thread Sergey Lukjanov
Personally, I think that it's a great step now to move this code to the
templates. As for the huge frameworks - I prefer something like Angular.JS
or Knockout.JS.

Currently, the status.js file isn't so bug to rewrite it as a real life web
app and so, we could just add templates to make it much more readable and
improvable.


On Mon, Jan 13, 2014 at 5:05 PM, Sean Dague s...@dague.net wrote:

 On 01/12/2014 09:56 PM, Michael Krotscheck wrote:

 If all you're looking for is a javascript-based in-browser templating
 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).


 Honestly, I've not done enough large scale js projects to know whether
 we'd consider status.js to be big or not. I just know it's definitely
 getting too big for += all the html together and doing document.writes.

 I guess the real question I had is is there an incremental path towards
 any of the other frameworks? I can see how to incrementally bring in
 templates, but again my personal lack of experience on these others means I
 don't know.


  Quick warning though, a lot of the javascript community out there uses
 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 right now).


 I'd ideally like to be able to function without node, mostly because it's
 another development environment to have to manager. But I realize that's
 pushing against the current at this point. So I agree, not a deal breaker.


 -Sean

 --
 Sean Dague
 Samsung Research America
 s...@dague.net / sean.da...@samsung.com
 http://dague.net

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




-- 
Sincerely yours,
Sergey Lukjanov
Savanna Technical Lead
Mirantis Inc.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [infra] javascript templating library choice for status pages

2014-01-13 Thread Greg Hill
If you're just using it for client-side templates, you should be able to treat 
it like any other js library (jquery, etc) without using npm (node's package 
manager) for installation.  Handlebars, for example, has a single downloadable 
js file that is available on their website:

http://builds.handlebarsjs.com.s3.amazonaws.com/handlebars-v1.3.0.js

I'm coming in to the conversation without a lot of context, though, so I might 
be missing some reason why that won't work.

As for the incremental approach to using one of the larger frameworks, 
templates definitely do seem like an incremental improvement that won't really 
hinder adoption of the larger framework, since most of them are pluggable to 
work with most of the major template engines last I checked.  

Greg

On Jan 13, 2014, at 7:05 AM, Sean Dague s...@dague.net wrote:

 On 01/12/2014 09:56 PM, Michael Krotscheck wrote:
 If all you're looking for is a javascript-based in-browser templating
 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).
 
 Honestly, I've not done enough large scale js projects to know whether we'd 
 consider status.js to be big or not. I just know it's definitely getting too 
 big for += all the html together and doing document.writes.
 
 I guess the real question I had is is there an incremental path towards any 
 of the other frameworks? I can see how to incrementally bring in templates, 
 but again my personal lack of experience on these others means I don't know.
 
 Quick warning though, a lot of the javascript community out there uses
 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 right now).
 
 I'd ideally like to be able to function without node, mostly because it's 
 another development environment to have to manager. But I realize that's 
 pushing against the current at this point. So I agree, not a deal breaker.
 
   -Sean
 
 -- 
 Sean Dague
 Samsung Research America
 s...@dague.net / sean.da...@samsung.com
 http://dague.net
 
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [infra] javascript templating library choice for status pages

2014-01-13 Thread Monty Taylor

On 01/13/2014 05:05 AM, Sean Dague wrote:

On 01/12/2014 09:56 PM, Michael Krotscheck wrote:

If all you're looking for is a javascript-based in-browser templating
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).


Honestly, I've not done enough large scale js projects to know whether
we'd consider status.js to be big or not. I just know it's definitely
getting too big for += all the html together and doing document.writes.

I guess the real question I had is is there an incremental path towards
any of the other frameworks? I can see how to incrementally bring in
templates, but again my personal lack of experience on these others
means I don't know.


Quick warning though, a lot of the javascript community out there uses
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 right now).


I'd ideally like to be able to function without node, mostly because
it's another development environment to have to manager. But I realize
that's pushing against the current at this point. So I agree, not a deal
breaker.


Yeah - as a quick note though, just for clarity - this is only talking 
about node as a dev/build time depend - not a runtime depend.


I think, given that we seem to be doing more and more with javascript, 
that we might should just bite the bullet and learn the toolchain - I'm 
starting feel that doing all the js stuff without it is like the crazy 
python people who refuse to touch pip for some reason.



___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [infra] javascript templating library choice for status pages

2014-01-13 Thread Sergey Lukjanov
Just to make a context for this discussion, here are the two files that
where're speaking about:

https://git.openstack.org/cgit/openstack-infra/config/tree/modules/openstack_project/files/zuul/status.html
https://git.openstack.org/cgit/openstack-infra/config/tree/modules/openstack_project/files/zuul/status.js


On Mon, Jan 13, 2014 at 7:55 PM, Sergey Lukjanov slukja...@mirantis.comwrote:

 Currently, we already have a simple status page in zuul repo and status
 page in infra/config, probably, we should think about moving them to the
 separated repo and merge their functionality and in this case it'll be easy
 to use any actual js tools. Otherwise it'll be not really straightforward
 to have internal node.js project in mostly-puppet infra/config or python
 zuul.


 On Mon, Jan 13, 2014 at 7:21 PM, Monty Taylor mord...@inaugust.comwrote:

 On 01/13/2014 05:05 AM, Sean Dague wrote:

 On 01/12/2014 09:56 PM, Michael Krotscheck wrote:

 If all you're looking for is a javascript-based in-browser templating
 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).


 Honestly, I've not done enough large scale js projects to know whether
 we'd consider status.js to be big or not. I just know it's definitely
 getting too big for += all the html together and doing document.writes.

 I guess the real question I had is is there an incremental path towards
 any of the other frameworks? I can see how to incrementally bring in
 templates, but again my personal lack of experience on these others
 means I don't know.

  Quick warning though, a lot of the javascript community out there uses
 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 right now).


 I'd ideally like to be able to function without node, mostly because
 it's another development environment to have to manager. But I realize
 that's pushing against the current at this point. So I agree, not a deal
 breaker.


 Yeah - as a quick note though, just for clarity - this is only talking
 about node as a dev/build time depend - not a runtime depend.

 I think, given that we seem to be doing more and more with javascript,
 that we might should just bite the bullet and learn the toolchain - I'm
 starting feel that doing all the js stuff without it is like the crazy
 python people who refuse to touch pip for some reason.



 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




 --
 Sincerely yours,
 Sergey Lukjanov
 Savanna Technical Lead
 Mirantis Inc.




-- 
Sincerely yours,
Sergey Lukjanov
Savanna Technical Lead
Mirantis Inc.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [infra] javascript templating library choice for status pages

2014-01-13 Thread Russell Bryant
On 01/12/2014 09:56 PM, Michael Krotscheck wrote:
 If all you're looking for is a javascript-based in-browser templating
 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). 

For reference, you can find status.html / status.js here:

http://git.openstack.org/cgit/openstack-infra/config/tree/modules/openstack_project/files/zuul

-- 
Russell Bryant

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [infra] javascript templating library choice for status pages

2014-01-13 Thread Michael Krotscheck

On 01/13/2014 05:05 AM, Sean Dague wrote:
Honestly, I've not done enough large scale js projects to know whether 
we'd consider status.js to be big or not. I just know it's definitely 
getting too big for += all the html together and doing document.writes.

Yes indeed.
I guess the real question I had is is there an incremental path 
towards any of the other frameworks? I can see how to incrementally 
bring in templates, but again my personal lack of experience on these 
others means I don't know.
Short answer: Yes, and the incremental path will be more/less difficult 
depending on which application framework you want to move to. [/captain 
obvious]


Long answer: Pretty much all the template frameworks out there use 
{{mustache-style}} syntax. Some application frameworks use handlebars 
directly (ember), for some it's pluggable (knockout), others have their 
own framework with similar markup (angular). From what I saw of 
status.js, it's really not complicated enough to preclude a refactor to 
any of the above.


Michael
Also, what Monty said.

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [infra] javascript templating library choice for status pages

2014-01-13 Thread Sean Dague
On 01/13/2014 03:06 PM, Michael Krotscheck wrote:
 On 01/13/2014 05:05 AM, Sean Dague wrote:
 Honestly, I've not done enough large scale js projects to know whether
 we'd consider status.js to be big or not. I just know it's definitely
 getting too big for += all the html together and doing document.writes.
 Yes indeed.
 I guess the real question I had is is there an incremental path
 towards any of the other frameworks? I can see how to incrementally
 bring in templates, but again my personal lack of experience on these
 others means I don't know.
 Short answer: Yes, and the incremental path will be more/less difficult
 depending on which application framework you want to move to. [/captain
 obvious]
 
 Long answer: Pretty much all the template frameworks out there use
 {{mustache-style}} syntax. Some application frameworks use handlebars
 directly (ember), for some it's pluggable (knockout), others have their
 own framework with similar markup (angular). From what I saw of
 status.js, it's really not complicated enough to preclude a refactor to
 any of the above.
 
 Michael
 Also, what Monty said.

Well, as an expert in the area, particular recommendations would be
appreciated. I don't feel like we necessarily need one answer, but it
would be nice knock some of the options off the table.

-Sean

-- 
Sean Dague
http://dague.net



signature.asc
Description: OpenPGP digital signature
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [infra] javascript templating library choice for status pages

2014-01-13 Thread Michael Krotscheck

On 01/13/2014 01:12 PM, Sean Dague wrote:


Well, as an expert in the area, particular recommendations would be
appreciated. I don't feel like we necessarily need one answer, but it
would be nice knock some of the options off the table.


I'd say: Start with handlebars, unless you want to lay application 
groundwork, in which case you should try angular.js.


The former will be much, much faster, and have a shallower learning curve.

Michael



___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [infra] javascript templating library choice for status pages

2014-01-13 Thread Sergey Lukjanov
@Michael, very nice conclusion, absolutely agree.


On Tue, Jan 14, 2014 at 1:28 AM, Michael Krotscheck krotsch...@gmail.comwrote:

 On 01/13/2014 01:12 PM, Sean Dague wrote:


 Well, as an expert in the area, particular recommendations would be
 appreciated. I don't feel like we necessarily need one answer, but it
 would be nice knock some of the options off the table.


 I'd say: Start with handlebars, unless you want to lay application
 groundwork, in which case you should try angular.js.

 The former will be much, much faster, and have a shallower learning curve.

 Michael




 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




-- 
Sincerely yours,
Sergey Lukjanov
Savanna Technical Lead
Mirantis Inc.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [infra] javascript templating library choice for status pages

2014-01-12 Thread Monty Taylor

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).

I'd like to propose that we pick some javascript templating framework,
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?

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [infra] javascript templating library choice for status pages

2014-01-12 Thread Michael Krotscheck
If all you're looking for is a javascript-based in-browser templating
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).

Quick warning though, a lot of the javascript community out there uses
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
right now).

Michael



On Sun, Jan 12, 2014 at 5:21 PM, Monty Taylor mord...@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).

 I'd like to propose that we pick some javascript templating framework,
 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?

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


[openstack-dev] [infra] javascript templating library choice for status pages

2014-01-11 Thread Sean Dague
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).


I'd like to propose that we pick some javascript templating framework, 
and start incrementally porting bits over there over time.


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.


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.


-Sean

--
Sean Dague
Samsung Research America
s...@dague.net / sean.da...@samsung.com
http://dague.net

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev