enyo.DataRepeater does not respect 'tag' property

Description

When defining an enyo.DataRepeater in a components block, no matter what you set the 'tag' property to, it always renders a div. The only way I have found to get it to render a different element is to create a trivial kind with the tag I wish to use and then set the 'defaultKind' property on the enyo.DataRepeater to the trivial kind.

Environment

all

Activity

Show:
Lis Hammel
March 3, 2015, 7:24 PM

Update: this is still in the queue to be resolved.

Lis Hammel
March 24, 2015, 11:42 PM

We've had some discussions on this one and would appreciate more information to help us figure out next steps. Would you be able to provide a JSFiddle or at least a code snippet illustrating the problem and describing the difference between the expected / actual results? thanks.

Brian Guilfoil
March 25, 2015, 12:48 AM

In looking back at this now, it appears I posted this but it seems that it is not actually a bug. Apparently I was confused about the difference between the element that the enyo.DataRepeater renders and the element that its "container" renders. I apologize for my error in this.

I needed to render a table with a tbody element to hold the "data rows" for the repeater. I kept trying to make the repeater a tbody element and a div kept showing up instead. In my frustration I tried using various ways to get it to behave the way I needed and never noticed that the div element that was rendering was the repeater's container. It should have dawned on me that is why using "defaultKind" solved my problem.

In doing some testing so that I could answer your comment Lis, I went to the source code for the enyo.DataRepeater. This is where I just discovered the properties "containerName" and "containerOptions". In experimenting with these I was able to achieve what I had been using "defaultKind" for instead.

My question now is, should the properties "containerName" and "containerOptions" actually be marked "private"? By doing so the online API doesn't show them by default and even if you show private there is no description of what they do, or how to use them. Also, though there is practically no such thing as a private property in javascript, marking them "private" implies, at least to me, that they are not intended to be overridden. This is clearly not the case because if you need to use enyo.DataRepeater to render any of the various html nested structures, ul/li, ol/li or tbody/tr to name a few, you have to use them or the "container" will be a div and that just makes the DOM angry. I think the proper classification for them, in the classical OOP sense, would be "protected".

Again I apologize for my error in reporting this as a bug.

Lis Hammel
March 27, 2015, 3:36 AM

Thanks for all the information Brian. We have a PR pending (https://github.com/enyojs/enyo/pull/1088) to document containerName and containerOptions
and make them public. We also have a placeholder task written up to do another sweep over all the docs to re-check what is private/public/protected. Thanks again for raising this.

Assignee

Screener (Enyo Team)

Reporter

Brian Guilfoil

Labels

None

External issue ID

None

Tango Test Run Elements

None

Old Issue Key

None

Components

Affects versions

Priority

None
Configure