Convert IP-blocking table to "Empty table pattern"

New patch, /core compatibility, no table type change and wording following #1473210: Empty table pattern for "Blocked IP Addresses" admin page proposal.

I removed the "Add one above" part because this non-standard add UI pattern needs to be overhauled anyway.

This is how it looks.

Looks good to me.

Nice! We should be able to backport this. I can take a look during my next commit spree. However, this is also about enforcing standards, so tagging it that way in case Jennifer wants to get to it first. :)

Ummm... The pattern on the base issue says:
"Pattern outlined in [#501452] :
"If the table contains no records: display within the same table a concise "call to action" message with a link which allows the user to add relevant content.""

This does not contain a call to action, or a link to add relevant content, so I don't think this brings the IP blocking table in line with this standard?

And I don't see any discussion supporting #4's comment that "the pattern needs to be overhauled anyway"... Isn't this issue about bringing the IP blocking table in line with the current standard?

IP block addresses functionality uses inline form for adding so there's no /add URL to point in call to action link. Yes, we could have "No blocked IP addresses available. Add one above" as originally suggested by karschsp but I'd better do not depend on specific spacial references in UI (element locations can change).

I'd propose go with what we have now in patch, re-visit when we rethink / harmonize "Add" UI pattern in this page in the future (correct, this discussion has not started yet).

Also, the documented pattern needs expanding, there are several cases in core when we do not have CTA part, just the "No x available" string (content and comment tables).

OK, I guess I am being stupid, sorry... The standards for tables like this page says:

Empty text:
- Use Text pattern "There are no [things] available. Add [a thing]".
- The "Add a [thing]" link is the same action as the Local action link on the same page.

But I see that the actual form to add an IP address is directly above... Actually, that is the non-standard thing. Normally the form to "add a thing" and the table listing the "things" are on different pages.

But still, there is supposed to be a "call to action" in the empty text, and this doesn't have a call to action. Shouldn't it? And should the form be moved to a different page from the listing?

@jhodgdon For backport, we cannot make it a separate page. I am on the fence if we should change the existing pattern, other than consistency there is no real reason.

Yes, the form should be moved / standardized. Then we could re-visit the empty string.

What about going back to the wording in the patch in #2 -- adding "Add one above." to the text? That would be a call to action, thereby satisfying the spirit (I think) of the interface pattern guidelines.

I'd personally avoid spatial references (but yes, help texts are full of those), fix the non-standard "Add x" interaction and re-visit the string. If there's a strong preference for "Add one above" suffix, go for that.

Yes, pattern guidelines should be more specific and tackle edge cases like this.

RE #15 - Not sure what you mean by

...fix the non-standard "Add x" interaction...

?

So, the approach is:

D7 - Add the empty table pattern, without the "actionable" part
D8 - Change the pattern, and add a page

I would not suffix the "Add one above" part, guidelines are not there to add useless text :)

@ jhodgdon will follow-up on this.

RE #17 - so the existing patch needs work, right?

I think #4 is commitable both for D7 and D8. When commited to D8, create a new issue / reference that makes sure that we re-visit committed empty string when we happen to change add interaction.

I agree that the patch from #4 is good to go for now, and I'd like to handle the add interaction in #1161486: Move IP blocking into its own module.

I'm leaving this one for catch/Dries, as it's not strictly "coding standards".

Ok, committed and pushed to 8.x and 7.x.

Since the adding a separate page for adding IP addresses is a bigger change, I think it makes sense to close this issue as fixed.

Updating tags per http://drupal.org/node/1517250