Re: @number attribute on xforms:repeat

Hello Erik

Erik Bruchez wrote:
> 
> 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?

Chiba doesn't implement @number yet, simply because we didn't find the 
time to do it. However, my interpretation would be against scrolling. I 
think of @number as the window/block size of visible repeat items. When 
index changes, the window/block is shifted until it covers the selected 
item.

Regards,
Uli.

> 
> -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>
> 
> 
> 
> 


-- 
Ulrich Nicolas Lissé

Received on Wednesday, 30 November 2005 20:48:02 UTC