Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Sections #398

Open
wants to merge 46 commits into
base: dev
Choose a base branch
from
Open

Sections #398

wants to merge 46 commits into from

Conversation

rsterbin
Copy link

@rsterbin rsterbin commented Dec 1, 2016

This is a new feature allowing you to add subqueries ("sections") with their own sets of filters.

Tests and existing plugins work, but not all features available to the root group are available for sections.

NB: I don't know MongoDB, so I've added an error if you try to use getRules and you have a section defined, but I hope that someone else can add that functionality.

Merge request checklist

  • I read the guidelines for contributing
  • I created my branch from dev and I am issuing the PR to dev
  • Unit tests are OK
  • If it's a new feature, I added the necessary unit tests
  • If it's a new language, I filled the __locale and __author fields

Reha Sterbin added 30 commits October 14, 2016 12:57
@mistic100
Copy link
Owner

WOW that's a lot of changes, it will take a while to review and test.

Awesome work BTW;

@mistic100 mistic100 added the feature New feature label Dec 1, 2016
@rsterbin
Copy link
Author

rsterbin commented Dec 1, 2016

Thanks! It looks like I'll need to add some more tests to get coverage up. Would you rather I hold off on that till you've had a chance to make a first pass review?

@mistic100
Copy link
Owner

Go ahead, I can't do it right away.

@@ -112,9 +124,15 @@ QueryBuilder.DEFAULTS = {
allow_empty: false,
conditions: ['AND', 'OR'],
default_condition: 'AND',
allow_sections: true,
has_sections: false,
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Shouldn't this be in this.prop ?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yep. Will move.

return !section.group.contains(node, true);
}
else {
return true;
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

not false ?

Copy link
Author

@rsterbin rsterbin Dec 5, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should be; will fix.

var self = this;

if (filters === undefined) {
if (Object.prototype.toString.call(delete_orphans) === '[object Array]') {
Copy link
Owner

@mistic100 mistic100 Dec 4, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Old js knowledge is old. Will fix.

* @param stypes {array}
* @return {string}
*/
QueryBuilder.prototype.getSectionTypeSelect = function(section, stypes) {
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can't find any usage of this method.

{
id: 'subquery-a',
label: 'Subquery A',
base_sql: 'SELECT a_id FROM section_a WHERE parent_id = 10 AND ',
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

not used

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Derp, forgot to remove that.

@mistic100
Copy link
Owner

General remarks :

  • I don't understand what is "stype", more over because the "getSectionTypeSelect" method is not used.
  • the "exist" keyword used everywhere does not seem adapted to me, in the sense that sections should not bounded to "exists" and "not exists" only, it should be called "section_type" or something like that.
  • although the feature is very powerful, I would prefer to ship it as a plugin and not integrated in the core. I know it would be a huge rework and I don't know if everything can be a moved in a plugin yet.

The main problem I think is that it currently only works with "EXISTS" and "NOT EXISTS", it would be great to make it work with any operand that supports a subquery (about every operand actually). But in order to make it work, the builder needs to be able to build select clauses (like asked here #310).
Your opinion ?

@rsterbin
Copy link
Author

rsterbin commented Dec 5, 2016

Section type (stype) is where you select which section you want to add. I'd initially called it "section_id" -- which makes more sense but collided with the internal section ID. I'm definitely open to calling it something else! (The function getSectionTypeSelect is called in core.js on line 706; were you talking about a different one?)

I like the idea of binding subqueries to different kinds of operators, and I'd be interested in doing that in the future, if there's a way to expand in that direction. I chose EXISTS/NOT-EXISTS because that's the shortest path to getting working sections -- my client has a lot of business logic that means I'm not really modeling the full subquery, just offering them a proxy of sorts to it and building the query from json later. Asking whether they want the section to be present or not is the only logical distinction they care about at this time. (Although now that you bring up the possibility, I could certainly see them asking for that functionality in the future.)

My first attempt at writing this was as a plugin, but I ran into trouble because it changes the group->rule structure. I do know a lot more about the code now than I did then, though, so let me think about it and see if I can't come up with a way to rework this as a plugin that spawns extra builders within a special rule. I'm somewhat concerned I won't have enough time to get that big a change done by the time my client needs it, but I'll see what I can do.

@rsterbin
Copy link
Author

rsterbin commented Dec 5, 2016

Quick update: I'm working on a little proof of concept using a plugin:
https://github.com/rsterbin/jQuery-QueryBuilder/tree/subquery-plugin

The main problem right now is finding a way to prevent the buttons within the subquery from triggering events in the base query. If I can find a workaround for it, I think a plugin solution is possible.

@mistic100
Copy link
Owner

e.stopPropagation() in every listener should work
https://github.com/mistic100/jQuery-QueryBuilder/blob/dev/src/core.js#L237

@rsterbin
Copy link
Author

rsterbin commented Dec 7, 2016

That did the trick. I'll push forward with the plugin and see if I can get it up to where this one is before I close it out.

@cheizer
Copy link

cheizer commented Jun 3, 2017

Hello, I was wondering what the status of this plugin was? I tried getting the source and running bower install in the project and was unable to get it to work. I'm kinda green when it comes to how to compile all of this so I'm not sure how to proceed.

Thanks!

@anthonyblond
Copy link

I'm also curious if this progressed further. Perhaps at another location?

@rsterbin
Copy link
Author

rsterbin commented Feb 5, 2018

Sorry, my client decided not to pursue this feature, so it's effectively abandoned. If anyone wants to pick it up, the most recent work is here -- https://github.com/rsterbin/jQuery-QueryBuilder/tree/subquery-plugin

@se
Copy link

se commented Nov 22, 2018

Do you guys think to add this feature?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature New feature
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants