I guess the "NG" part in the sandbox name stands for "Next/New Generation"(?) It's pretty cool, but rather typical ;)

IMHO "Modules instant filter" suits it better (plural "Modules" instead of "Module" too) and "module_instantfilter" as a machine name. It distinctively states that it is a fork of Module filter that uses and depends on Instant filter.

All that of course only in case it doesn't make its way back to the "parent" Module filter project or as a submodule of Instant filter.

Comments

kiphaas7’s picture

kiphaas7 commented
Status: Active » Postponed

Right, so postponing for now :).

klonos’s picture

klonos
he/him
Primary language English
Location 90% Melbourne, Australia - 10% Larissa, Greece
commented

Status update: Some time has passed and the original project now has both a 7.x-1.x stable release and a 7.x-2.x branch with a dev. Back in #1023252: UI should utilize Drupal 7 core more - new 7.x-2.x branch? from where this sandbox's idea was born I asked the project maintainers for an official reply if they ever intent to merge your work back to the original project. I think that if there is no reply till the end of the month, it would be safe to conclude that this will likely never happen. If so, perhaps you should make this sandbox a full project then.

kiphaas7’s picture

kiphaas7 commented

It does indeed look like the maintainer did not want to bother to cooperate. No biggie, I intend to, when I have some free time, to do the following:

  • #1270220: Refactor code to use Instant filter new hooks
  • Move the checkboxes code to a submodule of Instant filter. Implement checkbox code for each Instant filter page where it might be beneficial.
  • Move the re-factored module filter NG code to Instant filter, in a submodule called 'instant module filter' or something like that. This is where the tabs, history hash, autocomplete and 'all' tab will live.
klonos’s picture

klonos
he/him
Primary language English
Location 90% Melbourne, Australia - 10% Larissa, Greece
commented

Great! Just let me know when you need help with testing.

As for moving this to a submodule of the instant_filter project... we already have the instant filter implemented in the modules page, the people page, the admin/config page and the content page and we are trying to get it in the permissions page too and wherever it might fit in the future (I was thinking the log messages page). So, -the way I see it- you have two options: either have separate submodules for them or whole separate projects. I think that submodules seem more appropriate so we can keep things in sync. Either way, people will have the option of enabling instant filter to only whichever admin page they wish, so we're good!

By having the checkboxes as a separate submodule, each page-filter submodule can hold different checkboxes implementations as required (or no checkboxes at all - like the admin/config page for example), but they can surely share the code behind it, so once again we're good!!

This looks very promising and I'm sure that at the end instant_filter (or some stripped-down version of it at least) will eventually get in core ;)

kiphaas7’s picture

kiphaas7 commented

If core would ever consider implementing this, the code needs to mature quite a bit.

But that is a big if since from what I can see it looks like they tend to look more for "Proudly found elsewhere" instead of yet another custom build javascript file.

klonos’s picture

klonos
he/him
Primary language English
Location 90% Melbourne, Australia - 10% Larissa, Greece
commented

I hear you. Still, this module has become as necessary to me as admin_menu.