Schizophrenic detailviewdefs page

[n3fih]

I've inherited a project where my predecessor handled the situation where Accounts/listview displays different information for different types of accounts, by wrapping the declarations in a giant "if/then/else",
This has the problem of (1) breaking Studio, and (2) forcing us to run in debugging mode to prevent caching, since the cache 'freezes' the result on the first account type displayed.

My question: What is the "Right" way to handle this situation? Is there a mechanism in Sugar CE that can obtain the desired effect, w/out causing the side effects mentioned?

[Angel]

The "right" way is debatable as there are often many ways to accomplish the same. So long as the approach is upgrade safe, you are usually fine.

I've done something similar to what you are referring to, for which I would assume you have a custom view.detail.php. If you don't, then I am not sure how to help you as the view.detail.php approach would allow you to forcibly reset the cache every time, thus eliminating the problem.

Assuming you did it that way, insert this line of code before the line that begins with $this->dv->setup...

TemplateHandler::clearCache($this->module,'DetailView.tpl');

[n3fih]

That sounds like what I need, but if you mean modules\Accounts\views\view.detail.php, I do not see a line "$this->dv->setup...". I *do* see that line in /include\MVC\View\views\view.detail.php, but I suspectthat putting the line you recommend there would force the change on all templates, not just Accounts. Can you advise?

[agcopley]

I've inherited a project where my predecessor handled the situation where Accounts/listview displays different information for different types of accounts, by wrapping the declarations in a giant "if/then/else",
This has the problem of (1) breaking Studio, and (2) forcing us to run in debugging mode to prevent caching, since the cache 'freezes' the result on the first account type displayed.

My question: What is the "Right" way to handle this situation? Is there a mechanism in Sugar CE that can obtain the desired effect, w/out causing the side effects mentioned?

It depends how you do this, but generally you need to modify the TemplateHandler.php file to cope with different DetailView/EditView layouts...you can set a session variable in view.detail.php and the use this in modified TemplateHandler.php. Clearing the cache will not allow you to take advantage of the performance benefits, which are significant.

[Angel]

That sounds like what I need, but if you mean modules\Accounts\views\view.detail.php, I do not see a line "$this->dv->setup...". I *do* see that line in /include\MVC\View\views\view.detail.php, but I suspectthat putting the line you recommend there would force the change on all templates, not just Accounts. Can you advise?

Normally you would have made a custom version of view.detail.php under custom/modules/Accounts/views, which is just a clone of the one in the MVC directory, with your modifications. That's the version of the file you would want to modify.

Again, I am basing my comments off of how I did it. It may not necessary reflect what you have in place, but take a look at the directory I mention.

[stevec]

I'm having a similar design decision and this thread seems the most pertinent:

http://www.sugarcrm.com/forums/f148/...de-safe-47769/

As for the caching issue (I had similar using the 'devtoolkit' add-on) you can call the cache clear for particular modules in the custom view. For v6:

$modules = Array($this->bean->module_dir);
$RepairAndClear = new RepairAndClear();
$RepairAndClear->module_list = $modules;
$RepairAndClear->show_output = false;
$RepairAndClear->execute = true;
$RepairAndClear->clearTpls;

It would also be worth looking at the devtoolkit package to see if that can help:

SugarForge: Development Tool Kit: Project Info

http://www.sugarcrm.com/forums/f19/d...eleased-47031/

[Angel]

I think you are doing a full repair for the module in that case, which I would expect to take longer than simply clearing out the cache as it pertains to the view in question.

The line I reference in my prior reply does just that, clears out the cache file for the specific view one has customized, in this case DetailView.

[stevec]

More than one way to skin a cat Like you said

The "right" way is debatable as there are often many ways to accomplish the same.

The part of the code:

$RepairAndClear->clearTpls;

Just calls the the clear template code for the defined modules (in this case, the module you are working with).

[Angel]

Gotcha. That's part of what I was saying. It clears out more than it needs to. For example, in this case all we need to do is clear out the DetailView.tpl.

The only reason why I stress it is because if it clears out all the tpl every time the view is accessed, it is a performance hit, specially when compared to just clearing out the DetailView.tpl, which is already a performance hit on its own.

[stevec]

Aha - good point, it's clearing all the module's templates.