En este post vamos a continuar desde dónde lo dejamos. En la última entrada en Español hablábamos de cómo crear una página visualforce utilizando únicamente un Controlador Standard. Si todavía no has tenido la oportunidad de leerla sería interesante que lo hicieras antes de continuar. Aquí tienes el link.
Controlador Personalizado
Hasta ahora sólo hemos usado el controlador Standard asociado al objeto que usábamos en la página, Account. Y con él hemos conseguido hacer muchas cosas. Entonces, ¿por qué necesito crear uno? Con este tipo de controladores vamos a extender la funcionalidad, de forma que nuestra página puede llegar a ser más potente si cabe.
Tenemos dos tipos de controladores personalizados:
- Asociados a una lista de registros de un objeto
- Asociados a un único registro de un objeto
Dejaremos la lista de registros para un blog futuro y hoy vamos a centrarnos en qué hacer con un único registro.
Único Registro
Estos controladores se usarán cuando quiero realizar una acción asociada a un registro en concreto.
Para empezar sólo tengo que crear una clase Apex
Setup | Develop | Apex Classes
Y hacer click en el botón New.
A continuación sólo tienes que escribir estas líneas de código y guardar:
public with sharing class AccountController
{
public AccountController(ApexPages.StandardController controller){}
}
Antes de continuar ¿qué podemos destacar del código anterior?
- Una clase puede ser:
- private: la clase es sólo conocida de forma local, es decir por el código de esa clase.
- public: la clase es visible en toda la aplicación.
- global: la clase es visible por cualquier código Apex en cualquier sitio, es decir, si empaquetamos la clase, ésta será visible y accesible para cualquier usuario que haya instalado el paquete. Mi recomendación por ahora es que tu clase sea pública de forma que así también puedes proteger la propiedad intelectual de tu clase si decides comercializarla en un futuro.
- With Sharing nos permite indicar permisos de acceso. Échale un vistazo a este blog en inglés de Andy Fawcett dónde explica el significado de estás palabras
- Palabra Controller en el nombre de la clase. Es una opción personal para saber que esa clase es un Controlador, pero si tu prefieres darle otro nombre, ¡adelante! sólo una recomendación. Mantén una misma convención en cuanto a nombres se refiere a lo largo de todo tu desarrollo, así que si creas otro controlador, dale un nombre similar
- Un constructor con un único argumento del tipo ApexPages.StandardController que proporciona una serie de métodos para poder recoger información del registro asociado a ese controlador
Una vez que tenemos el controller creado, vamos a asociarlo a una página. Por ejemplo, vamos a extender la funcionalidad de la página accountedit que creamos en el post anterior. Para ello sólo tenemos que añadir el atributo extensions a la definición de la página.
<apex:page standardController="Account" extensions="AccountController">
</apex:page>
Y ahora, ¿tenemos que hacer algún otro cambio? No en principio podemos mantener el mismo código en la página aunque lo asociemos a un controlador custom.
<!-- accountedit -->
<apex:page standardController="Account" extensions="AccountController">
<apex:form >
<apex:pageBlock title="Vista Cuenta">
<apex:pageBlockButtons >
<apex:commandButton action="{!save}" value="Save"/>
</apex:pageBlockButtons>
<apex:pageBlockSection title="Campos Cuenta">
<apex:inputField value="{!account.name}"/>
<apex:inputField value="{!account.site}"/>
<apex:inputField value="{!account.type}"/>
<apex:inputField value="{!account.accountNumber}"/>
</apex:pageBlockSection>
</apex:pageBlock>
</apex:form>
</apex:page>
Como ya aprendimos en el post anterior, si sobre escribimos el botón Edit del objeto Cuenta para mostrar nuestra página, el resultado será el siguiente:
Entonces, ¿cual es la diferencia?
Por ahora ninguna.
Pero vamos a seguir añadiendo funcionalidad. En la página view del anterior post, mostrábamos además una lista relacionada con las Oportunidades asociadas a la cuenta seleccionada. Vamos a hacer lo mismo en nuestra página pero esta vez vamos a usar el tag apex:BlockTable. Este tag tiene como atributo value que usaremos para llamar al método que nos devuelve la lista de registros sobre la que vamos a iterar en la tabla. Y el atributo var que será la variable que usaremos en cada iteración.
<apex:pageBlockTable title="Opportunities" value="{!opportunityList}" var="opp">
</apex:pageBlockTable>
¿Y qué es opportunityList? Ahí es cuando entra en acción nuestro nuevo controlador dónde tendremos un método que via una consulta a base de datos (en Salesforce se llaman SOQL) obtendremos la lista de Oportunidades asociadas a la cuenta Account1.
Una vez que tenga esta información, usaremos los métodos get / set que al final serán los que el atributo value llamará.
public with sharing class AccountController
{
private Id m_accountId;
private List<Opportunity> m_opportunities;
private ApexPages.StandardController m_controller;
public AccountController(ApexPages.StandardController controller)
{
m_controller = controller;
m_accountId = m_controller.getRecord().Id;
m_opportunities = calculateOpportunities(m_accountId);
}
public List<Opportunity> getOpportunityList()
{
return m_opportunities;
}
public void setOpportunityList(List<Opportunity> value)
{
m_opportunities = value;
}
private List<Opportunity> calculateOpportunities(Id accId)
{
//Remember Separation of Concerns
//Move to a Selector class
List<Opportunity> oppList = [Select Id, Name From Opportunity Where AccountId = :accId];
return oppList;
}
}
Cómo hemos mencionado antes del código, tenemos una variable privada m_opportunities que será utilizada por el get / set. Y si te fijas, estos métodos tienen el nombre que hemos usado en nuestra página visualforce.
Además, tenemos un método calculateOpportunities donde vamos a hacer la consulta a base de datos, la SOQL. Recuerda que aunque en este ejemplo estoy haciendo una SOQL en un controlador, debemos mantener el SOC. Para más información echa un vistazo aquí.
Y este método será llamado en el constructor del controlador y lo usaremos para modificar la variable privada m_opportunities de forma que una vez que se llame al controlador, la lista de Oportunidades se rellenará automáticamente.
Otra cosa a destacar, es el filtro de nuestra consulta. Buscamos las Oportunidades cuyo campo Account tenga el mismo valor que la cuenta que tengo en mi página. Si recuerdas, ya hemos comentado que StandardController ofrece muchos métodos, entre ellos getRecord() que nos devolverá el registro que estamos visualizando en el momento de llamar a nuestro controlador.
El último paso antes de visualizar el resultado, es añadir alguna columna a nuestra tabla. Por ahora sólo añadiremos el Nombre de la oportunidad.
<apex:pageBlock title="Related Lists">
<apex:pageBlockTable title="Opportunities" value="{!opportunityList}" var="opp" >
<apex:column headerValue="Name">
<apex:outputText value="{!opp.Name}"/>
</apex:column>
</apex:pageBlockTable>
</apex:pageBlock>
Sabiendo todo esto, ¿cual es el resultado?
¿Pero y si queremos añadir un campo que no está en el objeto Oportunidad y mostrarlo en la tabla? Por ejemplo, me gustaría visualizar un checkbox que me indicara si la Oportunidad tiene estado Closed Won.
Al ser un campo calculado, la lista que devolveremos no será directamente del tipo Oportunidad. Lo que vamos a hacer es crearnos una clase interna con dos variables, por un lado el registro de la oportunidad, y por otro este nuevo campo que vamos a calcular. Una vez que lo tengamos, la lista que usaremos en la página será del tipo de la clase interna.
Por otro lado, en el método que calcula las Oportunidades asociadas a la Cuenta, haremos los cálculos pertinentes para rellenar el nuevo campo que crearemos.
Así quedaría el controlador:
public with sharing class AccountController
{
private Id m_accountId;
private List<OpportunityInfo> m_opportunities;
private ApexPages.StandardController m_controller;
public AccountController(ApexPages.StandardController controller)
{
m_controller = controller;
m_accountId = controller.getRecord().Id;
m_opportunities = calculateOpportunities(m_accountId);
}
public List<OpportunityInfo> getOpportunityList()
{
return m_opportunities;
}
public void setOpportunityList(List<OpportunityInfo> value)
{
m_opportunities = value;
}
private List<OpportunityInfo> calculateOpportunities(Id accId)
{
Boolean isClosed;
OpportunityInfo oppInfo;
List<OpportunityInfo> oppInfoList = new List<OpportunityInfo>();
//Remember Separation of Concerns
//Move to a Selector class
for(Opportunity opp : [Select Id, Name,
StageName, Amount,
CloseDate
From Opportunity
Where AccountId = :accId])
{
isClosed = opp.StageName == 'Closed Won' ? true : false;
oppInfo = new OpportunityInfo(opp, isClosed);
oppInfoList.add(oppInfo);
}
return oppInfoList;
}
//Inner class
private class OpportunityInfo
{
public Opportunity OpportunityRecord {get; private set;}
public Boolean ToClose {get; set;}
private OpportunityInfo(Opportunity oppValue, Boolean toCloseValue)
{
OpportunityRecord = oppValue;
ToClose = toCloseValue;
}
}
}
Y en la página visualforce, la tabla tendrá que hacer uso de la clase interna
<apex:pageBlock title="Related Lists">
<apex:pageBlockTable title="Opportunities" value="{!opportunityList}" var="opp" >
<apex:column headerValue="Name">
<apex:outputField value="{!opp.OpportunityRecord.Name}"/>
</apex:column>
<apex:column headerValue="is Closed?">
<apex:inputCheckbox value="{!opp.ToClose}" disabled="{!opp.ToClose}"/>
</apex:column>
<apex:column headerValue="Stage">
<apex:outputField value="{!opp.OpportunityRecord.StageName}"/>
</apex:column>
<apex:column headerValue="Amount">
<apex:outputField value="{!opp.OpportunityRecord.Amount}"/>
</apex:column>
<apex:column headerValue="CloseDate">
<apex:outputField value="{!opp.OpportunityRecord.CloseDate}"/>
</apex:column>
</apex:pageBlockTable>
</apex:pageBlock>
Siendo el resultado:
En este ejemplo todos los campos de la tabla son de sólo lectura. El único que es input es el campo personalizado que hemos creado a partir de la clase interna. Pero si te fijas, en todos los registros el checkbox es de tipo lectura menos en el último en que el campo es de escritura porque el Stage no es Closed Won. Sin embargo el tag que hemos usado en todos los casos es apex:inputCheckbox. ¿Por qué no usamos output? Porque este tag sólo da la opción de escritura. Sin embargo ofrece un atributo para deshabilitarlo y es el que hemos usado, disabled.
Por último, nos podríamos preguntar por el botón Save. Si mantenemos en nuestra página visualforce la misma línea para el botón save que en el post anterior, la funcionalidad será la misma. Usará el controlador Standard para hacer la modificación en base de datos.
Sin embargo podemos modificar esa funcionalidad para extenderla. Para ello tendremos que crear un método en nuestro controlador dónde añadiremos la funcionalidad que necesitemos y devolveremos la página hacia donde quiero navegar después de la modificación. En nuestro caso la versión sólo lectura de nuestra cuenta.
public PageReference saveUpdates()
{
//TODO: Acciones para salvar
return new PageReference('/' + m_accountId);
}
Y hacer una llamada a ese método en nuestra página.
<apex:pageBlockButtons >
<apex:commandButton action="{!saveUpdates}" value="Save"/>
</apex:pageBlockButtons>
Como resumen, en esta entrada hemos aprendido:
- Cómo crear un controlador asociado a un único registro
- Cómo asociarlo a una visualforce
- Cómo mostrar campos en nuestra página visualforce
- Cómo crear un tabla con valores que vienen de base de datos
- Cómo añadir a la tabla un campo que no existe en base de datos
- Cómo modificar el botón Standard Save
Nos vemos en el próximo post.
Agustina odeian 