search

lochmueller / calendarize

📆 Best TYPO3 Calendar ever 📆
http://typo3.org/extensions/repository/view/calendarize
75 stars 84 forks source link

Extending default constraints / limiting the found results #741

Closed akiessling closed 2 months ago

akiessling commented 1 year ago

Hi,

i'm toying around with the IndexRepositoryDefaultConstraintEvent and can't really seem to achieve what i was going for: limiting the found index entries with additional criteria.

  1. If the event returns index ids, they are set as a foreignUid constraint --> won't this conflict with multiple IndexTypes? If you e.g. use the built-in model and create your own, you can select them both in the flexform. But the foreignUid could match both of them?

  2. Depending on the amount of event records that match my criteria, you might run into other db problems or need to copy additional queries from calendarize to pre-filter the index ids.

Would it make sense to hand over the $constraints and $query to the listener? I already extended the index table and used the IndexPreUpdateEvent to copy over the fields so this would ease up the whole process a lot. The only other option i found would be to use the DetermineSearchEvent to filter the results, but then the heavy lifting of mapping all data is already over.

Setup: T3 10.4.36 calendarize 12.4.4

okmiim commented 1 year ago

Hi @akiessling,

regarding 1. your are right. I have an upcoming change ready in branch feature/category-conjunction-plugin

Yeah I can understand your problem. Concept wise it is not good practice to hand out $constraints and $query. I will try to think about that.

akiessling commented 1 year ago

Oh, i see. You can set the category filtering in the plugin configuration record? I added it to the flexform to keep everything in one place for the editors.

Concept wise it is not good practice to hand out $constraints and $query. I will try to think about that.

I don't have a solution for that at hand too :/

lochmueller commented 2 months ago

I close this issue. Feel free to suggest new events, if events are used. Related to the $query object. I also think we should not expose the $query object.