Re: Dojo tabs demo / using dojo in LSMB

[herman vierendeels <..hidden..>]

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 <..hidden..>:
> 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
> ..hidden..
> https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel