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=49501711&iu=/4140/ostg.clktrk
_______________________________________________
Ledger-smb-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel
