Re: [Ledger-smb-devel] Dojo tabs demo / using dojo in LSMB
I would like to have dojo added to current trunk. so we can 'probably try out a few different paradigms' By the time we ever reach production-stage , history-api might be fully implemented in all browsers http://www.w3.org/TR/html5/browsers.html#dom-history-replacestate 2013/7/29 John Locke m...@freelock.com: On 07/29/2013 07:36 AM, Brian Wolf wrote: Perhaps the common denominator of an area of the application. For example, in AR lots of functionality surrounds the customer; in AP, the vendor. There's probably much overlap in selecting an entity, viewing (perhaps a dashboard) basic information about it, and performing operations on that entity (eg, receiving a payment). It might be effective to have a one-page for a specific area of the application. On 07/29/2013 09:49 AM, Chris Travers wrote: One thing I would ask is that if we go with a multi-page design, what are the aspects of one-page design that we should be looking into incorporating? I think the natural place to start is with overview lists - detail views. In many cases, being able to see multiple transactions at once is very helpful. Having some panes for viewing/editing data, possibly some modal dialogs for data entry, and similar can be really helpful. I've got a pretty sizeable single-page app we use for much of our business, but it keeps the page paradigm -- pages get loaded into tabs which may be opened or closed. We've pretty much ignored the challenges Brian pointed out with state across refreshes -- as an internal app, we just take you back to a launch tab on refresh, you have to open up whatever you need. I did have a browser history manager partially implemented that would re-open tabs you had closed when you hit the back button -- but it wasn't high enough value for us to get fully working. In any case, converting the multiple pages into more usable standalone pages is clearly the next step. I think it's eventually worth experimenting with single-page apps, but not necessarily immediately, and make sure whatever UI we come up with ends up with a consensus before making it official -- probably try out a few different paradigms and see what we all like. Whatever we do, I think the app should be able to fall back to multiple pages, e.g. with js off, or with a lighter UI version for mobile, or whatever. Brian mentioned earlier a drop-down menu instead of a tree -- I was planning to just replace the current tree with a Dojo tree, which does use a cookie to remember previous state of expand/collapse. This seems like a really good place to start our experiments -- once we have the menu in a store, it's pretty trivial to switch between a menu bar and a tree widget. So is there any further objection to adding Dojo to the current trunk? The version I've put in my git repo does currently weigh in at 62M -- though currently it's adding around 140K to the page loads I've set up so far... Happy to see a few other developers on the list with Dojo experience! Cheers, John Locke http://www.freelock.com -- See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk ___ Ledger-smb-devel mailing list Ledger-smb-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel -- 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] Dojo tabs demo / using dojo in LSMB
John makes some good points. it's pretty trivial to switch between a menu bar and a tree widget. I've developed with Dojo and can validate John's statement. It also us the ability to provide multiple themes or layouts, letting each installation choose the one they want to use. Sounds like we're in agreement that substantial progress can be made in upgrading the user experience, and that a _javascript_ library like Dojo is a good place to start. One-page applications have the advantage of a more desktop-application-like experience, with less page refreshes (a visual encumbrance). However, my experience is that one-page apps can easily become heavy and are far more difficult to test (case set-up alone is tedious). One gigantic page may not be the answer, but several medium-size pages (one for each area of the app) may be a reasonable compromise. It facilitates testing and also independent development by various community members. 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 05:34 AM, herman vierendeels wrote: I would like to have dojo added to current trunk. so we can 'probably try out a few different paradigms' By the time we ever reach production-stage , history-api might be fully implemented in all browsers http://www.w3.org/TR/html5/browsers.html#dom-history-replacestate 2013/7/29 John Locke m...@freelock.com: On 07/29/2013 07:36 AM, Brian Wolf wrote: Perhaps the "common denominator" of an area of the application. For example, in AR lots of functionality surrounds the customer; in AP, the vendor. There's probably much overlap in selecting an entity, viewing (perhaps a dashboard) basic information about it, and performing operations on that entity (eg, receiving a payment). It might be effective to have a one-page for a specific area of the application. On 07/29/2013 09:49 AM, Chris Travers wrote: One thing I would ask is that if we go with a multi-page design, what are the aspects of one-page design that we should be looking into incorporating? I think the natural place to start is with overview lists - detail views. In many cases, being able to see multiple transactions at once is very helpful. Having some panes for viewing/editing data, possibly some modal dialogs for data entry, and similar can be really helpful. I've got a pretty sizeable single-page app we use for much of our business, but it keeps the page paradigm -- pages get loaded into tabs which may be opened or closed. We've pretty much ignored the challenges Brian pointed out with state across refreshes -- as an internal app, we just take you back to a launch tab on refresh, you have to open up whatever you need. I did have a browser history manager partially implemented that would re-open tabs you had closed when you hit the back button -- but it wasn't high enough value for us to get fully working. In any case, converting the multiple pages into more usable standalone pages is clearly the next step. I think it's eventually worth experimenting with single-page apps, but not necessarily immediately, and make sure whatever UI we come up with ends up with a consensus before making it official -- probably try out a few different paradigms and see what we all like. Whatever we do, I think the app should be able to fall back to multiple pages, e.g. with js off, or with a lighter UI version for mobile, or whatever. Brian mentioned earlier a drop-down menu instead of a tree -- I was planning to just replace the current tree with a Dojo tree, which does use a cookie to remember previous state of expand/collapse. This seems like a really good place to start our experiments -- once we have the menu in a store, it's pretty trivial to switch between a menu bar and a tree widget. So is there any further objection to adding Dojo to the current trunk? The version I've put in my git repo does currently weigh in at 62M -- though currently it's adding around 140K to the page loads I've set up so far... Happy to see a few other developers on the list with Dojo experience! Cheers, John Locke http://www.freelock.com -- See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate
Re: [Ledger-smb-devel] Dojo tabs demo / using dojo in LSMB
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 Ember, so that would be my choice, but no matter what JavaScript framework is picked, I am willing to help out build it. -- Kind regards, Mikkel Høgh mik...@hoegh.org On 30/07/2013, at 15.13, Brian Wolf brian.w...@activustech.com wrote: John makes some good points. it's pretty trivial to switch between a menu bar and a tree widget. I've developed with Dojo and can validate John's statement. It also us the ability to provide multiple themes or layouts, letting each installation choose the one they want to use. Sounds like we're in agreement that substantial progress can be made in upgrading the user experience, and that a JavaScript library like Dojo is a good place to start. One-page applications have the advantage of a more desktop-application-like experience, with less page refreshes (a visual encumbrance). However, my experience is that one-page apps can easily become heavy and are far more difficult to test (case set-up alone is tedious). One gigantic page may not be the answer, but several medium-size pages (one for each area of the app) may be a reasonable compromise. It facilitates testing and also independent development by various community members. Thanks. Brian activus_logo_small.png 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 05:34 AM, herman vierendeels wrote: I would like to have dojo added to current trunk. so we can 'probably try out a few different paradigms' By the time we ever reach production-stage , history-api might be fully implemented in all browsers http://www.w3.org/TR/html5/browsers.html#dom-history-replacestate 2013/7/29 John Locke m...@freelock.com: On 07/29/2013 07:36 AM, Brian Wolf wrote: Perhaps the common denominator of an area of the application. For example, in AR lots of functionality surrounds the customer; in AP, the vendor. There's probably much overlap in selecting an entity, viewing (perhaps a dashboard) basic information about it, and performing operations on that entity (eg, receiving a payment). It might be effective to have a one-page for a specific area of the application. On 07/29/2013 09:49 AM, Chris Travers wrote: One thing I would ask is that if we go with a multi-page design, what are the aspects of one-page design that we should be looking into incorporating? I think the natural place to start is with overview lists - detail views. In many cases, being able to see multiple transactions at once is very helpful. Having some panes for viewing/editing data, possibly some modal dialogs for data entry, and similar can be really helpful. I've got a pretty sizeable single-page app we use for much of our business, but it keeps the page paradigm -- pages get loaded into tabs which may be opened or closed. We've pretty much ignored the challenges Brian pointed out with state across refreshes -- as an internal app, we just take you back to a launch tab on refresh, you have to open up whatever you need. I did have a browser history manager partially implemented that would re-open tabs you had closed when you hit the back button -- but it wasn't high enough value for us to get fully working. In any case, converting the multiple pages into more usable standalone pages is clearly the next step. I think it's eventually worth experimenting with single-page apps, but not necessarily immediately, and make sure whatever UI we come up with ends up with a consensus before making it official -- probably try out a few different paradigms and see what we all like. Whatever we do, I think the app should be able to fall back to multiple pages, e.g. with js off, or with a lighter UI version for mobile, or whatever. Brian mentioned earlier a drop-down menu instead of a tree -- I was planning to just replace the current tree with a Dojo tree, which does use a cookie to remember previous state of expand/collapse. This seems like a really good place to start our experiments -- once we have the menu in a store, it's pretty trivial to switch between a menu bar and a tree widget. So is there any further objection to adding Dojo to the current trunk? The version I've put in my git repo does currently weigh in at 62M -- though currently it's adding around 140K to the page loads
Re: [Ledger-smb-devel] Dojo tabs demo / using dojo in LSMB
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 Ember, so that would be my choice, but no matter what JavaScript framework is picked, I am willing to help out build it. -- Kind regards, Mikkel Høgh mik...@hoegh.org mailto:mik...@hoegh.org On 30/07/2013, at 15.13, Brian Wolf brian.w...@activustech.com mailto:brian.w...@activustech.com wrote: John makes some good points. it's pretty trivial to switch between a menu bar and a tree widget. I've developed with Dojo and can validate John's statement. It also us the ability to provide multiple themes or layouts, letting each installation choose the one they want to use. Sounds like we're in agreement that substantial progress can be made in upgrading the user experience, and that a JavaScript library like Dojo is a good place to start. One-page applications have the advantage of a more desktop-application-like experience, with less page refreshes (a visual encumbrance). However, my experience is that one-page apps can
[Ledger-smb-devel] trunk css/global.css
i can't find css/global.css in trunk Any idea ? -- 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] Dojo tabs demo / using dojo in LSMB
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
[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
