Add status message API

[lsmith]

Likely a class extension that auto-mix()es onto Y.DataTable.

Adds showMessage([html]) and hideMessage() methods to the proto and a statusMessage attribute that defaults to "No records". Possibly, include a noRecordsMessage or some such (warning: naming discussion) as a separate attribute for that specific case.

showMessage() will display the configured message. showMessage(html) will show the provided message. I don't think it should update the attribute.

The challenging part here is when and how to wire it in to DT operation. It should initialize with an after('render') to display the message if the data is empty, and perhaps on(['dataChange', '*:change', '*:reset', etc]) to hide the message. Then a sync layer implementation could attach the loading message if a feature test showed the extension was there.

[lsmith]

yuilibrary.com ticket for this issue is http://yuilibrary.com/projects/yui3/ticket/2530593

[mosen]

Some thoughts from my own 'no rows' message, adapted from DT 3.3:

ModelList's add, remove and reset should provide enough information to determine whether there are records or not.

The DT implementation can simply render no rows for a modellist containing no models.

The message extension doesn't necessarily need to go after the rows have been processed because it can determine modellist.size() to be zero or not concurrently with the DT view renderer, and display the message inside its own element (normally a different TBODY element, but whatever suits the design).

[lsmith]

Perhaps a class extension to add the methods to Y.DataTable and plug in a Plugin into the bodyView (or the DT instance itself?) that monitors changes in the modelList or data.

@mosen, you're thinking just a plugin into the DT itself would be preferable to one on the bodyView? I'm cautious of the variable nature of the bodyView introducing a case where the the modelList is empty, but the bodyView, for whatever reason, still renders something. Your plan is probably the most pragmatic, though. It should be easy enough to override bits or provide an alternate messaging implementation if needed.

[mosen]

@lsmith, I was framing the discussion too much around the 3.3 version of DT. The equivalent functionality would be a second bodyView holding the message but not always being visible. I'm considering though whether there might be a situation where you would want to stop events on the entire table?