Re: Xforms appearances without stylesheets and AccessKey

Thanks for the replies

  After getting the initial replies, I looked at how hard implementing
stylesheets would be, and managed to get these functioning enough, and
still within legal syntax.  eg
 <input appearance="full" class="superbig" ....

 This works fine for single elements, and cleanly places the visual
appearance outside the xforms arena (which I very much got the hint was the
concept). In the case of the group/switch elements, there just aren't
enough values to handle the options we personally want, so in this case I
think we will have to add a few more eg,
<group appearance="fdl:popup" class="shippingaddress" ....

 Which should mean it works with fine level control if we are rendering,
but degrade reasonably well for other display devices.

 To explain some of our complexity, if we draw a form that requires a
"product name" (we are retail environments), then a classic approach would
be a select list, but we could have over 2 million items in the list for
some customers, with only 5 for others, so we need to switch appearance
based on factors other than @apperance.  No problems so far, we can do that
when we render the form, especially given the hint @appearance provides. If
however, the user scans a product with a barcode scanner while this form is
displayed, then externally, we need to identify the product and populate
that field on the form. No real problems here either, but it does mean that
the "select" for a 2 million item customer should be a single field input
box, unless the user types something, in which case we need to popup
another display screen capable of searching within 2 million items.
Interesting, but I think this is all do-able within the XForms framework,
and probably more of a problem for our auto generator to select wisely in
the first place.


In a similar vein, has anybody used "accesskey" attribute ?
The spec mentions it briefly, and I couldnt find any further details in the
references. Our environment can consist of programmable keyboards
(basically grids of keys that can be statically defined to send sequences
of characters), and it would be nice to link those keys to form
accelerators.  I could do it by overloading the various events, but
accesskey seems to promise a cleaner solution.

Regards
.Richard




At 22:54 20/11/2003 +0100, joern turner wrote:
>Hello Richard,
>
>actually a very interesting issue you brought up - i try to share some 
>of our experiences...
>
>Richard Brett wrote:
>> Hello
>> 
>>   We are starting to use XForms for generating screens dynamically from XSD
>> and other XML document types.  This is a being used in an application that
>> receives SOAP requests and may need to present user input, but without
>> knowing until runtime how the form will appear exactly (ie, no static form
>> definitions).  To do this, we dynamically convert xsd/xml to xforms and
>> have implemented some code to then convert xforms into user presentation
>> screens.  Note, we have not implemented all of xforms, so are not claiming
>> to be a conforming application.
>> 
>> Our "output" devices are not browser based, and we do not have stylesheets
>> ability, which is driving some of the following questions.  I aren't
>> totally keen to implement stylesheets, and are searching for ideas on how
>> others using XForms in constrained environments may have solved some
problems.
>> 
>> 
>> Question: Actual item appearance. While the standard says we can use
>> 	appearance=full | simple | QName-but-not-NCName
>>  I haven't found much on what the final tag is for?  Can we overload this
>> to provide a series of extended input display styles  eg, "radio",
>> "tickbox", or does it have another purpose?  To clarify, the simple sex
>> entry of M/F can be presented to the user in many different styles, and the
>> list of full/simple is potentially not strongly defined enough for some of
>> our customer requirements.
>> 
>> The options I can see are:
>> a)	appearance="our-style-name"
>right - that's an option and maybe the best - but you should carefully 
>choose the values for this attribute - XForms gives a hint here - 
>'full,compact,minimal' do not imply any specific visual qualities but 
>can also be applied to e.g. voice applications.
>
>> 
>> b)	<extension> ? 
>sure this is another, but your forms interoperability will be limited by 
>that cause your extensions must be present on the target platform/device
>
>> 
>> c)	Simply add a new attribute to element tags for our own purposes
>> 	<select ....   my-private-style-hint="popup-window">
>nobody hinders you to do so - XForms is not stand-alone and must allow 
>foreign namespaced attributes - but it's another custom option and the 
>same as for b) applies.
>
>> 
>> d)	implement style="stylesheet options", so that stylesheet elements can be
>> embedded, are not require a CSS file to be called.
>same as c) and maybe sometimes the only way to have very finegrained 
>control for a form with special layout requirements that doesn't fit in 
>your overall generic layout.
>
>> 
>> e)	Am I just wrong to try and use Xforms to control the appearance also,
>> and should be using it only to control the "purpose" (as per requirements
>> spec), and implement a separate "presentation" layer around xforms?
>> 
>
>to sum up: IMO the appearance attributes offers all you need to give 
>your engine the required 'styling hints' and even gives you the power of 
>defining some kind of layout-templates - we've used this approach in 
>Chiba to interpret the standard values 'full', 'compact' and 'minimal' 
>for groups and repeats and this gives us the author the option of 
>choosing between a flowlayout, a vertical or horizontal table if the 
>client uses html. for a different client we may interpret these options 
>in a different manner appropriate for that device. The interpretation of 
>  the attribute may happen at generation or at runtime dependent on your 
>needs.
>if this approach is not sufficient for a specific job i would use option 
>d) additionally.
>
>regards,
>
>Joern Turner
>
>
>> 
>>  While I know we can choose whatever we like as we currently draw the
>> output from the forms ourselves, I know that these forms will end up in
>> time being displayed on other web based devices too, so want to chose a
>> method that fits general standard direction.
>> 
>> 
>> Thanks for any guidance
>> .Richard
>> (Constantly concerned he just hasnt read some part of the documentation
>> before asking this question....)
>> 
>> 
>
>
>
>

Received on Thursday, 20 November 2003 19:14:23 UTC