302026 - Support number attribute in repeat element

Status: RESOLVED WONTFIX

(Core Graveyard :: XForms, enhancement)

Description

[Stephen Pride]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b4) Gecko/20050725 Firefox/1.0+
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b4) Gecko/20050725 Firefox/1.0+

Need to support number="" attribute for the <xf:repeat> element.

Reproducible: Always

Comment 1

[Stephen Pride]

Attachment: testcase

Comment 2

[Allan Beaufour]

Hmm, we had that discussion in another bug....
https://bugzilla.mozilla.org/show_bug.cgi?id=278209#c34, obviously I forgot to
create a bug for it :(

The spec states:
"Optional hint to the XForms Processor as to how many elements from the
collection to display."
(http://www.w3.org/TR/xforms/slice9.html#ui-repeat)

So it's not 100% a need. And it's not evident how it should be implemented either.

Comment 3

[aaronr]

well, this might not be strictly required to be 1.0 compliant, but I think that this is an important bug with many uses and since it is mentioned in the spec (and other processors support it) then authors will want to use it.  I hope that this gets in before 1.0.

Comment 4

[alexander :surkov (:asurkov)]

repeat can show number of elements only corresponding @number attibute, the rest of elements can be available though scrollbar. We can use overflow style to show scrollbar and set width/height (it depends on repeat orientation) of repeat by using the formula repeatWidth/count*number. How does xforms other processors do?

Comment 5

[aaronr]

(In reply to comment #4)
> repeat can show number of elements only corresponding @number attibute, the
> rest of elements can be available though scrollbar. We can use overflow style
> to show scrollbar and set width/height (it depends on repeat orientation) of
> repeat by using the formula repeatWidth/count*number. How does xforms other
> processors do?
> 

formsPlayer seems to be the only browser processor that supports it.  And they don't use scrollbars.  They just show the 'number' of repeat items, which will kind of scroll as you increment/decrement the index since the index repeat item has to be visible.

Comment 6

[alexander :surkov (:asurkov)]

(In reply to comment #5)

> formsPlayer seems to be the only browser processor that supports it.  And they
> don't use scrollbars.  They just show the 'number' of repeat items, which will
> kind of scroll as you increment/decrement the index since the index repeat item
> has to be visible.
> 

Ok, the problem only is in that how to show repeat element with current index always. We can use maxheight/maxwidth to show the certain number of repeat elements. If anybody wants to see scrollbar then he can add it via css.

Comment 7

[aaronr]

(In reply to comment #6)
> (In reply to comment #5)
> 
> > formsPlayer seems to be the only browser processor that supports it.  And they
> > don't use scrollbars.  They just show the 'number' of repeat items, which will
> > kind of scroll as you increment/decrement the index since the index repeat item
> > has to be visible.
> > 
> 
> Ok, the problem only is in that how to show repeat element with current index
> always. We can use maxheight/maxwidth to show the certain number of repeat
> elements. If anybody wants to see scrollbar then he can add it via css.
> 


I wouldn't mind the scroll bar approach.  But it could be confusing to the user to move the scroll position move away from where the user had it.  Which could happen if the index changed due to some interaction with another control.

Comment 8

[Steve Speicher]

It would seem that a scrollbar would be hard to manage, since the repeat items are  not styled as table-rows by default...so would it be a vertical scroll or horizontal?  Also, if there are a huge number of nodes, say 1,000's, then would the processor actually build the repeat will all nodes within the scrollable area?

Seems that just displaying the number, as formsPlayer does, and using setindex() to manage scrolling seems like the best way to achieve this, imho.

Comment 9

[Steve Speicher]

Attachment: testcase with trigger scroll

Comment 10

[Steve Speicher]

Attachment: sample implemented w/o @number, using xpath position() tests

Though it may seem like it, I don't have too much time on my hands.

Thought this might be useful to the discussion of this bug.  Too bad repeat's @startindex and @number aren't xpathexprs (likewise for range's attributes).  Guess that's another matter to bring up with the WG.

Comment 11

[aaronr]

(In reply to comment #10)
> Created an attachment (id=229986) [edit]
> sample implemented w/o @number, using xpath position() tests
> 
> Though it may seem like it, I don't have too much time on my hands.
> 
> Thought this might be useful to the discussion of this bug.  Too bad repeat's
> @startindex and @number aren't xpathexprs (likewise for range's attributes). 
> Guess that's another matter to bring up with the WG.
> 


Well, we should be able to allow for some dynamicity by listening for attribute changes and honoring them when they happen.  So even if @number isn't hooked to instance data, if @number were changed in the DOM, then the number of repeat rows that we showed would change (between 0 and the number of items in the nodeset).

I like your sample.  So going from that, assuming that the repeat was done using @number=3 and the up/down triggers just increased/decreased the index by one, I would think that if the index became such that the repeat item for it wasn't visible, then we'd 'spin' one position up or down to make it visible.  If the index row were already visible, then we wouldn't 'spin' at all.  Just like formsPlayer works.

We should also make sure that if a repeat has @number="3" and the nodeset only has two items that if two inserts were done that the third item would show but the fourth wouldn't.

Comment 12

[David Bolter [:davidb] (NeedInfo me for attention)]

RIP xforms