Search articles in group_orders form

[JuliusR]

See #143 for previous discussion.

This adds the possibility to filter articles by name when ordering. The plugin list.js was used which had to be modified to not break the form submission.

Further work has to be done when the filtering shall be combined with sorting functionality because the list.js has its own sort logic. Ordering of DOM objects outside of list.js will be overwritten by list.js. That should be addressed in a separate issue if needed.

[wvengen]

Nice! There is one more thing I see that may bother users: category names are always visible. It would be most helpful to show just those categories that have matching articles; or else hide them all if a search term is active. Does that make sense? (If it exceeds the effort you'd wanted to put in, that's ok, we can add that later too)

[JuliusR]

There is one more thing I see that may bother users: category names are always visible.

Yeah, this I did by purpose (see 6ec81ac) so that the ordering of articles makes sense (grouped by category and ordered by name).

It would be most helpful to show just those categories that have matching articles

I agree that this would be the most favorable solution. However, I do not see a simple solution that is easy to understand (concerning code readability). What I thought about is using an Adjacent Sibling Selector. I will try it in another branch first and then we can discuss about the gain and readability.

or else hide them all if a search term is active

This I disklike because the ordering could confuse users.

[JuliusR]

OK with pure CSS I did not find a way. How do you like the style in the new branch?

After all, it is some more code for a slightly better user experience but I think this is fine here because the new functionality is not entangled with the main application. This means that it would not do any harm to remove or replace it at some point.

[wvengen]

Congratulations for the smart categories branch, it feels quite nice.

Regarding subclassing listjs, that would be great - I'll have a quick look to see if I can come up with something. That would also allow us to use rails-assets-listjs. If not, let's merge your new branch.

[JuliusR]

That would also allow us to use rails-assets-listjs

I did not modify the original code, so in principle it should already be possible. However, an update of the gem could break compatibility of the modifications.

I will look deeply into it if you have a suggestion.

[wvengen]

Ok, this also seems to work; it's not fully polished, but I'd like to call it a day.

Please make sure you have at least revision 4.

[JuliusR]

Thanks for your superClass example. In fact, I was pointing at list.customized.js, but your suggestion also helped to reduce the code additions. Regarding local variables, I only found this hint by the original author when writing a plugin: http://jonnystromberg.com/listjs-plugins-guide. I guess it does not help for our case of writing a template engine.

What do you think about the current code now?

[wvengen]

Looks ok, great! Now we can use a listjs gem, right (with a commented line in the Gemfile that on updates list.*.js may need updates too)? I've been fiddling of creating a listjs plugin for delay (and one for the headings?) but didn't get there yet. Would be nice, but certainly not a must :)
Good job man.

[JuliusR]

Should the symbol be defined in the locales? I do not think so, but there are other examples in the locales (see e.g. ui.marks.close)

[wvengen]

Awesome! I think the bootstrap icon is customisable enough (if different
icons are needed for a language, I don't think changing the font would
be a bad thing to do).

p.s. why not adding the close mark in the reset plugin (from an option
with a sensible default); that way enabling/disabling the plugin would
just work without extra html.
p.p.s. something tiny: any reason for setting plugin options at
invocation, whhen they're already the default?

[JuliusR]

why not adding the close mark in the reset plugin

Yeah, I thought about that. Finally I prefer the current style because it is highly customizable and it is obvious how it works. Moreover, the controls are already present while the page is still loading so that the page appearance does not alter after initialization.

something tiny: any reason for setting plugin options at invocation, whhen they're already the default?

I tested if it is possible to specify alternating options. After that, I decided to leave one option per plugin so that the purpose of the [] syntax becomes clear.

[JuliusR]

I am completely satisfied now. If you are too let us briefly decide the locale issue (see my last commitcomment) and then perform the final manual tests.