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.
>
>
> 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?
>
>
> > So if you're amenable, I'd suggest let's go ahead with introducing Dojo
> as an included library, and let me, Brian, Herman, Mikkel, and anyone else
> who's comfortable plugging away at the JS side of things improve one
> screen/module at a time, with a goal of more complete coverage in 1.5, and
> then perhaps look at new UI paradigms for the release after that.
>
> Sounds good to me.
>
> >
> > Cheers,
> > John Locke
> > http://www.freelock.com
>
>
--
Best Wishes,
Chris Travers
Efficito: Hosted Accounting and ERP. Robust and Flexible. No vendor
lock-in.
http://www.efficito.com/learn_more.shtml
------------------------------------------------------------------------------
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
