Last Comment Bug 302026 - Support number attribute in repeat element
: Support number attribute in repeat element
Status: RESOLVED WONTFIX
:
Product: Core Graveyard
Classification: Graveyard
Component: XForms (show other bugs)
: Trunk
: All All
: -- enhancement (vote)
: ---
Assigned To: xforms
: Stephen Pride
Mentors:
http://www.w3.org/TR/xforms/slice9.ht...
Depends on:
Blocks: 264329 322255 326372 326373
  Show dependency treegraph
 
Reported: 2005-07-25 07:05 PDT by Stephen Pride
Modified: 2016-07-15 14:46 PDT (History)
5 users (show)
See Also:
QA Whiteboard:
Iteration: ---
Points: ---


Attachments
testcase (567 bytes, application/xhtml+xml)
2005-07-25 07:07 PDT, Stephen Pride
no flags Details
testcase with trigger scroll (1.61 KB, application/xhtml+xml)
2006-07-19 06:41 PDT, Steve Speicher
no flags Details
sample implemented w/o @number, using xpath position() tests (2.54 KB, application/xhtml+xml)
2006-07-20 11:48 PDT, Steve Speicher
no flags Details

Description Stephen Pride 2005-07-25 07:05:03 PDT
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 2005-07-25 07:07:25 PDT
Created attachment 190405 [details]
testcase
Comment 2 Allan Beaufour 2005-07-25 07:25:16 PDT
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 2006-04-21 09:37:38 PDT
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 2006-07-12 07:38:09 PDT
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 2006-07-12 09:38:30 PDT
(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 2006-07-13 22:38:43 PDT
(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 2006-07-17 13:15:50 PDT
(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 2006-07-19 06:40:09 PDT
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 2006-07-19 06:41:50 PDT
Created attachment 229807 [details]
testcase with trigger scroll
Comment 10 Steve Speicher 2006-07-20 11:48:14 PDT
Created attachment 229986 [details]
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 2006-07-20 13:03:10 PDT
(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] 2016-02-04 12:19:57 PST
RIP xforms

Note You need to log in before you can comment on or make changes to this bug.