>
> Though I do think about things like a text-only version, e.g. lynx or
> links. I don't think we need to support js disabled for modern browsers,
> but at least at this point it seems wise to preserve the current html form
> posting and data retrieval without requiring JS, and then enhance from
> there. At least for the time being...
>
>
This is my idea as well: for 1.4, there are a few screens which have low to
extremely low hanging fruit; sometimes replacing existing JS (which doesn't
work particularly well) with tried-and-tested JS libraries.
> Also, some things will be harder to implement, if we have to keep things
> _the same_ rather than just making sure they work and are accessible.
> Suppose I wanted to replace our account autocompleter with something based
> on http://ivaynberg.github.io/select2/ – then I would have to hack
> Select2 to make its output match the current one (2700--Account name here),
> rather than just making sure that the form still worked as its supposed to
> (ie. by setting the value of the actual field to just the account number).
>
>
> I don't see the need to keep things the same in the JS version as the
> non-JS version. I just think we should keep it *possible* to use non-js,
> not necessarily *usable*.
>
> With dojo, it's pretty easy to change the output to match the current Form
> API in use by the text version, regardless of the widget in use -- we might
> need to extend it to rewrite the value field, but that's not hard.
>
> As I mentioned earlier, I would prefer to enhance the interfaces further
> and post/put JSON blobs to the web service, rather than using a regular
> form post with the current values, but that will take more work server
> side, and again, I personally don't want this to hold up the release of 1.4.
>
>
Same here. If any efforts on part of the UI/client side come from other
developers than those that want to rewrite the server side logic, we can
achieve more targets in the same timeframe. To me that's a pure win. From
what you, Brian, Mikkel and Herman said, I think that's what's happening
here: you'd rather hack on creating new pages with a better UI while Chris
(and I) would rather fix the server side part. Those are IMO nicely
complementing efforts.
> Ok, I've got a full day today, so I won't be able to get this in now. But
> I can probably commit my Dojo work to trunk tomorrow or the next day,
> unless I hear a "no" before then.
>
> 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?
Here's how I'm thinking of setting this up/what you would need to do in
> each template:
>
> 1. In the top section, in the dojo_include array, list any widgets in use
> on the page to be loaded and instantiated by the parser. E.g.
> 'dijit/form/DateTextBox',
> 'dijit/form/CurrencyTextBox','lsmb/accounts/AccountSelector'
>
> 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.?
> 3. If either dojo_include or dojo_load is included in a template, dojo.js
> will get added to the page, the modules require'd, and the dojo parser
> called to parse the page. If dojo_load is specified, the init function will
> get called after the parser -- but any modules it require's will get loaded
> before the parser runs.
>
>
>
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...)
> 5. What I already hooked up adds a dojo_type attribute to any of the form
> elements, making it possible to make any form element a dojo widget of the
> specified class. I can also add a dojo_param attribute to support anything
> that would go into a data-dojo-props string on the HTML element.
>
>
> #4 and #5 are two different ways to do pretty much the same thing -- #5 is
> useful for prototyping/experimenting, but #4 will make it much easier to
> reuse elements across screens.
>
> 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.
--
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=49501711&iu=/4140/ostg.clktrk
_______________________________________________
Ledger-smb-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel
