Pros/Cons in using Resource class vs *Record classes
I'm curious what the best practices are around, for example, using form() in ThingResource::form versus CreateRecord::form? (also, table(), etc...)
My ASSUMPTION is that when you have a relatively simple application you can just leave everything in the Resource class, but if your application is more complex, you can break it out into Pages for easier management. Is that correct?
Which leads to a second opinion question: If I use the *Record classes one resource (versus the monolithic Resource class aproach), should I do that for all resources to maintain consistency?
Solution:Jump to solution
I would stick to the resource class unless your create and edit forms are that drastically different. Keeps from having to repeat the fields.
Most of the field modifiers accept callback functions which get the create or edit $operation injected so if it’s only like one or 2 fields you can manage it in the resource class.
For example:...
3 Replies
Solution
I would stick to the resource class unless your create and edit forms are that drastically different. Keeps from having to repeat the fields.
Most of the field modifiers accept callback functions which get the create or edit $operation injected so if it’s only like one or 2 fields you can manage it in the resource class.
For example:
That makes sense. I have a situation for one of my resources where I want a Wizard to create, but when you edit I want a normal form. I think that's a good candidate for breaking them apart - but maybe just in that case. I appreciate the advice!
Yea, that would be a valid use case for splitting them up. You’ll have some duplication, but I think that’s ok for this use case since it’s not a global thing.
I certainly wouldn’t split the all up though. Don’t think consistency should be the focus for this one.