Closed ivank closed 6 years ago
You can create your own custom builder class to store state and custom queries in.
See this part of the guide: https://github.com/creatoro/jelly/blob/3.2/master/guide/jelly/extending-builder.md
Yeah I'm aware of this, but that way the behavior cannot be packaged and distributed on it's on. I was hoping for something more fundamental to allow behaviors to be more self-sufficient and perform more logic. If I did extend the builder class then I either have to write a new builder class for each model or extend Jelly_Builder directly - and then users of this behavior will not be able to do that themselves.
I think it would be best if we allowed reading the contents of the builder class from outside anyway - this way behaviors could be made to introspect the state of the builder and do a whole lot of additional stuff. Like
$builder->get('where')
or $builder->where()
to return the current where clauses
You have a good point. Behaviours might wish to store state on a per-model-instance or per-builder-instance basis, and there's no way of achieving that at the moment without extending the model or the builder.
Edit: storing the state in the behaviour instance is not an option as there's no way to tell when a model/builder instance has been garbage collected, so it would cause memory leakage.
I think it would be best if we allowed reading the contents of the builder class from outside anyway - this way behaviors could be made to introspect the state of the builder and do a whole lot of additional stuff.
Unfortunately Jelly just wraps the Kohana query builder, the jelly builder does not attempt to store the query state, so we're limited to what the Kohana query builder supports.
Well the model is not a problem as it has "unassigned" array for this, and we can implement something similar in the jelly builder as well. The question is are we at a point where we can try extending Jonathan's work or do you think it's best to only maintain for compatibility with kohana's releases? There are a lot of advanced things that are started and need to be completed ( this behavior thing, polymorphic, manytomany keeping old link rows) I'm working on a large project right now and could contribute to this a bit, but I don't want to create another fork of jelly as this has become the go-to version people are using. So it'll be better if you issued a pull request. What do you think about this?
I don't really have time to test or code for this project at the moment, but I'm sure @creatoro would accept pull requests.
There may be room for some sort of rewrite of Jelly; it has some really good design features, but I'm starting to see its limitations in some areas. @creatoro mentioned trying to modularise it a bit more in another issue thread.
@ivank: pull requests are certainly welcome. It would be nice to extend behavior features, it would be even better to have them seperated from the core in another module.
I'm trying to implement paranoid behavior and I have this problem - I've added an event listener for "builder.before_select" that adds an "is_deleted" where clause, but I have a builder_call_deleted() method that modifies that clause so you can do $builder->desleted("all")->select_all() to get all the records including the deleted ones. The problem is I cannot keep state between the method call and the event Jelly_Builder doesn't provide any arbitrary attributes for this, and I can't read if the builder has set a where for "is_deleted" or not.
So this would be solved if
Here's the current implementation (but it does not work) as I cannot set "_select_deleted" on the Jelly_Builder