Allow "multiple" in <select name="icon_board"

Started by Angelina Belle, August 27, 2009, 12:47:41 PM

Previous topic - Next topic

Angelina Belle

I think the interface would be improved if it were easy to add a custom message icon to several boards at once.

If, for example, a forum has three "buy, sell, or trade" boards, it would be appropriate to use a custom forsale.gif on all three of these boards, but not on any other boards in the forum.

An additional benefit to this approach would be that it would be more difficult (if not impossible, depending on the implementation) to add the same message icon more than once to the same table.

In the list of message icons, each would be listed once, with the associated boardnames listed in the "Board" column (which could now be headed "Boards").
Editing options would include deleting the icon, or in "add" or "modify", selecting or de-selecting one or more boards from the drop-down. Some explanatory text would be required to explain that the user should choose "All boards" or select any number of board names from the drop-down.

Implementing this change may require changing the structure of the table message_icons, so that a file name does not have to be associated with several different icon_ids. This might involve adding another table (message_icon_boards?) to reflect the one-to-many relationship between icons and boards.

$context['icons']['board'] would become an array, $context['icons']['boards'].

SQL statements for SELECT and INSERT would have to be changed. After the "modify" form has been submitted, the code would need to check to see if any boards currently associated with the icon are no long selected and so need to be deleted for that icon_id.

It sounds like a bit of work for a modest improvement in the interface! But I think it is worth scheduling into "ease of use" improvements.

Thanks for considering my enhancement suggestion.

AB
Never attribute to malice that which is adequately explained by stupidity. -- Hanlon's Razor

Arantor

It will be another table for the one-to-many relation, but more to the point you'll slow down a fair amount of the forum because that table-join would apply on many different pages and in many contexts.

1.1 is only maintained, not actively developed, 2.0 is feature-locked - but it can be considered for 2.1. I don't know if there are any plans to update this feature generally; several other updates for this have been requested.

Jade Elizabeth

I want :D.

You know how phpmyadmin does that thingie on export? Where you can press control and select different tables?

I want it like that :D.
Once proud Documentation Writer and Help Squad Leader | Check out my new adult coloring career: Color With Jade/Patreon.

Arantor

That's how the interface would likely be (that's a select multiple).

The code is, unfortunately, somewhat uglier to do.

* Arantor adds it to his to-do list under 'merits definite further investigation'.

Jade Elizabeth

Doesnt phpBB do it? :P








I honestly have no idea, I'm just being silly
Once proud Documentation Writer and Help Squad Leader | Check out my new adult coloring career: Color With Jade/Patreon.

Arantor

Quote from: Jade Elizabeth on August 27, 2009, 04:26:30 PM
Doesnt phpBB do it? :P

I don't know but that's almost enough reason to contemplate it!

Jade Elizabeth

Quote from: Arantor on August 27, 2009, 04:31:17 PM
Quote from: Jade Elizabeth on August 27, 2009, 04:26:30 PM
Doesnt phpBB do it? :P

I don't know but that's almost enough reason to contemplate it!

I bet MyBB, and IPB, and ... *mental blank*... VB...and... other software do it :D.
Once proud Documentation Writer and Help Squad Leader | Check out my new adult coloring career: Color With Jade/Patreon.

Angelina Belle

For speed, you can put a static of the join in a third table. You have several rows per filename -- that's the way message_icons is now. At least all the rows for one filename can have the same icon_id. The only hit would occur in ManageSmileys.php, where you'd have to insert or delete from the new message_icon_boards (and sometimes insert or delete from message_icons), and then recreate the static message_icons_and_boards from the join of the two other tables.

Since the number number of times per second an admin is expected to be updating message icons and the boards they blong to is expected to be small, this should not be a big performance problem for the server.

Since it would be very unusual for these to be big tables, the duplication is not a big deal, space-wise, either.
Never attribute to malice that which is adequately explained by stupidity. -- Hanlon's Razor

Arantor

It's still a (yet one more) cross table join that would be being performed for many page loads, meaning that it will affect performance, even if the content is mostly static, plus the queries will have to be modified in multiple places, making it a large feature, or even a complex mod, to build.

That said it is doable, whether you relegate it to one or two new tables. It's on my to-do list and I'll look into it once I clear some of the other stuff I have first.

Angelina Belle

I think you can avoid any additional cross-table joins by saving the output of the join as a table immediately after updating the two message_icons tables, and using that "snapshot" (sorry -- Oracle term)  for filling $context['icons'] whenever it is needed. Of course, there will be additional logic to filling $context['icons'].

I bet it could be a bigger hassle tracking down every use of $context['icons'], and changing how it is filled and used.

Thanks for considering the request; I think it will be a good feature in some future version of SMF.

AB
Never attribute to malice that which is adequately explained by stupidity. -- Hanlon's Razor

Arantor

The problem with doing it is that it needs to be done in a way that is cross-DB compliant, meaning that you'd have to store that join output as a value in its own right, so perhaps forcing it into a single table somehow.

The list will be huge, yes... but it's on my list. I won't guarantee if/when I get to it, or whether the devs will put it into 2.1, but it's certainly food for thought.

Angelina Belle

Never attribute to malice that which is adequately explained by stupidity. -- Hanlon's Razor

Oldiesmann

Putting it into one table is easy. Just store the board IDs as a comma-separated list.
Michael Eshom
Christian Metal Fans

Jade Elizabeth

Quote from: Oldiesmann on August 27, 2009, 09:51:31 PM
Putting it into one table is easy. Just store the board IDs as a comma-separated list.

THAT'S TOTALLY WHAT I SAID TO HER IN PM!!

QuoteI still don't even see the need for all that. Just put the board id's they're allowed in into the table and check against the ID on POST, not on viewing.

I meant what you said, with the end of what I said, but didnt know how to say it :-[.
I'm sick, so my brain is REALLY not functioning :(
Once proud Documentation Writer and Help Squad Leader | Check out my new adult coloring career: Color With Jade/Patreon.

Angelina Belle

Quote from: Oldiesmann on August 27, 2009, 09:51:31 PM
Putting it into one table is easy. Just store the board IDs as a comma-separated list.
That is so not 3NF. But it would work. So "all" that is left is rewriting the code for
* using the icon_board array to make up the SQL insert statement
* unpacking the CSV list from icon_board field of message_icons into $context['icons'] -- which could have exactly the same form as it does now, to save rewriting in all the places where $context['icons'] is used.

AB
Never attribute to malice that which is adequately explained by stupidity. -- Hanlon's Razor

Arantor

Oldiesmann's suggestion is entirely consistent with several data structures in SMF - many things are comma separated lists (e.g user ignore list, user secondary groups...)

青山 素子

Quote from: AngelinaBelle on August 31, 2009, 03:20:39 PM
That is so not 3NF. But it would work.

While it would be nice if everything could be fully normalized, sometimes it just can't without a significant performance hit.
Motoko-chan
Director, Simple Machines

Note: Unless otherwise stated, my posts are not representative of any official position or opinion of Simple Machines.


Angelina Belle

Never attribute to malice that which is adequately explained by stupidity. -- Hanlon's Razor

Jade Elizabeth

* Jade Elizabeth is 100% lost with the last two replies
Once proud Documentation Writer and Help Squad Leader | Check out my new adult coloring career: Color With Jade/Patreon.

Angelina Belle

Database architecture -- third-normal form is almost an aesthetic ideal. It also offers the most flexibility for creating joins or views of the data for various purposes. When you want to mine very mulit-dimensional data, this is very useful.

Joins are resource intensive. If you don't NEED to slice and dice the data, you can pick a non-3NF "view" of the data for storage. Stuffing a list of attributes into a single field is very unaesthetic, but can be a good practical choice if it reduces the time to serve the page and/or load on the server(s).
Never attribute to malice that which is adequately explained by stupidity. -- Hanlon's Razor

Advertisement: