Logic Behind Structure of Processors

I’m looking into fixing issue #15223, which can be easily solved on the surface (i.e., making some adjustments to the create form’s javascript) but should also be addressed in the processor. After looking more closely at the processors for lexicons (and a quick peek at some of the others), I have a question (not a rhetorical one): Why are the Create and Update type processors totally separated (as opposed to Update extending Create)?

With the specific issue I’m tackling, I can see that there’s literally no preparation or validation of the data being passed (aside from an alreadyExists routine). Because of the structure, other validation would need to be added in two places (Create and UpdateFromGrid), which seems a little non-OOP. Granted, I may be missing the bigger picture, which is why I’m asking :wink:.

I’m gonna go out on a limb here and say that’s just how it was decided to structure things a decade ago. Each action nicely encapsulated, with the type of object provided as a property. For a lot of cases it’s very easy to use and OOP, but indeed doesn’t help with shared validation in create and update actions.

IIRC the user processors have an include (maybe that was changed to a trait in 3.x) for shared validation. When it gets more complex than just marking required fields I can imagine that being useful.

These days people are more used to the RESTful paradigm and a resource based approach would be more natural to developers. Other than backwards compatibility (public processor methods are considered part of the api), I see no reason why a Update extends Create approach wouldn’t be feasible within the current system. There is some boilerplate related to events in each of the Create/Update processors, but that wouldn’t be too hard to sort out in a new class.

Thanks for your insights. I don’t know that this is something I’d want to tackle immediately, but wanted to get a sense of whether there was flexibility in how the processors are structured. I like to avoid duplicate or overly similar code living in more than one place, and do see some opportunities to optimize by pursuing the Update extends Create route.

1 Like