[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: JS frameworks & the future of the LSMB UI
- Subject: Re: JS frameworks & the future of the LSMB UI
- From: John Locke <..hidden..>
- Date: Tue, 30 Jul 2013 15:54:42 -0700
One quick comment to make on this... Otherwise I think I've already
expressed my opinion ;-)
On 07/30/2013 03:14 PM, Erik Huelsmann wrote:
As far as "LedgerSMB coming with Scriptaculous" is concerned, I'll add
a section to INSTALL telling packagers to depend on the packages
readily provided by their distribution to provide
Scriptaculous/Dojo/jQuery/etc: these packages are updated for bug- and
security fixes, something we can't all keep track of. Which means to
me: we should probably separate the scriptaculous dependency out into
its own TAR file which can be untarred over a tar which holds the base
LedgerSMB code, if the user wants it. This makes the dependency more
apparent and prevents packagers from accidentally packaging an
additional JS framework.
I don't see how it's practical to do this. JS frameworks need to be
served up by a server, and it makes sense to have it served up by the
same server that's handling the underlying web app.
There is decent CDN support for Dojo, but not for a few of the
extensions I can see adding (primarily Dgrid at this point), and having
a specific CDN hard-coded into an open source app seems like bad
practice to me.
All in all, most webapps that use JS libraries go ahead and bundle them
in, because otherwise configuring them gets messy and challenging. It's
just a lot easier to include them.
Regarding the bug and security fixes, I can think of one major Dojo
security update that might have been a concern enough to warrant an
upgrade: a PHP script that was part of the supporting util or test code
that could be exploited. Otherwise we're talking about code running in a
browser, not code on a server. While this might (with a lot of effort)
open up some new vectors for CSRF attacks from other users of the same
LedgerSMB instance, it's really hard to see any kind of attack vector
that these JS libraries open up.
The only server-executable code in the entire Dojo tree (outside of what
you might run in Node.js) are things we could probably omit: code for
providing server-side support for demos and tests, and code to build js
and css layers to optimize loading.
The build functionality is definitely useful to address Brian's most
recent comment, about needing to load 10 or more AMD modules (which is
already the case on the two screens I started with).
In most of my Dojo projects, what I do is put the Dojo tree in a git
submodule (similar to an svn external), and then make a build that gets
added to the actual application's repo. With that model, we could strip
the build of any/all server-executable code, and only ship built