Re: Xforms appearances without stylesheets

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 16:53:59 UTC