On 07/31/2013 03:53 AM, Mikkel Høgh wrote:
On 31/07/2013, at 12.23, Chris Travers <[email protected]
<mailto:[email protected]>> wrote:
On 31/07/2013, at 01.19, John Locke <[email protected]
<mailto:[email protected]>> wrote:
>
> I think we should continue to maintain a plain-HTML front end
as a fallback, at least for the near future.
Realistically, how many users would actually need that? I don't
have the statistics on hand, but unless we have end-users on ~15
year old browsers, there should be no need for a non-JS fallback.
And keeping the fallback in place would make the development more
difficult, thus slowing us down.
If the data is well designed, I don't see why fallback would be
difficult at all. There are a number of reasons why a plain HTML
interface can be handy in some cases. I don't know, for example,
how well screen readers and other accessibility tools work with
js-rich pages (and if the design gets in the way of accessibility,
the javascrpt can always be turned off). I wouldn't suggest we lose
it unless it becomes a real burden to handle it. Realistically I
don't see much burden there, but I could be wrong. Any objection to
seeing what we can do to come up with a nice clean way to preserve this?
Well, it's not that I think we should go out of our way to break
backwards compatibility, but having two versions of every page (no-JS
and JS) that are both supposed to work effectively doubles our testing
load. Once I've made something and tested it in all browsers, I'd have
to disable JavaScript and test it all again.
I see the non-js version to be mainly a starting point. I do think
you're right, JS is becoming so ubiquitous and necessary in so many
places, it's probably fine to drop the requirement that it works without JS.
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...
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.
Accesibility is a separate concern, as I see it. Modern screen readers
do run JavaScript, and it's definitely possible to make JS-rich pages
accessible. WAI ARIA does a pretty good job at explaining to screen
readers what's going on on the page.
Yes, and most Dojo core widgets already specify a lot of this.
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.
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.
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.
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?
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
