I’ve started doing some R&D with region plugins, one of the things I like is that we can define the “Region Source” as a SQL statement and set the minimum and maximum columns allowed. This means that we get builtin SQL statement parsing to make sure our queries are syntactically correct when we define our plugin query source, which is really nice. We can even show query examples so we the developer know what query structure is required when defining them.

Now on initial investigation one might think that you can have only one query associated with a plugin, and by definition that’s true, but have you considered creating a plugin that’s actually made up of say 5 plugin definitions? i.e. we have one parent plugin and 4 child plugins which work together to produce 1 result. Why would we want to do this? Consider a menu bar, we may want each menu e.g. “File”, “Edit”, “View” etc. to be defined from separate SQL queries. Since we only have one query definition that we can define per plugin, why don’t we just create one master plugin with X many child plugins. The child plugins will be stripped down, i.e. all they do is just define our query sources and with the option of setting a template to define what sort of component it is. We then use the APEX data dictionary within our parent plugin to locate the direct children during the rendering phase, execute them and use the results.

This approach can give us greater flexibility and visibility of our plugin definition as it’s visible and editable through the APEX IDE with a visual tree structure, thus ensuring we have less code and object maintenance on the backend. Potential other uses for a plugin with multiple query definitions could be grids within grids within grids. Anyway it’s early days for me I’m just tinkering around seeing what the possibilities could be. As I stated in an earlier post my favourite feature is the new parent/child setting for regions, it’s opened Pandora’s box in my eyes