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=enThe 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/8domain: (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 tomorrowunit: 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 questionmask: 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 answermode: 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
canlook at the ODK Voice code, but it's a terrible hack and I'm not very
proudof 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
leastoffensive 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
forxforms 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
providecss-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
thedatatype itself is 'string'. my view shows a numeric keypad in this
caseinstead of the full keyboard.
we have no standard for annotating questions with this meta-data, so
forthe time being i hacked it into the question's appearance attribute.
this isclearly a hack, but i think the overall idea of providing meta-data
haspromise. i think we should come up with a vocabulary of custom
attributes toinclude 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
soswitches the keypad? My actual pattern can be
"[a-z0-9][0-9][0-9]". Socould it be smart enough that after the first digit is pressed that
it thenswitches to the numeric keypad. I can see where a special data
type couldbe used to choose a default but I'm probably pressing my luck
thinking itwould be easy to have it watch a regex pattern develop and notice
that Heythe next character can only be a number so I'll be nice and switch
on thenumeric 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 istypically numeric. Is it possible to have a string type but
force thedisplayed keypad to be launched as the numeric rather that alpha?
-steve-
--
Unsubscribe: opendatakit...@googlegroups.com
--
Unsubscribe: opendatakit...@googlegroups.com
--
Unsubscribe: opendatakit...@googlegroups.com
--
Unsubscribe: opendatakit...@googlegroups.com
--
Unsubscribe: opendatakit...@googlegroups.com
--
Unsubscribe: opendatakit...@googlegroups.com
--
Post: opend...@googlegroups.com
Unsubscribe: opendatakit...@googlegroups.com
--
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