Re: [Ledger-smb-devel] JS frameworks the future of the LSMB UI
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 On 31/07/2013, at 01.19, John Locke m...@freelock.com 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. 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 -- 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=49501711iu=/4140/ostg.clktrk ___ Ledger-smb-devel mailing list Ledger-smb-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel
Re: [Ledger-smb-devel] JS frameworks the future of the LSMB UI
On Wed, Jul 31, 2013 at 2:15 AM, Mikkel Høgh mik...@hoegh.org 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 m...@freelock.com 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=49501711iu=/4140/ostg.clktrk___ Ledger-smb-devel mailing list Ledger-smb-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel
Re: [Ledger-smb-devel] JS frameworks the future of the LSMB UI
On 31/07/2013, at 12.23, Chris Travers chris.trav...@gmail.com wrote: On Wed, Jul 31, 2013 at 2:15 AM, Mikkel Høgh mik...@hoegh.org 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 m...@freelock.com 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=49501711iu=/4140/ostg.clktrk___ Ledger-smb-devel mailing list Ledger-smb-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel
Re: [Ledger-smb-devel] JS frameworks the future of the LSMB UI
On 07/31/2013 01:59 PM, Erik Huelsmann wrote: Meanwhile there are a few other decisions to be made about how to make it easy to start adding Dojo widgets -- basically defining how to hook it up, so we can distribute this work. Ok. So, just to verify my understanding: this is still mainly to address the short term needs? Or are all of you on the same page that this is going to be *the* approach toward 1.5? I'm thinking that this approach would be for 1.4 and 1.5 -- that we introduce functionality in 1.4 and get full coverage in 1.5. And then re-open the broader discussion at that point on what works/doesn't work, and what we want to do that needs new architecture to get there. 2. Also in the top section, if there's a custom handler for this page, set it in dojo_load, e.g. dojo_load = lsmb/Contact/handler. This is assumed to be an AMD module that returns an object with an init() method/function, which will be called after the page is loaded and ready. This is optional. From our chat on IRC, I understand this is key, however, to making the ECA page work intuivitely - preventing the page from jumping to the initial Company tab on reload, etc.? Yes. Also, I think there's opportunity to combine some screens this way -- e.g. combine several search screens with results on the same page, and it facilitates substantially more as well... haven't necessarily thought about the menu just yet though. 4. I'm thinking I'll define some new element types in UI/libs/elements.html -- accountselector, date, currency, contact, part. These elements will be hooked up to user locale and currency preferences, as well as data sources back in LSMB. So once these exist, all that will be necessary to widget-ize an element will be to change the ?lsmb include input element_data = ... to ?lsmb include accountselector element_data = ... There will probably be some additional attributes for element data, such as foreign currency for currency, contact type, etc. Having additional elements seems like a logical next step. That way we make sure the selectors/... appear consistently formatted over all screens. (I think we have an issue there now regarding the way we present ECAs - sometimes by company name, sometimes using company and description concatenated...) Yes, I noticed this -- and I think one server-side improvement that would help might be to accept just the account id, ECA id, etc in form posts. Probably need to preserve the ability to accept the current long forms of these fields as well -- but if we can fix these so that we don't _have_ to combine the fields exactly the same way in form posts as they are done now, that will make it easier to come up with richer, more intuitive interfaces. Thoughts? Suggestions? To me this plan provides a very good next step into the era of a new UI. It also provides the tangible results people (or at least I) would like to see to understand the benefits of this kind of UI conversion. This discussion made me realise that I offered to start the discussion regarding the target UI and how to get there, but you, Brian, Herman and Mikkel are much more qualified to have that discussion than I am at this point. I think I should let you guys have it and draw up your plans! From there lets try to figure out how the plan fits best with the existing plans to rewrite the back-end. Great! Cheers, John Locke http://www.freelock.com -- 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=49501711iu=/4140/ostg.clktrk___ Ledger-smb-devel mailing list Ledger-smb-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel
[Ledger-smb-devel] JS frameworks the future of the LSMB UI
Hi all, Let me start out by expressing my happiness that we're having the discussion of which frameworks to use and where the LSMB UI should go. Personally I greatly value discussions like these because they interest in LedgerSMB and a general drive to improvement as well as a way for developers and community to reflect on what's considered improvement. Now regarding the thread itself, I'm seeing two topics being discussed which might actually need separate treatment. 1. Short-term improvement to the Customer/Vendor account screen and GL transaction entry screen required to a) make LedgerSMB's UI match that of the user's expectations (ie. make the Customer/Vendor screen show actual Tabs, not just make links work like they are) b) Fix the 1.4 customer/vendor screen - which didn't work at all beyond the Company and Account tabs until John's recent commit 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. On the first point (short-term interface developments, notably LedgerSMB 1.4 [and 1.3 backports?]) I see that Brian has developed custom extensions for LedgerSMB, using Scriptaculous, because that's what we are currently using. From John I understand that Dojo doesn't pollute the global namespace, so it could harmlessly co-exist with Scriptaculous. If that's the case, I can see there being a case for replacing the two or three places where we currently have JS code with Dojo based code. Brian's Scriptaculous code won't be affected and can be used in parallel. 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. Comments? Regarding the second subject, I'd like to start a separate thread to see who could and would want to contribute to what. From there, we can probably define the direction which can have the most developers behind it to achieve both the most satisfying result to the (then) active contributors *and* to get the most out of our community. Note that this is just my idea and that I think all community members (active contributors, lurkers and potential users alike) should have a say in this. Although I do think that the people actually writing the code (currently or new contributors) get the final votes. I'll write a separate mail to kick off technical discussion on the second subject (long term UI direction). What do you think? -- Bye, Erik. http://efficito.com -- Hosted accounting and ERP. Robust and Flexible. No vendor lock-in. -- 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=49501711iu=/4140/ostg.clktrk___ Ledger-smb-devel mailing list Ledger-smb-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel
Re: [Ledger-smb-devel] JS frameworks the future of the LSMB UI
Oh, ok, I can't help but comment on the second point too: 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. I'd like to see some improvements in the JSON interface, both for integration with entirely outside applications and to simplify the work that needs to be done in the browser to make richer interfaces (assuming we're using things like Dojo stores to consume and update that data). The spec we developed that's described in rest_server.pl should work -- however the actual interface doesn't currently work with the one class that's defined (LedgerSMB::REST_Class::Contact), and I think there might be some easier ways to get broad coverage here -- perhaps hooking into the ORM model to return straight JSON from virtually any stored function? Or providing some REST methods on the LedgerSMB data object that everything else inherits... But the biggest thing to me is not slowing down the release. The reason I haven't committed my changes (yet) to trunk is that I want to see 1.4 out and working, soon, and I don't want the UI discussions to slow that down. There's enough improvement going on that I don't want to distract you or Chris too much by adding a ton more that needs to be done before we declare a stable release. 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. Cheers, John Locke http://www.freelock.com -- 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=49501711iu=/4140/ostg.clktrk ___ Ledger-smb-devel mailing list Ledger-smb-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel
