Tudo sobre WebResources II

by Pedro Azevedo 25. June 2013 22:07

 Boas pessoal,

Vamos continuar o exemplo anterior e vamos tentar complicar um pouco para percebermos como tirar o maior partido desta funcionalidade.

Vamos então perceber como podemos referenciar um WebResource directamente. Agora quero colocar “OLA Nome do Cliente Potencial”. Para isso vou usar jQuery então adicionei a biblioteca do jQuery a solução através de um WebResource e adicionei o seguinte código:

$(document).ready(function() {
  var nomeCompleto = window.parent.Xrm.Page.getAttribute("fullname").getValue();
  $('#sayHello').append(nomeCompleto);
});

Se voltar abrir um Cliente Potencial vai dar o erro seguinte:

Isto porque mesmo tendo na solução um WebResource com a biblioteca jQuery, o CRM não vai carregar, por essa razão vamos ter que adicionar uma referência ao WebResource que tem a biblioteca jQuery, desta maneira:

<SCRIPT type=text/javascript src="ret_jquery"></SCRIPT>

Gravando, publicando e abrindo novamente o registo temos este resultado:

 

Este tipo de referenciação funciona se tivermos numa estrutura flat. Se tivermos os WebResources em pastas teremos que nos posicionar. Imaginemos que o WebResource ret_testewr estava em html/ret_testewr e que a biblioteca jQuery estava em scripts/ret_jquery, então teríamos que referenciar da seguinte maneira:

<SCRIPT type=text/javascript src="../scripts/ret_jquery"></SCRIPT>

Aqui estamos a usar um URL relativo e é assim que devemos usar, outra maneira era referenciarmos o WebResource da seguinte maneira:

<SCRIPT type=text/javascript src="http://<server>/<organization>/webresources/ret_jquery"></SCRIPT>

Colocar todo o caminho vai funcionar e muitas das vezes é o URL que eu coloco no browser para testar. Mas isto é muito mau, basta dizer que você não vai conseguir passar esse código para outro ambiente de desenvolvimento, sem ir alterar o código, o que é mau, por isso devemos sempre usar o URL relativo. Já para não falar se tivermos os dois tipos de deploy (online e on-premise) que o URL muda completamente.

Uma pergunta válida é o porquê de querermos estruturar os WebResources na forma de pastas. Não é uma obrigação mas sim uma boa prática, principalmente se um utilizador pertencer a mais que uma organização num servidor. Isto porque quando colocamos /WebResources/<nome web resource> ele vai aceder a organização por defeito do utilizador. Isto poderá gerar um erro do tipo “File Not Found” caso ele esteja aceder a uma organização que não a de por defeito e que esse WebResource não exista na organização por defeito. Então como boa prática deveria-se ter a a seguinte estrutura:

“_<prefixo da organização>”/<nome da pasta>/<nome do Recurso Web>

Já vimos que conseguimos aceder ao formulário então e como conseguimos aceder a coisas do CRM fora do formulário, por exemplo saber o nome da organização, para isso usamos a seguinte função:

Xrm.Page.context.getOrgUniqueName()

Se executarmos este código obtemos o seguinte erro:

 

Mas em cima colocamos o prefixo window.parent mesmo pondo este prefixo não funciona porque ele serve para aceder ao formulário. Para que isto funcione necessitamos de referenciar uma outra biblioteca (não esquecer que estou numa estrutura flat de WebResources, se este WebResource tivesse dentro de uma pasta teria que reposicionar):

 

<SCRIPT src="ClientGlobalContext.js.aspx"></SCRIPT>

 

Esta biblioteca permite acedermos a outros parâmetros, vejam aqui a lista:

  •     getAuthenticationHeader

Cabeçalho de autenticação SOAP para os WebServices do Dynamics CRM 4.0.

  •     getOrgLcid

Retorna o valor LCID da linguagem de base da organização.

  •     getOrgUniqueName

Retorna o nome da organização.

  •    getQueryStringParameters

Retorna um array de chave valor representando os argumentos em query string passados a página.

  •   getServerUrl

Retorna o URL base do servidor. Quando se está no modo offline ele retorna localhost.

  •   getUserId

Retorna o Guid do utilizador actual.

  •    getUserLcid

Retorna o valor LCID da linguagem seleccionada pelo utilizador.

  •   getUserRoles

Retorna um array de Guid que representam as roles associadas ao utilizador.

 Existe outra forma de referenciar WebResources através da directiva “$webresource:<Nome do WebResource>”, devemos usar sempre este tipo de referenciação, pois ele resolve as dependências de solução. Mas apenas podemos usar quando estamos a usar o SiteMap ou Ribbon. A questão das dependências é muito importante porque ele vai conseguir gerar o URL e com isso vai possibilitar haver cache do WebResource, vejam o URL para referenciar o WebResource:

/<organização>/%7B635318792490000000%7D/WebResources/ret_testewr

Se colocarmos um URL absoluto para além dos problemas anteriores ainda vamos perder a capacidade de fazer cache. Existe um artigo muito bom e que explica também como podemos gerar este URL.

Em relação a como aplicamos a directiva na prática vamos ver mais detalhes no próximo post.

 

Até a próxima

 

Fontes:

http://msdn.microsoft.com/en-us/library/gg328541.aspx

Tags: , , ,

Comments (1) -

Clayton Ancira
Clayton Ancira United States
7/5/2016 3:30:28 AM #

I like the valuable info you supply on your articles. I¡¯ll bookmark your blog and check again right here regularly. I am quite sure I will be informed many new stuff proper here! Good luck for the following!

Reply

Add comment

  Country flag

biuquote
  • Comment
  • Preview
Loading

About

Muito bem casado, Pai babado e um gosto muito grande pela tecnologia.

Tenho um lema "Sharing is Learning"

Mais aqui -> http://www.psazevedo.com

Month List