On 31/07/2013, at 12.23, Chris Travers <[email protected]> wrote:
> On Wed, Jul 31, 2013 at 2:15 AM, Mikkel Høgh <[email protected]> wrote:
> A few notes of my own.
>
> > 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.
>
> Also, loading external JavaScript code is a security issue, and given that
> we're dealing with people's financial data here, I don't think that's
> acceptable.
>
> To quote Douglas Crockford “IT IS EXTREMELY UNWISE TO LOAD CODE FROM SERVERS
> YOU DO NOT CONTROL.” (his caps, not mine):
> https://github.com/douglascrockford/JSON-js/blob/master/json2.js#L15
>
> +1 on this. Also I would suggest that what we distribute should come with
> code distributed with the app by default only. This could be configured,
> if we need it to be, but this provides some additional defence.
Also, distributing the libraries ourselves means that our users won't have to
worry about getting the right versions of x, y and z. We can upgrade users to
new versions of modules on our own schedule.
>
>
> On 31/07/2013, at 01.19, John Locke <[email protected]> wrote:
> >
> > On 07/30/2013 03:14 PM, Erik Huelsmann wrote:
> >>
> >> 2. Longer term general direction for the development of the LedgerSMB UI
> >> This point probably requires separate discussion, because the direction
> >> taken to develop a UI inherently affects the efforts required for the
> >> "back end". I.e. whether we from here on *only* develop services on the
> >> back end, with separate front-end developments, or that we develop along
> >> the current route which supports to build a rich front-end "eventually".
> >>
> > I think we should continue to maintain a plain-HTML front end as a
> > fallback, at least for the near future.
>
> Realistically, how many users would actually need that? I don't have the
> statistics on hand, but unless we have end-users on ~15 year old browsers,
> there should be no need for a non-JS fallback. And keeping the fallback in
> place would make the development more difficult, thus slowing us down.
>
> If the data is well designed, I don't see why fallback would be difficult at
> all. There are a number of reasons why a plain HTML interface can be handy
> in some cases. I don't know, for example, how well screen readers and other
> accessibility tools work with js-rich pages (and if the design gets in the
> way of accessibility, the javascrpt can always be turned off). I wouldn't
> suggest we lose it unless it becomes a real burden to handle it.
> Realistically I don't see much burden there, but I could be wrong. Any
> objection to seeing what we can do to come up with a nice clean way to
> preserve this?
Well, it's not that I think we should go out of our way to break backwards
compatibility, but having two versions of every page (no-JS and JS) that are
both supposed to work effectively doubles our testing load. Once I've made
something and tested it in all browsers, I'd have to disable JavaScript and
test it all again.
Also, some things will be harder to implement, if we have to keep things _the
same_ rather than just making sure they work and are accessible.
Suppose I wanted to replace our account autocompleter with something based on
http://ivaynberg.github.io/select2/ – then I would have to hack Select2 to make
its output match the current one (2700--Account name here), rather than just
making sure that the form still worked as its supposed to (ie. by setting the
value of the actual field to just the account number).
Accesibility is a separate concern, as I see it. Modern screen readers do run
JavaScript, and it's definitely possible to make JS-rich pages accessible. WAI
ARIA does a pretty good job at explaining to screen readers what's going on on
the page.
------------------------------------------------------------------------------
Get your SQL database under version control now!
Version control is standard for application code, but databases havent
caught up. So what steps can you take to put your SQL databases under
version control? Why should you start doing it? Read more to find out.
http://pubads.g.doubleclick.net/gampad/clk?id=49501711&iu=/4140/ostg.clktrk
_______________________________________________
Ledger-smb-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel
