Hi all Can we have the discussion on the list instead of the issue ? This makes it a tad easier to follow and discuss.
My concern was: > Justin Edelson I share Alexander Klimetschek's concerns (and sorry for being > late to the party as well). Somehow this really smells very badly. It's like > exposing some implementation and machine details. It ties clients into > explicit implementations. Basically I allows for close coupling of clients > with post processor implementations. It think this is wrong. > Maybe I don't understand the use case fully (I just read the proposed > implementation). What problem does this solution try to solve ? Justin replied: > Felix Meschberger the use case is laid out in the issue description – a POST > request may depend upon the presence of one or more post processors. Actually, the issue description essentially justs says: I want to implement a new parameter to list required plugins. This describes the solution not the problem. Alex brings up the use case of encryption: > What if the sling post servlet understands the @suffix (in this case > @Encrypted) and detects if no post processor has handled it? That sounds like a good use case. And also I like the solution much better. Because it is inline with what already do for typing values with @TypeHint, and other features. Justin contends: > I'm trying to solve this problem in a generic way that can be reused across > multiple PostProcessors I ask: YAGNI ? So, if the problem really is that we want to ensure encryption is handled, we could indeed do that with the @Encrypt notation and thrown an error if the @Encrypt is not known. Regards Felix
