Re: 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