Configuration to set ignored classes for defaultControl/Presenter resolvers

[MartinMystikJonas]

No description provided.

[MartinMystikJonas]

I just stubled upon need for this while writing custom resolvers. SO I will implement it. Whad do you think a out this format

latte:
    customResolve:
        - App/Components/BaseControl

Alternative names: customResolveClasses, skipDefaultResolve, skipDefaultResolveClasses, excludeDefaultResolve, excludeDefaultResolveClasses.

Any better idea?

[lulco]

I think we should somehow create priorities for resolvers and each class should be resolved with only one resolver (as it was before). So all your custom resolvers will run first and then our default at the end (I think presenters first then controls). What do you think?

[MartinMystikJonas]

You can have multiple resolvers matching single class. As we already have one for presenter actions and another for presenter standalone templates. Similar to it I have custom resolver written for standalone control templates (our base control have default template file mechanism) but I also want to use default control resolver.

[MartinMystikJonas]

Maybe make resolver-template pair unique? But I am not sure how well it would work in other use cases

[MartinMystikJonas]

Or maybe make it part of resolver interface? So resolver can say whether other resolvers should try to resolve this class/node or if resolving is finished.

[MartinMystikJonas]

Or maybe another way. Resolver can implement method that allow it to can say it is authoritative for given classes. If resolver is authoritative then it replaces default resolvers.

[lulco]

I don’t know really :) I have to try it on some of our projects where it will be needed. Just don’t have enough time for it now.

maybe something like:

latte:
    resolvers:
        exclude:
            ResolverClassName: # classname of resolver to setup
                - ClassName::methodName # exact method from class
                - ClassName2::* # all methods from class
                - ClassName3::somePattern* # methods with name matching pattern

[MartinMystikJonas]

Like the idea of configuration per resolver. Also this could be a way to register resolvers. Not directly as services but as configuration that would be handled by some ResolversRegistry. It would aslo simplify adding resolvers. When used as service it has to be added by CLI option - - autoload-file. This was it could be added by config parameter bootstrapFiles I think.

[lulco]

I felt into this issue today, but I don’t need it at the end.

I have so called "plugins" in my apps. They are extended Controls with specialized method templatePath() which returns string - path to latte template.

First I've create whole new resolver but then these plugins were processed twice. Then I realize I need only PathCollector.

Same thing happens to me with components. All “global plugins” are components of each other plugin. Solved with custom ComponentsCollector.

So for now I solved everything with custom collectors.

If I will have some classes which are not resolved with built-in resolvers I'll create new one. It means there should not be any conflict. Each class will be resolved by one resolver.