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 <[email protected]>
On 30/07/2013, at 15.13, Brian Wolf <[email protected]> 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: [email protected]
> 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 <[email protected]>:
>>> 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=48808831&iu=/4140/ostg.clktrk
>>> _______________________________________________
>>> Ledger-smb-devel mailing list
>>> [email protected]
>>> 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=49501711&iu=/4140/ostg.clktrk
>> _______________________________________________
>> Ledger-smb-devel mailing list
>> [email protected]
>> 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=49501711&iu=/4140/ostg.clktrk_______________________________________________
> Ledger-smb-devel mailing list
> [email protected]
> 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=49501711&iu=/4140/ostg.clktrk
_______________________________________________
Ledger-smb-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel
