Can you for a string type to default to numeric keypad

I have input which is basically a string but for the most parts it is
typically numeric. Is it possible to have a string type but force the
displayed keypad to be launched as the numeric rather that alpha?
-steve-

the keypads we display map to data types. is is not possible to
override this in the xform, but it is pretty easy to do it in the
collect source.

··· On Fri, Feb 4, 2011 at 14:57, Steve Roberts wrote: > I have input which is basically a string but for the most parts it is > typically numeric. Is it possible to have a string type but force the > displayed keypad to be launched as the numeric rather that alpha? > -steve- > > -- > Post: opendatakit@googlegroups.com > Unsubscribe: opendatakit+unsubscribe@googlegroups.com > Options: http://groups.google.com/group/opendatakit?hl=en >

Do you mean come up with a custom data type that Collect recognizes so
switches the keypad? My actual pattern can be "[a-z0-9][0-9][0-9]". So
could it be smart enough that after the first digit is pressed that it then
switches to the numeric keypad. I can see where a special data type could
be used to choose a default but I'm probably pressing my luck thinking it
would be easy to have it watch a regex pattern develop and notice that Hey
the next character can only be a number so I'll be nice and switch on the
numeric keypad.

··· On Fri, Feb 4, 2011 at 3:26 PM, Yaw Anokwa wrote:

the keypads we display map to data types. is is not possible to
override this in the xform, but it is pretty easy to do it in the
collect source.

On Fri, Feb 4, 2011 at 14:57, Steve Roberts steve@roberts.org wrote:

I have input which is basically a string but for the most parts it is
typically numeric. Is it possible to have a string type but force the
displayed keypad to be launched as the numeric rather that alpha?
-steve-

--
Post: opendatakit@googlegroups.com
Unsubscribe: opendatakit+unsubscribe@googlegroups.comopendatakit%2Bunsubscribe@googlegroups.com
Options: http://groups.google.com/group/opendatakit?hl=en

--
Post: opendatakit@googlegroups.com
Unsubscribe: opendatakit+unsubscribe@googlegroups.comopendatakit%2Bunsubscribe@googlegroups.com
Options: http://groups.google.com/group/opendatakit?hl=en

i confronted this problem when making touchforms -- a web interface for
xforms meant to be used on touchscreen kiosks, powered by javarosa.

the solution i came up with is to keep the data as a string, but provide
css-like meta-data about the question that the rendering engine can act on.
in this case, that the 'domain' of the data is numeric, even though the
datatype itself is 'string'. my view shows a numeric keypad in this case
instead of the full keyboard.

we have no standard for annotating questions with this meta-data, so for the
time being i hacked it into the question's appearance attribute. this is
clearly a hack, but i think the overall idea of providing meta-data has
promise. i think we should come up with a vocabulary of custom attributes to
include in a , or make our own css-like dialect.

··· On Fri, Feb 4, 2011 at 6:36 PM, Steve Roberts wrote:

Do you mean come up with a custom data type that Collect recognizes so
switches the keypad? My actual pattern can be "[a-z0-9][0-9][0-9]". So
could it be smart enough that after the first digit is pressed that it then
switches to the numeric keypad. I can see where a special data type could
be used to choose a default but I'm probably pressing my luck thinking it
would be easy to have it watch a regex pattern develop and notice that Hey
the next character can only be a number so I'll be nice and switch on the
numeric keypad.

On Fri, Feb 4, 2011 at 3:26 PM, Yaw Anokwa yanokwa@gmail.com wrote:

the keypads we display map to data types. is is not possible to
override this in the xform, but it is pretty easy to do it in the
collect source.

On Fri, Feb 4, 2011 at 14:57, Steve Roberts steve@roberts.org wrote:

I have input which is basically a string but for the most parts it is
typically numeric. Is it possible to have a string type but force the
displayed keypad to be launched as the numeric rather that alpha?
-steve-

--
Post: opendatakit@googlegroups.com
Unsubscribe: opendatakit+unsubscribe@googlegroups.comopendatakit%2Bunsubscribe@googlegroups.com
Options: http://groups.google.com/group/opendatakit?hl=en

--
Post: opendatakit@googlegroups.com
Unsubscribe: opendatakit+unsubscribe@googlegroups.comopendatakit%2Bunsubscribe@googlegroups.com
Options: http://groups.google.com/group/opendatakit?hl=en

--
Post: opendatakit@googlegroups.com
Unsubscribe: opendatakit+unsubscribe@googlegroups.comopendatakit%2Bunsubscribe@googlegroups.com
Options: http://groups.google.com/group/opendatakit?hl=en

Is the hack something you can share?

··· On Fri, Feb 4, 2011 at 4:36 PM, Drew Roos wrote:

i confronted this problem when making touchforms -- a web interface for
xforms meant to be used on touchscreen kiosks, powered by javarosa.

the solution i came up with is to keep the data as a string, but provide
css-like meta-data about the question that the rendering engine can act on.
in this case, that the 'domain' of the data is numeric, even though the
datatype itself is 'string'. my view shows a numeric keypad in this case
instead of the full keyboard.

we have no standard for annotating questions with this meta-data, so for
the time being i hacked it into the question's appearance attribute. this is
clearly a hack, but i think the overall idea of providing meta-data has
promise. i think we should come up with a vocabulary of custom attributes to
include in a , or make our own css-like dialect.

On Fri, Feb 4, 2011 at 6:36 PM, Steve Roberts steve@roberts.org wrote:

Do you mean come up with a custom data type that Collect recognizes so
switches the keypad? My actual pattern can be "[a-z0-9][0-9][0-9]". So
could it be smart enough that after the first digit is pressed that it then
switches to the numeric keypad. I can see where a special data type could
be used to choose a default but I'm probably pressing my luck thinking it
would be easy to have it watch a regex pattern develop and notice that Hey
the next character can only be a number so I'll be nice and switch on the
numeric keypad.

On Fri, Feb 4, 2011 at 3:26 PM, Yaw Anokwa yanokwa@gmail.com wrote:

the keypads we display map to data types. is is not possible to
override this in the xform, but it is pretty easy to do it in the
collect source.

On Fri, Feb 4, 2011 at 14:57, Steve Roberts steve@roberts.org wrote:

I have input which is basically a string but for the most parts it is
typically numeric. Is it possible to have a string type but force the
displayed keypad to be launched as the numeric rather that alpha?
-steve-

--
Post: opendatakit@googlegroups.com
Unsubscribe: opendatakit+unsubscribe@googlegroups.com
Options: http://groups.google.com/group/opendatakit?hl=en

--
Post: opendatakit@googlegroups.com
Unsubscribe: opendatakit+unsubscribe@googlegroups.com
Options: http://groups.google.com/group/opendatakit?hl=en

--
Post: opendatakit@googlegroups.com
Unsubscribe: opendatakit+unsubscribe@googlegroups.com
Options: http://groups.google.com/group/opendatakit?hl=en

--
Post: opendatakit@googlegroups.com
Unsubscribe: opendatakit+unsubscribe@googlegroups.com
Options: http://groups.google.com/group/opendatakit?hl=en

I ran into almost exactly the same problem developing ODK Voice - it needed
additional specifications for how to render the form, but there was no
standard way to add application-specific attributes to an XForm, so I ended
up with a really ugly hack.

What is the JavaRosa stance on a sort of 'plugin' spec as part of JavaRosa
XForms that would allow developers to add their own data without breaking
other applications? E.g.

whatever stuff I want can go in here and it won't
break other applications

I'm not sure whether this would be attached to the instance data or
controls. Does something like this exist, or are there reasons not to have
such functionality? It's not part of XForms, but in the end it would
probably encourage conformance, because everyone who needed their own
attributes wouldn't have to break the spec.

Just my two cents,
Adam

··· On Fri, Feb 4, 2011 at 7:36 PM, Drew Roos wrote:

i confronted this problem when making touchforms -- a web interface for
xforms meant to be used on touchscreen kiosks, powered by javarosa.

the solution i came up with is to keep the data as a string, but provide
css-like meta-data about the question that the rendering engine can act on.
in this case, that the 'domain' of the data is numeric, even though the
datatype itself is 'string'. my view shows a numeric keypad in this case
instead of the full keyboard.

we have no standard for annotating questions with this meta-data, so for
the time being i hacked it into the question's appearance attribute. this is
clearly a hack, but i think the overall idea of providing meta-data has
promise. i think we should come up with a vocabulary of custom attributes to
include in a , or make our own css-like dialect.

On Fri, Feb 4, 2011 at 6:36 PM, Steve Roberts steve@roberts.org wrote:

Do you mean come up with a custom data type that Collect recognizes so
switches the keypad? My actual pattern can be "[a-z0-9][0-9][0-9]". So
could it be smart enough that after the first digit is pressed that it then
switches to the numeric keypad. I can see where a special data type could
be used to choose a default but I'm probably pressing my luck thinking it
would be easy to have it watch a regex pattern develop and notice that Hey
the next character can only be a number so I'll be nice and switch on the
numeric keypad.

On Fri, Feb 4, 2011 at 3:26 PM, Yaw Anokwa yanokwa@gmail.com wrote:

the keypads we display map to data types. is is not possible to
override this in the xform, but it is pretty easy to do it in the
collect source.

On Fri, Feb 4, 2011 at 14:57, Steve Roberts steve@roberts.org wrote:

I have input which is basically a string but for the most parts it is
typically numeric. Is it possible to have a string type but force the
displayed keypad to be launched as the numeric rather that alpha?
-steve-

--
Post: opendatakit@googlegroups.com
Unsubscribe: opendatakit+unsubscribe@googlegroups.comopendatakit%2Bunsubscribe@googlegroups.com
Options: http://groups.google.com/group/opendatakit?hl=en

--
Post: opendatakit@googlegroups.com
Unsubscribe: opendatakit+unsubscribe@googlegroups.comopendatakit%2Bunsubscribe@googlegroups.com
Options: http://groups.google.com/group/opendatakit?hl=en

--
Post: opendatakit@googlegroups.com
Unsubscribe: opendatakit+unsubscribe@googlegroups.comopendatakit%2Bunsubscribe@googlegroups.com
Options: http://groups.google.com/group/opendatakit?hl=en

--
Post: opendatakit@googlegroups.com
Unsubscribe: opendatakit+unsubscribe@googlegroups.comopendatakit%2Bunsubscribe@googlegroups.com
Options: http://groups.google.com/group/opendatakit?hl=en

If you really want to see my hack for adding rendering attributes, you can
look at the ODK Voice code, but it's a terrible hack and I'm not very proud
of it, so I'd rather not post it on this list as some sort of example code.
As a member of the JavaRosa team, Drew might be able to tell you the least
offensive place to put your attributes.

··· On Fri, Feb 4, 2011 at 11:07 PM, Steve Roberts wrote:

Is the hack something you can share?

On Fri, Feb 4, 2011 at 4:36 PM, Drew Roos droos@dimagi.com wrote:

i confronted this problem when making touchforms -- a web interface for
xforms meant to be used on touchscreen kiosks, powered by javarosa.

the solution i came up with is to keep the data as a string, but provide
css-like meta-data about the question that the rendering engine can act on.
in this case, that the 'domain' of the data is numeric, even though the
datatype itself is 'string'. my view shows a numeric keypad in this case
instead of the full keyboard.

we have no standard for annotating questions with this meta-data, so for
the time being i hacked it into the question's appearance attribute. this is
clearly a hack, but i think the overall idea of providing meta-data has
promise. i think we should come up with a vocabulary of custom attributes to
include in a , or make our own css-like dialect.

On Fri, Feb 4, 2011 at 6:36 PM, Steve Roberts steve@roberts.org wrote:

Do you mean come up with a custom data type that Collect recognizes so
switches the keypad? My actual pattern can be "[a-z0-9][0-9][0-9]". So
could it be smart enough that after the first digit is pressed that it then
switches to the numeric keypad. I can see where a special data type could
be used to choose a default but I'm probably pressing my luck thinking it
would be easy to have it watch a regex pattern develop and notice that Hey
the next character can only be a number so I'll be nice and switch on the
numeric keypad.

On Fri, Feb 4, 2011 at 3:26 PM, Yaw Anokwa yanokwa@gmail.com wrote:

the keypads we display map to data types. is is not possible to
override this in the xform, but it is pretty easy to do it in the
collect source.

On Fri, Feb 4, 2011 at 14:57, Steve Roberts steve@roberts.org wrote:

I have input which is basically a string but for the most parts it is
typically numeric. Is it possible to have a string type but force the
displayed keypad to be launched as the numeric rather that alpha?
-steve-

--
Post: opendatakit@googlegroups.com
Unsubscribe: opendatakit+unsubscribe@googlegroups.comopendatakit%2Bunsubscribe@googlegroups.com
Options: http://groups.google.com/group/opendatakit?hl=en

--
Post: opendatakit@googlegroups.com
Unsubscribe: opendatakit+unsubscribe@googlegroups.comopendatakit%2Bunsubscribe@googlegroups.com
Options: http://groups.google.com/group/opendatakit?hl=en

--
Post: opendatakit@googlegroups.com
Unsubscribe: opendatakit+unsubscribe@googlegroups.comopendatakit%2Bunsubscribe@googlegroups.com
Options: http://groups.google.com/group/opendatakit?hl=en

--
Post: opendatakit@googlegroups.com
Unsubscribe: opendatakit+unsubscribe@googlegroups.comopendatakit%2Bunsubscribe@googlegroups.com
Options: http://groups.google.com/group/opendatakit?hl=en

--
Post: opendatakit@googlegroups.com
Unsubscribe: opendatakit+unsubscribe@googlegroups.comopendatakit%2Bunsubscribe@googlegroups.com
Options: http://groups.google.com/group/opendatakit?hl=en

we've been using the appearance tag in 1.1.6 to do question grouping
and will be doing more with different kinds of select widgets. i'd
like us to converge on a rough standard before this stuff gets out of
our control and starts breaking compatibility. i know clayton was
concerned about folks using appearance as a way to bypass form logic,
so we were hoping for some whitelist of keyboards that would get
passed up through the core.

drew, can you write up what you have and the community can iterate
through some of the keywords we might need? i figure with feedback
from adam and mitch, we should be able to get a rough xforms-friendly
spec in place.

··· On Sat, Feb 5, 2011 at 00:55, Adam Lerer wrote: > If you really want to see my hack for adding rendering attributes, you can > look at the ODK Voice code, but it's a terrible hack and I'm not very proud > of it, so I'd rather not post it on this list as some sort of example code. > As a member of the JavaRosa team, Drew might be able to tell you the least > offensive place to put your attributes. > > On Fri, Feb 4, 2011 at 11:07 PM, Steve Roberts wrote: >> >> Is the hack something you can share? >> >> On Fri, Feb 4, 2011 at 4:36 PM, Drew Roos wrote: >>> >>> i confronted this problem when making touchforms -- a web interface for >>> xforms meant to be used on touchscreen kiosks, powered by javarosa. >>> >>> the solution i came up with is to keep the data as a string, but provide >>> css-like meta-data about the question that the rendering engine can act on. >>> in this case, that the 'domain' of the data is numeric, even though the >>> datatype itself is 'string'. my view shows a numeric keypad in this case >>> instead of the full keyboard. >>> >>> we have no standard for annotating questions with this meta-data, so for >>> the time being i hacked it into the question's appearance attribute. this is >>> clearly a hack, but i think the overall idea of providing meta-data has >>> promise. i think we should come up with a vocabulary of custom attributes to >>> include in a , or make our own css-like dialect. >>> >>> On Fri, Feb 4, 2011 at 6:36 PM, Steve Roberts wrote: >>>> >>>> Do you mean come up with a custom data type that Collect recognizes so >>>> switches the keypad? My actual pattern can be "[a-z0-9][0-9][0-9]". So >>>> could it be smart enough that after the first digit is pressed that it then >>>> switches to the numeric keypad. I can see where a special data type could >>>> be used to choose a default but I'm probably pressing my luck thinking it >>>> would be easy to have it watch a regex pattern develop and notice that Hey >>>> the next character can only be a number so I'll be nice and switch on the >>>> numeric keypad. >>>> >>>> On Fri, Feb 4, 2011 at 3:26 PM, Yaw Anokwa wrote: >>>>> >>>>> the keypads we display map to data types. is is not possible to >>>>> override this in the xform, but it is pretty easy to do it in the >>>>> collect source. >>>>> >>>>> On Fri, Feb 4, 2011 at 14:57, Steve Roberts wrote: >>>>> > I have input which is basically a string but for the most parts it is >>>>> > typically numeric. Is it possible to have a string type but force the >>>>> > displayed keypad to be launched as the numeric rather that alpha? >>>>> > -steve- >>>>> > >>>>> > -- >>>>> > Post: opendatakit@googlegroups.com >>>>> > Unsubscribe: opendatakit+unsubscribe@googlegroups.com >>>>> > Options: http://groups.google.com/group/opendatakit?hl=en >>>>> > >>>>> >>>>> -- >>>>> Post: opendatakit@googlegroups.com >>>>> Unsubscribe: opendatakit+unsubscribe@googlegroups.com >>>>> Options: http://groups.google.com/group/opendatakit?hl=en >>>> >>>> -- >>>> Post: opendatakit@googlegroups.com >>>> Unsubscribe: opendatakit+unsubscribe@googlegroups.com >>>> Options: http://groups.google.com/group/opendatakit?hl=en >>> >>> -- >>> Post: opendatakit@googlegroups.com >>> Unsubscribe: opendatakit+unsubscribe@googlegroups.com >>> Options: http://groups.google.com/group/opendatakit?hl=en >> >> -- >> Post: opendatakit@googlegroups.com >> Unsubscribe: opendatakit+unsubscribe@googlegroups.com >> Options: http://groups.google.com/group/opendatakit?hl=en > > -- > Post: opendatakit@googlegroups.com > Unsubscribe: opendatakit+unsubscribe@googlegroups.com > Options: http://groups.google.com/group/opendatakit?hl=en >

here are the custom keywords i've been using for touchforms. they are
encoded as css-like style declarations and stuffed into the 'appearance'
attribute.

you can see all these features demoed here: http://xforms.dimagi.com/enter/8

domain: (alpha|numeric|full) and also extensions like 'phone' (phone number)

  • specify the 'sub-type' of a string question, which changes the available
    keyboard. 'numeric' means show only number pad. 'alpha' means 'A-Z'
    keyboard. 'phone' gives a numeric keypad plus a '+' symbol.

before: (N days)
after: (N days)

  • specify range limits for date entry so our calendar widget can restrict
    input appropriately. clayton has some prototype code to allow these to be
    calculated from the constraint. alternatively, we could support the
    control, which has 'min' and 'max' attributes (which we would then have to
    break from spec and extend to allow xpath expressions, instead of just
    static values).

example: -- allow up
to 60 days in the past, today, or tomorrow

unit: eg., 'kg', '°C', 'bpm'

  • specify the unit of a numeric field. instead of having to write 'enter
    weight in kg', just say 'enter weight', and specify unit as 'kg'. the 'kg'
    is rendered next to the input box, not in the caption.

prefix:

  • specify a prefix to pre-populate into a text question. useful for ID
    numbers. the prefix is NOT considered a default answer to the question

mask: eg. xxx-xx-xxxxx-x

  • specify an input mask for ID numbers. each 'x' becomes a single-character
    box in the UI. the dashes (or any other character) as NOT part of the
    resulting answer

mode: autocomplete
autocomplete-key:

  • enable autocompletion for the given question. autocomplete-key tells the
    engine what kind of data to provide. if absent, defaults to value of
    'domain'.

example:

as-select1: (comma-separated list of indices)

  • on a multi-select, specify certain choices that will trigger select1-style
    autoadvance behavior. useful for exclusive options like 'none of the above'.
··· On Sat, Feb 5, 2011 at 2:02 PM, Yaw Anokwa wrote:

we've been using the appearance tag in 1.1.6 to do question grouping
and will be doing more with different kinds of select widgets. i'd
like us to converge on a rough standard before this stuff gets out of
our control and starts breaking compatibility. i know clayton was
concerned about folks using appearance as a way to bypass form logic,
so we were hoping for some whitelist of keyboards that would get
passed up through the core.

drew, can you write up what you have and the community can iterate
through some of the keywords we might need? i figure with feedback
from adam and mitch, we should be able to get a rough xforms-friendly
spec in place.

On Sat, Feb 5, 2011 at 00:55, Adam Lerer adam.lerer@gmail.com wrote:

If you really want to see my hack for adding rendering attributes, you
can
look at the ODK Voice code, but it's a terrible hack and I'm not very
proud
of it, so I'd rather not post it on this list as some sort of example
code.
As a member of the JavaRosa team, Drew might be able to tell you the
least
offensive place to put your attributes.

On Fri, Feb 4, 2011 at 11:07 PM, Steve Roberts steve@roberts.org wrote:

Is the hack something you can share?

On Fri, Feb 4, 2011 at 4:36 PM, Drew Roos droos@dimagi.com wrote:

i confronted this problem when making touchforms -- a web interface for
xforms meant to be used on touchscreen kiosks, powered by javarosa.

the solution i came up with is to keep the data as a string, but
provide

css-like meta-data about the question that the rendering engine can act
on.

in this case, that the 'domain' of the data is numeric, even though the
datatype itself is 'string'. my view shows a numeric keypad in this
case

instead of the full keyboard.

we have no standard for annotating questions with this meta-data, so
for

the time being i hacked it into the question's appearance attribute.
this is

clearly a hack, but i think the overall idea of providing meta-data has
promise. i think we should come up with a vocabulary of custom
attributes to

include in a , or make our own css-like dialect.

On Fri, Feb 4, 2011 at 6:36 PM, Steve Roberts steve@roberts.org wrote:

Do you mean come up with a custom data type that Collect recognizes so
switches the keypad? My actual pattern can be "[a-z0-9][0-9][0-9]".
So

could it be smart enough that after the first digit is pressed that it
then

switches to the numeric keypad. I can see where a special data type
could

be used to choose a default but I'm probably pressing my luck thinking
it

would be easy to have it watch a regex pattern develop and notice that
Hey

the next character can only be a number so I'll be nice and switch on
the

numeric keypad.

On Fri, Feb 4, 2011 at 3:26 PM, Yaw Anokwa yanokwa@gmail.com wrote:

the keypads we display map to data types. is is not possible to
override this in the xform, but it is pretty easy to do it in the
collect source.

On Fri, Feb 4, 2011 at 14:57, Steve Roberts steve@roberts.org wrote:

I have input which is basically a string but for the most parts it
is

typically numeric. Is it possible to have a string type but force
the

displayed keypad to be launched as the numeric rather that alpha?
-steve-

--
Post: opendatakit@googlegroups.com
Unsubscribe: opendatakit+unsubscribe@googlegroups.com
Options: http://groups.google.com/group/opendatakit?hl=en

--
Post: opendatakit@googlegroups.com
Unsubscribe: opendatakit+unsubscribe@googlegroups.com
Options: http://groups.google.com/group/opendatakit?hl=en

--
Post: opendatakit@googlegroups.com
Unsubscribe: opendatakit+unsubscribe@googlegroups.com
Options: http://groups.google.com/group/opendatakit?hl=en

--
Post: opendatakit@googlegroups.com
Unsubscribe: opendatakit+unsubscribe@googlegroups.com
Options: http://groups.google.com/group/opendatakit?hl=en

--
Post: opendatakit@googlegroups.com
Unsubscribe: opendatakit+unsubscribe@googlegroups.com
Options: http://groups.google.com/group/opendatakit?hl=en

--
Post: opendatakit@googlegroups.com
Unsubscribe: opendatakit+unsubscribe@googlegroups.com
Options: http://groups.google.com/group/opendatakit?hl=en

--
Post: opendatakit@googlegroups.com
Unsubscribe: opendatakit+unsubscribe@googlegroups.com
Options: http://groups.google.com/group/opendatakit?hl=en

I'm not familiar with javarosa, so I've been building forms using XLSforms. Is there a way to restrict the keyboard to numeric when the type=integer. I tried appearance='domain: numeric' and that didn't work.

Thanks!

··· On Tuesday, February 8, 2011 9:37:25 AM UTC-8, Drew Roos (Dimagi) wrote: > here are the custom keywords i've been using for touchforms. they are encoded as css-like style declarations and stuffed into the 'appearance' attribute. > > you can see all these features demoed here: http://xforms.dimagi.com/enter/8 > > > domain: (alpha|numeric|full) and also extensions like 'phone' (phone number) > - specify the 'sub-type' of a string question, which changes the available keyboard. 'numeric' means show only number pad. 'alpha' means 'A-Z' keyboard. 'phone' gives a numeric keypad plus a '+' symbol. > > > before: (N days) > after: (N days) > - specify range limits for date entry so our calendar widget can restrict input appropriately. clayton has some prototype code to allow these to be calculated from the constraint. alternatively, we could support the control, which has 'min' and 'max' attributes (which we would then have to break from spec and extend to allow xpath expressions, instead of just static values). > > > example: -- allow up to 60 days in the past, today, or tomorrow > > unit: eg., 'kg', '°C', 'bpm' > - specify the unit of a numeric field. instead of having to write 'enter weight in kg', just say 'enter weight', and specify unit as 'kg'. the 'kg' is rendered next to the input box, not in the caption. > > > prefix: > - specify a prefix to pre-populate into a text question. useful for ID numbers. the prefix is NOT considered a default answer to the question > > mask: eg. xxx-xx-xxxxx-x > - specify an input mask for ID numbers. each 'x' becomes a single-character box in the UI. the dashes (or any other character) as NOT part of the resulting answer > > > mode: autocomplete > autocomplete-key: > - enable autocompletion for the given question. autocomplete-key tells the engine what kind of data to provide. if absent, defaults to value of 'domain'. > > example: > > > > as-select1: (comma-separated list of indices) > - on a multi-select, specify certain choices that will trigger select1-style autoadvance behavior. useful for exclusive options like 'none of the above'. > > > > > > On Sat, Feb 5, 2011 at 2:02 PM, Yaw Anokwa wrote: > > we've been using the appearance tag in 1.1.6 to do question grouping > > and will be doing more with different kinds of select widgets. i'd > > like us to converge on a rough standard before this stuff gets out of > > our control and starts breaking compatibility. i know clayton was > > concerned about folks using appearance as a way to bypass form logic, > > so we were hoping for some whitelist of keyboards that would get > > passed up through the core. > > > > drew, can you write up what you have and the community can iterate > > through some of the keywords we might need? i figure with feedback > > from adam and mitch, we should be able to get a rough xforms-friendly > > spec in place. > > > > > > > > > On Sat, Feb 5, 2011 at 00:55, Adam Lerer wrote: > > > If you really want to see my hack for adding rendering attributes, you can > > > look at the ODK Voice code, but it's a terrible hack and I'm not very proud > > > of it, so I'd rather not post it on this list as some sort of example code. > > > As a member of the JavaRosa team, Drew might be able to tell you the least > > > offensive place to put your attributes. > > > > > > On Fri, Feb 4, 2011 at 11:07 PM, Steve Roberts wrote: > > >> > > >> Is the hack something you can share? > > >> > > >> On Fri, Feb 4, 2011 at 4:36 PM, Drew Roos wrote: > > >>> > > >>> i confronted this problem when making touchforms -- a web interface for > > >>> xforms meant to be used on touchscreen kiosks, powered by javarosa. > > >>> > > >>> the solution i came up with is to keep the data as a string, but provide > > >>> css-like meta-data about the question that the rendering engine can act on. > > >>> in this case, that the 'domain' of the data is numeric, even though the > > >>> datatype itself is 'string'. my view shows a numeric keypad in this case > > >>> instead of the full keyboard. > > >>> > > >>> we have no standard for annotating questions with this meta-data, so for > > >>> the time being i hacked it into the question's appearance attribute. this is > > >>> clearly a hack, but i think the overall idea of providing meta-data has > > >>> promise. i think we should come up with a vocabulary of custom attributes to > > >>> include in a , or make our own css-like dialect. > > >>> > > >>> On Fri, Feb 4, 2011 at 6:36 PM, Steve Roberts wrote: > > >>>> > > >>>> Do you mean come up with a custom data type that Collect recognizes so > > >>>> switches the keypad? My actual pattern can be "[a-z0-9][0-9][0-9]". So > > >>>> could it be smart enough that after the first digit is pressed that it then > > >>>> switches to the numeric keypad. I can see where a special data type could > > >>>> be used to choose a default but I'm probably pressing my luck thinking it > > >>>> would be easy to have it watch a regex pattern develop and notice that Hey > > >>>> the next character can only be a number so I'll be nice and switch on the > > >>>> numeric keypad. > > >>>> > > >>>> On Fri, Feb 4, 2011 at 3:26 PM, Yaw Anokwa wrote: > > >>>>> > > >>>>> the keypads we display map to data types. is is not possible to > > >>>>> override this in the xform, but it is pretty easy to do it in the > > >>>>> collect source. > > >>>>> > > >>>>> On Fri, Feb 4, 2011 at 14:57, Steve Roberts wrote: > > >>>>> > I have input which is basically a string but for the most parts it is > > >>>>> > typically numeric. Is it possible to have a string type but force the > > >>>>> > displayed keypad to be launched as the numeric rather that alpha? > > >>>>> > -steve- > > >>>>> > > > >>>>> > -- > > >>>>> > Post: opend...@googlegroups.com > > >>>>> > Unsubscribe: opendatakit...@googlegroups.com > > >>>>> > Options: http://groups.google.com/group/opendatakit?hl=en > > >>>>> > > > >>>>> > > >>>>> -- > > >>>>> Post: opend...@googlegroups.com > > >>>>> Unsubscribe: opendatakit...@googlegroups.com > > >>>>> Options: http://groups.google.com/group/opendatakit?hl=en > > >>>> > > >>>> -- > > >>>> Post: opend...@googlegroups.com > > >>>> Unsubscribe: opendatakit...@googlegroups.com > > >>>> Options: http://groups.google.com/group/opendatakit?hl=en > > >>> > > >>> -- > > >>> Post: opend...@googlegroups.com > > >>> Unsubscribe: opendatakit...@googlegroups.com > > >>> Options: http://groups.google.com/group/opendatakit?hl=en > > >> > > >> -- > > >> Post: opend...@googlegroups.com > > >> Unsubscribe: opendatakit...@googlegroups.com > > >> Options: http://groups.google.com/group/opendatakit?hl=en > > > > > > -- > > > Post: opend...@googlegroups.com > > > Unsubscribe: opendatakit...@googlegroups.com > > > Options: http://groups.google.com/group/opendatakit?hl=en > > > > > > > -- > > > > > Post: opend...@googlegroups.com > > Unsubscribe: opendatakit...@googlegroups.com > > Options: http://groups.google.com/group/opendatakit?hl=en

The suggestion was to have:

type = string
appearance = numbers

http://opendatakit.org/help/form-design/examples/#numeric_string

··· On Mon, Jul 22, 2013 at 1:50 PM, wrote:

I'm not familiar with javarosa, so I've been building forms using
XLSforms. Is there a way to restrict the keyboard to numeric when the
type=integer. I tried appearance='domain: numeric' and that didn't work.

Thanks!

On Tuesday, February 8, 2011 9:37:25 AM UTC-8, Drew Roos (Dimagi) wrote:

here are the custom keywords i've been using for touchforms. they are
encoded as css-like style declarations and stuffed into the 'appearance'
attribute.

you can see all these features demoed here:
http://xforms.dimagi.com/enter/8

domain: (alpha|numeric|full) and also extensions like 'phone' (phone
number)

  • specify the 'sub-type' of a string question, which changes the
    available keyboard. 'numeric' means show only number pad. 'alpha' means
    'A-Z' keyboard. 'phone' gives a numeric keypad plus a '+' symbol.

before: (N days)
after: (N days)

  • specify range limits for date entry so our calendar widget can
    restrict input appropriately. clayton has some prototype code to allow
    these to be calculated from the constraint. alternatively, we could support
    the control, which has 'min' and 'max' attributes (which we would
    then have to break from spec and extend to allow xpath expressions, instead
    of just static values).

example: -- allow
up to 60 days in the past, today, or tomorrow

unit: eg., 'kg', '°C', 'bpm'

  • specify the unit of a numeric field. instead of having to write 'enter
    weight in kg', just say 'enter weight', and specify unit as 'kg'. the 'kg'
    is rendered next to the input box, not in the caption.

prefix:

  • specify a prefix to pre-populate into a text question. useful for ID
    numbers. the prefix is NOT considered a default answer to the question

mask: eg. xxx-xx-xxxxx-x

  • specify an input mask for ID numbers. each 'x' becomes a
    single-character box in the UI. the dashes (or any other character) as NOT
    part of the resulting answer

mode: autocomplete
autocomplete-key:

  • enable autocompletion for the given question. autocomplete-key tells
    the engine what kind of data to provide. if absent, defaults to value of
    'domain'.

example:

as-select1: (comma-separated list of indices)

  • on a multi-select, specify certain choices that will trigger
    select1-style autoadvance behavior. useful for exclusive options like 'none
    of the above'.

On Sat, Feb 5, 2011 at 2:02 PM, Yaw Anokwa yan...@gmail.com wrote:

we've been using the appearance tag in 1.1.6 to do question grouping

and will be doing more with different kinds of select widgets. i'd

like us to converge on a rough standard before this stuff gets out of

our control and starts breaking compatibility. i know clayton was

concerned about folks using appearance as a way to bypass form logic,

so we were hoping for some whitelist of keyboards that would get

passed up through the core.

drew, can you write up what you have and the community can iterate

through some of the keywords we might need? i figure with feedback

from adam and mitch, we should be able to get a rough xforms-friendly

spec in place.

On Sat, Feb 5, 2011 at 00:55, Adam Lerer adam....@gmail.com wrote:

If you really want to see my hack for adding rendering attributes, you
can

look at the ODK Voice code, but it's a terrible hack and I'm not very
proud

of it, so I'd rather not post it on this list as some sort of example
code.

As a member of the JavaRosa team, Drew might be able to tell you the
least

offensive place to put your attributes.

On Fri, Feb 4, 2011 at 11:07 PM, Steve Roberts st...@roberts.org wrote:

Is the hack something you can share?

On Fri, Feb 4, 2011 at 4:36 PM, Drew Roos dr...@dimagi.com wrote:

i confronted this problem when making touchforms -- a web interface
for

xforms meant to be used on touchscreen kiosks, powered by javarosa.

the solution i came up with is to keep the data as a string, but
provide

css-like meta-data about the question that the rendering engine can
act on.

in this case, that the 'domain' of the data is numeric, even though
the

datatype itself is 'string'. my view shows a numeric keypad in this
case

instead of the full keyboard.

we have no standard for annotating questions with this meta-data, so
for

the time being i hacked it into the question's appearance attribute.
this is

clearly a hack, but i think the overall idea of providing meta-data
has

promise. i think we should come up with a vocabulary of custom
attributes to

include in a , or make our own css-like dialect.

On Fri, Feb 4, 2011 at 6:36 PM, Steve Roberts st...@roberts.org wrote:

Do you mean come up with a custom data type that Collect recognizes
so

switches the keypad? My actual pattern can be
"[a-z0-9][0-9][0-9]". So

could it be smart enough that after the first digit is pressed that
it then

switches to the numeric keypad. I can see where a special data
type could

be used to choose a default but I'm probably pressing my luck
thinking it

would be easy to have it watch a regex pattern develop and notice
that Hey

the next character can only be a number so I'll be nice and switch
on the

numeric keypad.

On Fri, Feb 4, 2011 at 3:26 PM, Yaw Anokwa yan...@gmail.com wrote:

the keypads we display map to data types. is is not possible to

override this in the xform, but it is pretty easy to do it in the

collect source.

On Fri, Feb 4, 2011 at 14:57, Steve Roberts st...@roberts.org wrote:

I have input which is basically a string but for the most parts
it is

typically numeric. Is it possible to have a string type but
force the

displayed keypad to be launched as the numeric rather that alpha?

-steve-

--

Post: opend...@googlegroups.com

Unsubscribe: opendatakit...@googlegroups.com

Options: http://groups.google.com/group/opendatakit?hl=en

--

Post: opend...@googlegroups.com

Unsubscribe: opendatakit...@googlegroups.com

Options: http://groups.google.com/group/opendatakit?hl=en

--

Post: opend...@googlegroups.com

Unsubscribe: opendatakit...@googlegroups.com

Options: http://groups.google.com/group/opendatakit?hl=en

--

Post: opend...@googlegroups.com

Unsubscribe: opendatakit...@googlegroups.com

Options: http://groups.google.com/group/opendatakit?hl=en

--

Post: opend...@googlegroups.com

Unsubscribe: opendatakit...@googlegroups.com

Options: http://groups.google.com/group/opendatakit?hl=en

--

Post: opend...@googlegroups.com

Unsubscribe: opendatakit...@googlegroups.com

Options: http://groups.google.com/group/opendatakit?hl=en

--

Post: opend...@googlegroups.com

Unsubscribe: opendatakit...@googlegroups.com

Options: http://groups.google.com/group/opendatakit?hl=en

--

Post: opendatakit@googlegroups.com
Unsubscribe: opendatakit+unsubscribe@googlegroups.com
Options: http://groups.google.com/group/opendatakit?hl=en


You received this message because you are subscribed to the Google Groups
"ODK Community" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to opendatakit+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

--
Mitch Sundt
Software Engineer
University of Washington
mitchellsundt@gmail.com