The question is how do you pass meta-information that the generic admin screen requires in an elegant way? I have a solution, but I don't love it. Better ideas appreciated . . .
I always pass an IBO (although you could pass a query) to my admin display list. But there is some information that isn't record specific. For instance, what is the name of the type of object I'm listing? What are the titles and the names of the properties I'm displaying, and what kind of things can I do to them (add, edit, delete, approve, send, publish, push-to-staging, implement, transform, import, export, etc.). The question is where that information should go.
For now I'm using the idea of "class properties". So, if you have a list of three products with a title and price for each one, you have three titles and three prices, but you also have a single PropertyNameList (Title,Price) and ObjectName (Product).
For now I've added a classGet() and classSet() method (including optional oMM support) so you can classGet("PropertyNameList") or classGetPropertyNameList() depending on your preference. I don't really like this approach, but I just dislike all the other approaches I've considered to date equally or more.
I don't particularly want to pass separate data and metadata beans, and I've thought seriously about having a metadata bean composed within the IBO so I could just Object.getMetadataBean().getPropertyNameList(). That seems marginally more elegant but I've not yet decided whether the marginal extra elegance warrants the extra complexity (it probably does, but I'm still a little on the fence).
Of course, I could just add the "class" properties to the regular properties and use a simple getPropertyNameList() that's smart enough to realize it's metadata, but then I run into the potential for naming conflicts in the general case - if I ever had an object that actually have a property called PropertyNameList I'd be SOL. I could also gen a separate list screen for each object, hard coding property name lists and the like. This is something I am seriously considering, although the amount of redundant display information seems a little un-DRY.
I could use some kind of strategy pattern for building up the displays, sharing common implementation details and then subclassing or composing different objects for the parts of the template that are object specific, but honestly objects can be a little inelegant as a solution for some kind of display templating problems and getting a sense of what an overall list screen looked like would require jumping between different CFC's.
So, how do you handle this when you want to add enough richness to your generic screens that they aren't just a scaffolding asset but are actually the final code while staying DRY and elegant? Any input appreciated!
Hmm, was just wondering if I should just use annotations on cfcomponent and maybe cfproperty tags and then use getMetadata() to access the annotations. Maybe that'd be a cleaner approach - what do you think? I'm starting to like the sound of that - anyone think of any downsides?