Re: @number attribute on xforms:repeat

I am ok with this being only a hint. I am also ok with different 
implementations providing different visual appearances - even though I 
think that it would make sense, in order to help spread adoption of 
XForms, to seriously discuss how XForms and (X)HTML interoperate, and to 
recommend visual apperances to implementors. In fact, the XForms spec 
does make suggestion for the appearance of xforms:select/@appearance and 
xforms:select1/@appearance, and it could do so for xforms:repeat/@number 
as well.

The spec could also be clearer and tackle the issue that was raised by 
Allan, which is that if an implementation shows repeated items 1-10 as 
per the hint, and the setindex action selects index 14, the 
implementation SHOULD make sure that item 14 becomes visible to the user.

So far I seem to have a confirmation that you can do whatever you please 
in your implementation, including using scrolling or paging of repeated 
items using @number as a hint, although I have yet to hear strong 
feedback in the line of "Yes, that makes sense, that's cool!" ;-)

Part of my initial questions remains though: how do current 
implementations of XForms + (X)HTML interpret the spec? Has everybody 
done like Allan and happily ignored this attribute?

-Erik

T.V Raman wrote:
> 
> Eric,
> But since an xforms+xhtml instance might be run on different
> screen sizes and different device form factors, number on
> xf:repeat will still have to remain a hint at best.
> 
> The design intent behind  this hint was that it allowed the
> author to state a preference for the number of items that would
> be displayed.
> 
> As far as interoperability goes, XForms was never intended to
> display the same form *identically* in different environments, in
> fact the contrary. 
> Given its intent-based authoring focus, interoperability amongst
> XForms user agents means you get the "same answer" when you fill
> out the form independent of implementation --- but that "answer"
> does not include visual appearance (or for that matter auditory
> appearance).
> 
> XForms among 
> 
> 
>>>>>>"Erik" == Erik Bruchez <erik@bruchez.org> writes:
> 
>     Erik> Mark Birbeck wrote:
>     >> It is a hint, and as such can rightly be ignored.
>     >> 
>     >> Just in terms of why it's a hint, the problem is more the
>     >> other way round; how would we come up with a
>     >> cross-platform, device-independent way of defining
>     >> @number? Obviously we could say that it is used to
>     >> indicate how many 'rows' of a xf:repeat are rendered, but
>     >> then is a photocopier or a fax machine non-conformant if
>     >> it can only show one row at a time?
>     Erik> 
>     Erik> I agree with this. But now I can reformulate my
>     Erik> question for XForms engine with HTML or XHTML as host
>     Erik> language, since this is my main focus. In this case,
>     Erik> there should be agreement among XForms engines
>     Erik> implementors as to what the desired behavior should be.
>     Erik> 
>     >> At one time I was keen for at least number="1" to have
>     >> mandated behaviour (i.e., the device could process any
>     >> other values of @number as best they could, but '1' should
>     >> always only show one iteration), since that makes
>     >> wizard-style forms really easy to write, safe in the
>     >> knowledge that they will be the same on all devices. But
>     >> even with that we found that there were other ways to do
>     >> it, and so the enthusiasm for mandating that waned!
>     Erik> 
>     Erik> Understandable.
>     Erik> 
>     >> Finally, on the specific questions raised in this thread:
>     >> no, @number doesn't affect index() or setindex
>     Erik> 
>     Erik> Makes perfect sense to me.
>     Erik> 
>     >> and no, it can't be used for things like paging. The
>     >> latter needs to be set up by the form author (there are a
>     >> number of examples on our site).
>     Erik> 
>     Erik> We have also done paging using other means, but why
>     Erik> couldn't @number be used for such a purpose? I would
>     Erik> argue that this would be a great use of this
>     Erik> attribute. If I put together these two sentences from
>     Erik> the spec:
>     Erik> 
>     Erik>    "number - Optional hint to the XForms Processor as
>     Erik> to how many elements from the collection to display."
>     Erik> 
>     Erik> and:
>     Erik> 
>     Erik>    "Attributes on this element specify how many members
>     Erik> of the collection are presented to the user at any
>     Erik> given time."
>     Erik> 
>     Erik> This rings to me such words as "scrolling" or "paging",
>     Erik> hence my original question as to what people's
>     Erik> interpretation is. Certainly, it doesn't seem like the
>     Erik> spec precludes an XForms engine to implement scrolling
>     Erik> or paging of repeated sections based on this attribute.
>     Erik> 
>     Erik> -Erik
>     Erik> 
>

Received on Monday, 28 November 2005 17:49:20 UTC