Re: [Ledger-smb-devel] Dojo tabs demo / using dojo in LSMB
other advantages of dojo -national language support (nls) -dojo's building system to minify modules and resources into a few files 2013/7/30 Brian Wolf brian.w...@activustech.com John's assessment is insightful. It's hard to know exactly why some products really take off while others have difficulty in lift-off. One comment about Dojo's new AMD paradigm (I think since version 1.7): the upside is a set of light(er) weight modules that you declare individually; the reverse is true too: often you have to load 10 or more modules. Otherwise, Dojo has a lot of functionality, and certainly datagrid and AJAX-based stores make it terrific for a data-centric app like LedgerSMB. Thanks. Brian Brian Wolf Phone: 410.367.2958 Email: br...@activustech.com Try out Activus Secure Payments™, our recurring payments application. Demo at http://demo.activustech.com On 07/30/2013 02:48 PM, John Locke wrote: Hi, I just did a quick review of what Ember.js is, and what its strengths and weaknesses are, compared to Dojo. This assessment is definitely not coming from experience with Ember, but with a lot of Dojo experience, so I'm sure it's biased. But here's what I noticed: Ember strengths: - Routes, more opinionated management of controllers within the page - Single DOM event listeners for entire application - Views automatically delay re-rendering, possibly more streamlined DOM updates with less iterations Ember weaknesses: - Ember.data stores seem to be far less developed than dojo's stores and data objects, and still marked with an unstable warning - Not seeing any declarative way of adding widgets to existing code -- means there's a lot more effort involved to get results As I look at this, I still wonder why Dojo is shunned in so many circles. It is really a pioneer in this area, providing a huge amount of the functionality that's in Ember, and it provided it 6, 7 years ago, ages before this new generation of JS frameworks. And it still leads in areas like data management, defining APIs for paging, sorting, and searching that I don't see mentioned anywhere in Ember.data, things that will be especially useful for showing the transactions in an account (if I go to a chart of accounts report now on certain accounts and don't put in a filter for date, I need to wait for close to a minute for it to return a few thousand transactions!). And I really like the new encapsulated AMD (Asynchronous Module Definition) pattern, find it really effective for preventing conflicts with other libraries, keeping the memory footprint lightweight, and swapping out event libraries to target touch events and mouse events differently for different devices. In particular, Dojo to me seems like a no-brainer because we can enrich the user experience with much nicer widgets, with some very small changes to the UI templates -- the declarative style of markup that Dojo provides makes this much simpler to get a whole bunch of easy wins. And most of the things I see noted in the Understanding Ember pages ( http://emberjs.com/guides/understanding-ember/the-view-layer/) have been in Dojo for years: * Templates merged in the browser * Automatic updates of content in templates, browser side (you do need to build a widget for this, but it's a very well-defined process) * Event listeners (if anything, this sounds more complete in dojo -- with dojo/aspect, you can observe any function call, not just DOM events. Personally I use dojo/topic a lot, to create channels for pub/sub) * Class definitions, widget lifecycles So it strikes me that these are the arguments for going with Dojo: * Can enhance the existing UI today, without needing to start from the ground up and rebuild the entire UI * Can greatly improve a page/module at a time, without needing to build a single-page app * Can still build towards a single-page app, perhaps with a bit more planning necessary around DOM event delegation and re-rendering triggers * Widgets and systems already written and easy to deploy today, for handling thousands of rows of data, doing effective browser-side searches, sorts, and filtering with co-operation with the server side code * Decent charting library that can leverage the same data models we use for raw data display Cheers, John Locke http://www.freelock.com On 07/30/2013 08:47 AM, Mikkel Høgh wrote: Hi there, I've not been very involved with LedgerSMB development so far, since I'm not really a Perl guy, but I have in fact been considering starting a project to build a modern JavaScript app as a replacement for the current LSMB interface. I think the two best framework choices for this at the moment are Angular or Ember.js. I'm really impressed about what the Discourse guys have managed to accomplish with Ember.js (the forum at http://try.discourse.org/ is in fact a single page app, but it does certainly not feel like it). I have built a few apps with
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
