Driver still executed while shape hidden in placement

Topics: General, Troubleshooting, Writing modules
Dec 23, 2011 at 8:15 AM

Is it a normal behavior that when the shape is made hidden by placement that the Display method of the driver of that shape is loaded/accessed?

I have the problem with the image gallery module. I have a list with items which only needs a image gallery in displaytype Summary but not in Detail.


Dec 24, 2011 at 5:54 AM

The shape is created by the display method of the driver. the driver is not "of that shape": the driver is associated to a part, not a shape. The shape is the output of the driver. Placement acts on shapes, not parts, so yes, the driver has to run for there to be shapes that placement can act on.

Your driver can look at the display type and return null if it wants to return no shape.

Dec 24, 2011 at 6:22 AM

A thanks for your explanation. Isn't it possible (maybe a feature proposal) to make it possible do this kinds of things like a sort of placement file. This because i have to change all kinds of module drivers to return null (for performance improvements). When there a module updates these changes will be overridden. It would be nice if you can make such a file in your theme. I'm interested what's you idea about this.

Dec 24, 2011 at 6:23 AM

Do you have any evidence that this is affecting performance?

Dec 24, 2011 at 7:31 AM

An example: I have a list which show 10 items at a time (paging) those items each have the image gallery part and show a gallery in a few different display types like detail. I've made that gallery part hidden in the summary view and it doesn't show it (the correct behavior) problem is that the driver of the gallery part is still accessed and builds everything for it's part. So in this situation it's affecting the performance. When i check for display types like "detail" and return null, the performance is not affected but i have to do this for all module parts which are included in the contentitem. So when later on i install a few module updates because they improved the module performance for example, my custom display type checks are overridden and gone.

Maybe that's simply the problem of updating modules from the gallery but i think it's nicer to define in the theme which part are being accessed for a certain content type and display type.

Dec 24, 2011 at 7:34 AM

I don't believe you :) What I'm trying to say is sure it affects performance in a tiny, insignificant way that nobody should care about. Unless you prove otherwise. Before you fix a performance problem you always show first that there is a performance problem. Anything else is premature optimization.

Dec 24, 2011 at 7:45 AM
Edited Dec 24, 2011 at 7:46 AM

Well in the example i used the image gallery's and when the content items has a lost of images and it's build up for 10 items at once (list and paging on 10 items) it's quiet a unnecessary performance impact (and extra sql queries) i think. Also when you using different tenants and you use the same module you can get in problems when using for example that image gallery:

tenant 1: show gallery in summary mode

tenant 2: hide gallery in summary mode.

once again you can use placement to do this but you can't use the return null in that module.

next week i'm gonna try to show you some evidence lol :)

Dec 24, 2011 at 8:33 AM

Again, you don't know that. Bring it on.

Dec 24, 2011 at 12:22 PM

Every processing a driver method returning a shape does should happen in the shape's factory method. This is a very clever approach that Pete taught me in this discussion (there are also additional tips regarding placement and drivers, worth reading). This way can indeed suppress any processing happening, not just the shape's display. The driver method will still be called but that practically does not impact performance.