TimotheeJeannin / ProviGen

Easily make a ContentProvider from an annotated ContractClass.
MIT License
243 stars 27 forks source link

Allow Contract classes to make modifications to operations #33

Open keyboardr opened 10 years ago

keyboardr commented 10 years ago

Allow the Contract classes to specify classes to modify queries, deletes, inserts, and updates.

A primary use case for this would be to allow contract classes to do joins, subselects, group-bys, etc. without modifying the provider subclass (which would normally require copying over the full method).

I'll have a pull request to follow this up, but I wanted to get input on it while I'm working on it. So far my approach is to add a new Modifier annotation and four new interfaces (DeleteModifier, InsertModifier, QueryModifier, and UpdateModifier). Each of the new interfaces would have one method per relevant parameter (table, projection, selection, values, etc), and would take all of the original values as parameters. Contract uses instanceof in its constructor to determine which type of modifier is referenced by the annotation. ProviGenProvider then uses the modifiers when performing the relevant method.

TimotheeJeannin commented 10 years ago

Hi @keyboardr

I have the feeling that a fair of amount of users might need to modify the behavior of queries, deletes, inserts and updates. And ProviGen doesn't provide an easy documented way to do it. As you said the user needs to understand how ProviGen works and needs to copy over the full query / delete / insert /update methods to achieve this. So, we probably should do something about it.

Now, I don't know what's the best approach. On the first hand if we add a new Modifier annotation and new interfaces, I have the feeling that the user will need to understand where to put the annotation, what the annotations are doing, what are the implication on the queries etc. And I feel like it's might be a kind a usable 'black box', but that doesn't really put the user in control. If they want a specific behavior in the first place, maybe we should let them write a specific implementation. On the other hand if we don't modify ProviGen and just add documentation about "how to do it" it might be a bit cumbersome to copy over full methods.

I think we need to think about this a little bit more and consider all the options we have. What do you think ?

keyboardr commented 10 years ago

I've used ProviGen on several projects, and it's gotten to the point that I pull in the source even if I think my Provider will be simple. The nice thing about the Modifier approach is that it's 100% transparent to those who aren't using it while providing enough flexibility for the advanced users who are. My biggest concern is that I've only used this approach on one project, although it seems it would accomplish the goals of other projects I've had. I'll get my version up on GitHub so you can at least see it, but so far it's just a rough draft.

On Wed, Sep 10, 2014 at 12:37 AM, Timothée Jeannin <notifications@github.com

wrote:

Hi @keyboardr https://github.com/keyboardr

I have the feeling that a fair of amount of users might need to modify the behavior of queries, deletes, inserts and updates. And ProviGen doesn't provide an easy documented way to do it. As you said the user needs to understand how ProviGen works and needs to copy over the full query / delete / insert /update methods to achieve this. So, we probably should do something about it.

Now, I don't know what's the best approach. On the first hand if we add a new Modifier annotation and new interfaces, I have the feeling that the user will need to understand where to put the annotation, what the annotations are doing, what are the implication on the queries etc. And I feel like it's might be a kind a usable 'black box', but that doesn't really put the user in control. If they want a specific behavior in the first place, maybe we should let them write the a specific implementation. On the other hand if we don't modify ProviGen and just add documentation about "how to do it" it might be a bit cumbersome to copy over full methods.

What do you think ?

— Reply to this email directly or view it on GitHub https://github.com/TimotheeJeannin/ProviGen/issues/33#issuecomment-55080977 .

keyboardr commented 10 years ago

There's some whitespace and formatting issues, as well as some minor code cleanliness issues, but the core concept is here: https://github.com/keyboardr/ProviGen/commit/fc6478f78b325023f0c6b26014fff716c0142f2f

On Wed, Sep 10, 2014 at 4:35 AM, Josh Brown keyboardr@gmail.com wrote:

I've used ProviGen on several projects, and it's gotten to the point that I pull in the source even if I think my Provider will be simple. The nice thing about the Modifier approach is that it's 100% transparent to those who aren't using it while providing enough flexibility for the advanced users who are. My biggest concern is that I've only used this approach on one project, although it seems it would accomplish the goals of other projects I've had. I'll get my version up on GitHub so you can at least see it, but so far it's just a rough draft.

On Wed, Sep 10, 2014 at 12:37 AM, Timothée Jeannin < notifications@github.com> wrote:

Hi @keyboardr https://github.com/keyboardr

I have the feeling that a fair of amount of users might need to modify the behavior of queries, deletes, inserts and updates. And ProviGen doesn't provide an easy documented way to do it. As you said the user needs to understand how ProviGen works and needs to copy over the full query / delete / insert /update methods to achieve this. So, we probably should do something about it.

Now, I don't know what's the best approach. On the first hand if we add a new Modifier annotation and new interfaces, I have the feeling that the user will need to understand where to put the annotation, what the annotations are doing, what are the implication on the queries etc. And I feel like it's might be a kind a usable 'black box', but that doesn't really put the user in control. If they want a specific behavior in the first place, maybe we should let them write the a specific implementation. On the other hand if we don't modify ProviGen and just add documentation about "how to do it" it might be a bit cumbersome to copy over full methods.

What do you think ?

— Reply to this email directly or view it on GitHub https://github.com/TimotheeJeannin/ProviGen/issues/33#issuecomment-55080977 .