+1x4 below :)
On 02/12/2013 11:10 PM, Matt Franklin wrote:
On Tue, Feb 12, 2013 at 4:54 PM, Chris Geer <[email protected]> wrote:
On Tue, Feb 12, 2013 at 12:23 PM, Noe-Payne, Erin A. <[email protected]>wrote:
On 2/12/13 1:51 PM, "Chris Geer" <[email protected]> wrote:
On Tue, Feb 12, 2013 at 10:31 AM, Matt Franklin
<[email protected]>wrote:
On Mon, Feb 11, 2013 at 11:37 AM, Noe-Payne, Erin A. <[email protected]>
wrote:
Hi All,
I wanted to propose adding underscore.js (http://underscorejs.org/)
as
a dependency for rave javascript.
This is a small (4kb) utility belt library for javascript that adds a
number of convenience functions without modifying object prototypes. The
main advantages would be 1) more succinct code 2) better performance by
taking advantage of ecmascript 5 functions like Object.each, .map,
.keys,
etc when available.
Are there any objections to adding underscore as a dependency and
relying on it for new features going forward / refactoring older js to
take
advantage of it?
+1
It looks like in RAVE-886 [1] we are adding handlebars support and now
underscorejs. Are there any frameworks that provide all the capabilities
we
think we might need like EmberJS or AngularJS? Do we have a master list of
all the javascript libraries we use already?
Chris, that is correct. I am looking to do a refactor of rave's js to
isolate dependencies better - these tickets are the first steps. I do not
see rave as a good candidate for ember, angular, backbone or another mv*
framework because it relies on shindig for a lot of its functionality and
the integration would be messy. Also these frameworks look to handle logic
in their controllers, which would tightly couple rave's core js with those
libraries and basically force an implementer into using them.
Thanks Erin, that makes sense. I have no objections to underscorejs
My end goal would be for rave's core js to have a dependency on
underscore.js only - taking advantage of its utility and ecmascript 5
polyfills for better readability and performance in the core.
Any dependency on dom libraries (jquery, handlebars) would be refactored
into the rave.ui namespace and file(s) so that an implementer can easily
extend or overlay their ui work and even drop those dependencies without
affecting rave-core.
Any thoughts about migrating rave.ui into it's own file? I think it would
make things cleaner.
+1
+1
I'll throw this idea out there for consideration (or shooting down). Is
there any possibility we can migrate the backend to be more web services
and less UI and move more of the UI into javascript/HTML5? If we had web
services that returned the relevant widget/region information, couldn't
we construct the page client side? That would also give us a lot more
flexibility in making dynamic changes.
+1
I completely agree. The current state of heavyweight
controllers/server templating needs to be moved away from to make it
easier to integrate rave.
+1
[1] https://issues.apache.org/jira/browse/RAVE-886
If it is the only dependency of rave.js and it provides a lot of
convenience functions that we would have to write, I am +0
Erin
