diumenge, 26 de setembre del 2010

JAVA - Accés als membres d'una classe - Part II - package i private

Continuant amb els modificadors d'accessibilitat als membres d'una classe, ens restava per veure els nivells d'accés package i private.

Nivell package. Quan no s'especifíca un modificador d'accessibilitat a un membre, aquest només és accessible per altres subclasses dins el seu propi paquet de classes.Aquest nivell d'accés és més restrictiu que el protected.
Veiem-ne un exemple:


public class SuperClassA {

int superclassVarA;
void superclassMetodeA(){


...

}

}


En aquest exemple, la variable superclassVarA i el métode superclassMetodeA han estat declarats sense el modificador, per tant, només seràn accessibles dins del mateix paquet. Té restricció de paquet.

Nivell private. És el més restrictiu de tots els nivells d'accessibilitat. Els membres privats només són accessibles per altres membres de la mateixa classe.  Els membres amb modificador private no són heretats per la subclasse. En el següent exemple veiem que tant superclassVarA com superclassMetodeA tenen el nivell d'accés private, per tant, no són accessibles des de qualsevol lloc que no sigui la mateixa classe.


public class SuperClassA {

private int superclassVarA;
private void superclassMetodeA(){


...

}

}

dissabte, 4 de setembre del 2010

JAVA - Accés als membres d'una classe - Part I - public i protected

Una classe pot controlar l'accés als seus membres (métodes o atributs) per part d'altres classes.
És a dir, pot determinar quina informació és accessible i quina no ho és. Hi ha quatre nivells diferents d'accessibilitat:
  • public
  • protected
  • default (també anomenat package)
  • private         
Si no s'especifica cap nivell, el membre, per defecte,  té accessibilitat de paquet o default.

Nivell public. És el menys restrictiu de tots els nivells. Un membre públic és accessible des de qualsevol lloc, ja sigui des del mateix paquet que conté la classe o des d'altres on aquesta classe és visible.

Nivell protected. Un membre protected és accessible en totes les classes dins del mateix paquet i per totes les subclasses de la classe en qualsevol paquet des d'on sigui visible aquesta. És a dir, classes no heretades en altres paquets no poden accedir a membres protected.
Una subclasse en un altre paquet només pot accedir a membres protected de la superclasse a través de referències del seu propi tipus o subtipus. Veiem un exemple:


// fitxer SuperClasseA.java
public class SuperClasseA {      // En el paquet packageA

protected int variableClasseA;  // membre protegit
protected void metodeClasseA () { ...}  // membre protegit

}

// fitxer subClasseB.java
package packageB;
import packageA.*;

public class subClasseB extends SuperClasseA {   // En el paquet packageB

SuperClasseA objRefA = new SuperClasseA();
void subMetodeClasseB (subClasseB objRefB){

objRefB.metodeClasseA();   // OK
objRefB.variableClasseA = 15;  // OK
objRefA.metodeClasseA();             // NO OK
objRefA.variableClasseA = 20;      // NO OK

}
}


Un membre protected d'una superclasse només és accessible per una subclasse que estigui en un altre paquet, a través de l'herència.

dimarts, 3 d’agost del 2010

Facelets i JSF 2.0 - Creació d'un formulari - Part VII - Validació del formulari

Tal i com vàrem dir en l'anterior post , l'aplicatiu que estem dissenyant ha de poder validar o comprovar que l'usuari ha introduït correctament les dades en els camps del formulari. És a dir, cal un mecanisme que no permeti l'enviament del formulari fins que tots els camps (o almenys aquells que siguin expressament requerits) hagin estat omplerts i de forma correcte.
Hi ha diverses maneres de duu a terme aquesta tasca: podriem crear un métode en el nostre managed bean que, vinculat al camp corresponent del formulari, s'encarregués de comprovar i validar les dades que si han introduït. Per exemple, el típic camp que ens demana que introduïm una adreça de correu electrònic, hauria de tenir un métode que comprovés si realment hem escrit una adreça de correu (comprovar l'existència del símbol @).
En aquest cas hauriem de crear el que s'anomena un validador, una classe o bé un métode que compara les dades introduïdes amb un determinat patró.

D'altra banda, existeix un mecanisme molt senzill per comprovar que l'usuari no ha deixat cap camp en blanc i impedir que les dades del formulari siguin enviades i processades: la propietat required. Aquesta propietat forma part del conjunt de propietats que podem assignar a un component HTML d'entrada de dades com per exemple una caixa de text. Aquesta propietat accepta un valor de tipus booleà. Si el valor és true, es duu a terme la comprovació pel camp al qual hem assignat aquesta propietat. Quan l'usuari premi el botó d'enviament del formulari, si hi ha cap camp en blanc ens apareixerà un missatge avisant-nos de  que és necessari un valor per aquest camp. Un exemple podria ser el següent:

<h:inputText value="#{bean.nom}" id="nom" required ="true"/>
Una altra propietat que va unida amb la required és la requiredMessage i ens permet definir un missatge personalitzat que informi a l'usuari de l'error que s'ha produït.

<h:inputText value="#{bean.nom}" id="nom" required="true" requiredMessage="És necessari omplir aquest camp"/>

Resumint, per assegurar-nos que tots els camps han estat omplerts correctament, hauriem d'incloure la propietat required (establerta a true, obviament) a cadascun d'ells. En properes entrades aprofundirem una mica més en aquest aspecte i coneixerem altres formes de  validació.

Gràcies.

dijous, 15 de juliol del 2010

Facelets i JSF 2.0 - Creació d'un formulari - Part VI - Llenguatge EL

El llenguatge d'expressió unificat EL (Expression Language) permet als creadors de pàgines web utilitzar una senzilla sintaxi per accedir a les dades de forma dinàmica a través d'objectes JavaBeans És aquest llenguatge el que emprarem per vincular els camps html del nostre formulari amb les propietats o atributs del bean que vàrem crear en l'anterior post. JavaServer Faces utilitza el llenguatge EL per:
  • Evaluar de manera diferida o immediata les expressions EL.
  • Establir i/o obtenir dades.
  • Invocar métodes.
Resumint, EL proporciona una manera senzilla de llegir dades d'aplicacions emmagatzemades en objectes de tipus JavaBean. També permet l'escriptura, per exemple, de dades introduïdes per l'usuari a través d'un formulari , en un objecte JavaBean. Permet també l'execució de métodes invocats per esdeveniments. Per utilitzar el llenguatge EL hem d'escriure la sintaxi entre els símbols #{ d'inici i el símbol } de tancament. Veiem-ne un exemple:
En el següent codi (de l'arxiu inici.xhtml), el text introduït per  l'usuari en un camp de text serà emmagatzemat en la propietat corresponent de l'objecte JavaBean.

<h:inputText id="nom" value="#{bean.nom}">
Fixeu-vos que l'expressió EL l'escrivim dins l'atribut value del component. El primer paràmetre fa referència al nom del JavaBean i el segon, a la propietat nom (de tipus string) també del JavaBean.
Bé, doncs això hem de fer-ho per cadascun dels camps d'entrada de text del nostre formulari. Veiem una imatge amb el codi acabat.



Cada caixa de text (nom, cognoms, etc) té l'atribut value associat amb una propietat dins l'objecte JavaBean. 
Un altre detall molt important és l'atribut action del botó d'enviament del formulari. Vàrem dir que un botó pot tenir un atribut action i/o un atribut actionListener. Aquest últim l'emprarem per invocar métodes dins el JavaBean (ho veurem en properes entrades). L'atribut action l'utilitzarem per a navegar entre pàgines. En versions anteriors a JSF 2.0 calia declarar el que s'anomena regles de navegació  per a poder moure't entre diferents pàgines. En la versió actual això ja no és necessari (que no vol dir que no s'utilitzi). Amb JSF 2.0 existeix el que s'anomena navegació ímplicita, és a dir, JSF cerca una pàgina xhtml amb exactament el mateix nom que el definit en l'atribut action del botó (en aquest cas cercaria resultat.xhtml).
El que volem fer ara és mostrar les dades introduïdes per l'usuari en una nova pàgina. Per tant, crearem un nou arxiu de tipus Facelets Template Client que hereti de la plantilla original i li donarem el nom resultat.
Dins la secció content de la nova pàgina crearem una taula de dues columnes utilitzant el component panelGrid i mostrarem les dades entrades per l'usuari en l'atribut value del component outputText emprant el llenguatge EL. Per exemple:

 <h:outputText value="#{bean.nom}">

El codi de la pàgina resultat.xhtml quedaria així:


Bé, això podria ser un exemple senzill. Ara bé, calen certs retocs per a que esdevingui  un millor formulari. Per exemple, cal comprovar que l'usuari no es deixa cap camp en blanc o bé que el text introduït tingui una mínima longitud. Però això ho veurem un altre dia.

Gràcies.