Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP

Loading…

Bug #49463 - Make templates customizable across Sugar. #68

Closed
wants to merge 1 commit into from

2 participants

@dkinzer

I was asked to move the button row for the advanced search form to be placed above the search fields. But this is not easily done with the current core code base because it does not look to see if there is a custom override.

This commit fixes this issue.


Update:
We've decided to apply a solution that addresses this problem across the core code base.

@jmertic

Hi David,

I really like this fix, as it handles a big area where you can't customize these templates at all in an upgrade-safe way. Before we pull this in, I would like to see it extended to all of the templates for the SearchForm area ( SearchFormGeneric.tpl, SearchFormAdvanced.tpl, header.tpl, footer.tpl ) and have the headerTpl and footerTpl templateMeta properties respected as well. Sound like something you could tackle?

Thanks again!

John

@dkinzer

Hi John,
I added the change across all SearchForm Templates as you requested.

Best regards,
David

@dkinzer

Oops. I think I missed the "headerTpl and footerTpl templateMeta properties". I'll resubmit this later tonight after I'm out of work.

@dkinzer

Actually, looking at the changes I already made, I'm not sure what else should be added. So I think this is done unless you see something I'm missing.

@jmertic jmertic commented on the diff
include/SearchForm/SearchForm2.php
@@ -101,7 +101,7 @@ function SearchForm($seed, $module, $action = 'index'){
function setup($searchdefs, $searchFields = array(), $tpl, $displayView = 'basic_search', $listViewDefs = array()){
$this->searchdefs = $searchdefs[$this->module];
- $this->tpl = $tpl;
+ $this->tpl = $this->getSearchFormTemplateByPath($tpl);;
@jmertic
jmertic added a note

I think this change would be better made in ViewList::prepareSearchForm() instead, where we are defining the template to use. This would make the code a bit more consistant with how things are done elsewhere.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
@jmertic

So check in include/EditView/EditView2.php around line 578-579. Right now in EditView and DetailView templates you can directly specify the tpl to use here, which is used in a few places like the Leads module. For consistancy, I think it would be great to have this same functionality.

That said, maybe having the ability to define the path to use for any of these templates via metadata would be the best way to go and provide the most flexibility. We should try and make the way of changing the templates as consistent as possible across Edit, Detail, List, and Search views ( List will probably be tricky because of the weird way the metadata is defined ).

I know I'm rambling with ideas here, so let me know your thoughts on all of this. I can help out with direction and unit tests if needed.

Thanks!

John

@dkinzer

OK, I'll give this a closer look. I do agree with you about consistency.

So are you suggesting a complete overhaul of how templates are called? Because doing a grep for ".tpl" on the project I noticed many places where a custom template is not looked for.

Also, I am assuming that when a template path is given via a metadata definition we still want to check against 'custom/' . $templatePathInMetaData?

@jmertic

I think it would be good to make it consistent. As you well know each area of the framework has it's own quirks for overriding things, and it would be great to clean this up. Since right now the only templates overridable for the Edit/Detail/Search/List views without adding a bunch of code is Edit/Detail view headers and footers, perhaps using this as a pattern is a good place to start.

Hey also, I see you are located on the US East Coast. Did you see the code sprint in Raleigh we are holding in February? You sound like just the kind of person that would be great to have there. Learn more at https://www.surveymonkey.com/s/SR7KXXJ.

@dkinzer

Thanks, I wish I could go, but I wont have the time to when it's happening.

@jmertic
@dkinzer

Yeah, I would love to be part of that sometime. Is there a way I could participate via the internet?

One of my biggest beefs right now is with SearchForm::populateFromRequest()
I would love to see that reconfigured into it's own class with readable sized functions.

So, it looks like I'll have time to work on this today. I hope to resubmit by sometime tonight.

@jmertic
@dkinzer

Sorry, this is not done yet. I got caught up in something else. Though I did hit a bit of a stumbling block. I stumbled onto

SugarTheme::getTemplate($templateName)

Now I'm wondering, should we just apply this function where it isn't being used?
I guess it still wouldn't work in cases where the template is being declared via a metaTemplate parameter in a metada definition.

@dkinzer dkinzer Make all Sugar templates customizable (Attempt 1):
Areas I skipped becuase it looks like the code is already taking care of the customization:

SugarFieldBase::findTemplate()
ViewSugarFieldCollection::display()
ViewSugarFieldCollection::findTemplate()
SugarFieldDownload::getDetailViewSmarty()
FormatterFactory::getInstance()
default_formatter::getDetailViewFormat()
default_formatter::fetchSmarty()
ConnectorUtils::CleanMetaDataFiles()
ConnectorUtils::updateMetaDataFiles()
Campains/WizardHome.php
EmailUI::getQuickCreateForm()?? - partial change.

Areas I skipped because I'm not sure what is going on (Mostly all cache stuff)

TemplateHandler::cleearCache()
TemplateHandler::buildTemplate()
TemplateHandler::checkTemplate()
TemplateHandler::displayTemplate()
TemplateHandler::deleteTemplate()
RepairAndClear::clearSmarty()
RepairAndClear::clearTpls()
ConfiguratorController::action_save_config()
ConfiguratorViewSugarpdfsettings::display()
TemplateRange::populateFromPost()
modules/import/Forms.php  function getControl()
?? ParseModifyListView::handleSave()
?? modules/upgrade_wizard/uw_utils.php  upgradeUWFile()
5c5b4d4
@jmertic

Let me circle this around some engineers here and get some feedback. It may be a bit of an overkill, but I'd like to get more eyes than mine on this.

I think we still need to figure out how to handle the headerTpl and footerTpl directives, since there are some use cases around that approach. But let's tackle what you proposed first and go from there.

Thanks again! This has certainly spun into something bigger than the first commit ;-).

@dkinzer

Yeah, that's a good idea. I hadn't realized Sugar had so many templates :)

For what it's worth, to me it seemed that the DynamicFields module does a pretty good job of handling this sort of thing.

I didn't touch any of the cache code, partly because I didn't have the time to study exactly how it works, and partly because my guess it that it will handle the change fine since some modules are already checking for a custom version of the template.

By the way, I'm wondering if it would be possible to apply my original patch to our on demand instance?

@dkinzer dkinzer closed this
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Commits on Jan 6, 2012
  1. @dkinzer

    Make all Sugar templates customizable (Attempt 1):

    dkinzer authored
    Areas I skipped becuase it looks like the code is already taking care of the customization:
    
    SugarFieldBase::findTemplate()
    ViewSugarFieldCollection::display()
    ViewSugarFieldCollection::findTemplate()
    SugarFieldDownload::getDetailViewSmarty()
    FormatterFactory::getInstance()
    default_formatter::getDetailViewFormat()
    default_formatter::fetchSmarty()
    ConnectorUtils::CleanMetaDataFiles()
    ConnectorUtils::updateMetaDataFiles()
    Campains/WizardHome.php
    EmailUI::getQuickCreateForm()?? - partial change.
    
    Areas I skipped because I'm not sure what is going on (Mostly all cache stuff)
    
    TemplateHandler::cleearCache()
    TemplateHandler::buildTemplate()
    TemplateHandler::checkTemplate()
    TemplateHandler::displayTemplate()
    TemplateHandler::deleteTemplate()
    RepairAndClear::clearSmarty()
    RepairAndClear::clearTpls()
    ConfiguratorController::action_save_config()
    ConfiguratorViewSugarpdfsettings::display()
    TemplateRange::populateFromPost()
    modules/import/Forms.php  function getControl()
    ?? ParseModifyListView::handleSave()
    ?? modules/upgrade_wizard/uw_utils.php  upgradeUWFile()
Something went wrong with that request. Please try again.