Building Shape's too often?

Topics: General
Feb 18, 2011 at 3:00 PM

Wouldn't it be better if the ContentPartDriverCoordinator, ContentFieldDriverCoordinator handlers didn't call BuildDisplayShape, BuildEditorShape, etc based on the placement?
Perhaps each driver should give back information about the shape name and based on that it can be analysed if the shape must be build or not.

Now the shape is always build and in the apply the location is searched.. if it's empty or "-" then the shape has been builded for nothing?
I might be wrong.. just trying to understand why..

Feb 18, 2011 at 7:56 PM

I'd say because that's the most flexible approach, but do you have any data that shows this to be a problem?

Feb 19, 2011 at 3:04 PM

In our own drives i think they do to much, each driver ask our pageflowmanager if should be rendered for the current pageflowstate. 

For prototypeing we builded like 40 drivers and because we are only storing the pageflow_id in the sessionstate each time the pageflowmanager has to ask the repository to execute a query. 
40 queries isn't an issue, 5000 queries will be... and we'll have 5000 drivers or even more.
Ofcourse i'll alter the pageflowmanager to cache using the clock service or something, so this won't be an issue.

Anyway being the most flexible approach, it can be the cause of several performance issues.
I don't see a reason to render a shape if it won't be visible at all :)

For now i don't have data of the orchard drivers.

Feb 20, 2011 at 5:07 PM

Even if Display() is called in the driver, it doesnùt mean some code needs to be run. You can embed your code into the lambda inside the ContentShape() call. Then it's only when the shape is actually displayed that this code will be run.