Poster taggade med ‘jsf’

Sida 1 av 212

Java Bean Validation (JSR 303) definierar en meta-data-modell och ett API för validering av klasser. Implementationer av denna specifikation gör det möjligt att definiera och utföra validering med hjälp av annotationer eller xml. Exemplet nedan illusterar detta för ett användarnamn:

@NotNull
@Size(min = 5, max = 20)
@Pattern(regexp = "[a-zA-Z0-9\\._-]+")
private String userName;

Bean Validation är inte knutet till något speciellt ramverk eller lager. Det finns däremot bra stöd för Bean Validation i flertalet populära ramverk, såsom Hibernate och JSF 2. Dessutom är det enkelt att utföra validering via API:t:

import javax.validation.ConstraintViolation;
import javax.validation.Validation;
import javax.validation.Validator;
import javax.validation.ValidatorFactory;
...
ValidatorFactory factory = Validation.buildDefaultValidatorFactory();
Validator validator = factory.getValidator();
Set<ConstraintViolation<Customer>> constraintViolations = validator.validate(customer);

För att komma igång med ett Bean Validation (Hibernate Validator 4.x är referensimplementationen) i ett Maven-projekt lägg till följande beroenden i din pom:

<dependency>
 <groupId>org.hibernate</groupId>
 <artifactId>hibernate-validator</artifactId>
 <version>4.2.0.Final</version>
</dependency>
<dependency>
 <groupId>org.slf4j</groupId>
 <artifactId>slf4j-jdk14</artifactId>
 <version>1.6.1</version>
</dependency>

Används Hibernate eller JSF 2 räcker det oftast med att lägga till ovanstående beroenden så länge de finns tillgängliga i applikationens class path. Används JSF 2 går det till exempel att aktivera validering för ett inmatningsfält på följande sätt:

<h:inputText value="#{customer.age}">
  <f:validateBean/>
</h:inputText>

Bean validation stödjer dessutom validering av grupper som gör det möjligt att validera olika aspekter av ett objekt:

@Min(value=15, groups=AgeCheck.class)
private int age;

Struts-gänget har tydligen skrivit om planerna för Struts framöver. Ett nytt underprojekt, ”Shale”, är öppnat, och befintliga Struts kallas numera ”Struts Classic”.

Kortfattat har jag fattat nyheten såhär:

  • Struts (Classic) går nu in i underhålls-läge. Inga stora förändringar är planerade och vidare arbete kommer bara att handla om felrättningar och liknande.
  • Som det verkar nu kommer Struts Classic därför aldrig att komma i en ”version 2.0″.
  • Shale är ett projekt med en helt ny kodbas, och med Java Server Faces som grund. Det är nog tänkt att det ska lösa samma typ av problem som Struts Classic, men med annat API och annat angreppssätt. (Det är förstås JSF-kopplingen som är den viktigaste aspekten här.)

Naturligtvis framkallar ett sådant här meddelande reaktioner, och i blogvärlden är det som vanligt inga problem att hitta negativa inlägg… (Exempelvis här.) Själv har jag väl ungefär de här tankarna i den här frågan:

  • Om Struts var ett kommersiellt projekt skulle det här aldrig hända! Tänk om Microsoft sa att ”Word är nu färdigt, och behöver inga fler funktioner. Vi kommer att fortsätta fixa alla buggar, men ni behöver inte köpa några fler uppgraderingar.” Yeah, right…
  • Det här är på något sätt ett fantastiskt tillfälle att bevisa att open source fungerar. Om Struts-projektet missbedömt behovet av en ny version av ”Struts Classic”, så kommer den att skapa sig själv. Struts användarskara är stor nog att underhålla och vidareutveckla produkten själva.
  • Själv tycker jag helt krasst att det är rätt beslut. Struts löser redan det problem som det designats för att lösa. Snarare har det flytit ut för mycket på sidorna och försöker lösa närliggande problem också, men det tycker jag är feltänkt. Bättre att lösa ett väldefinierat problem bra än att vara halvbra på lite av varje. Jag skulle inte ha något emot att använda ”Struts Classic” på ett problem där jag vet att det uppfyller kraven — även om det finns ett nyare projekt med ett annat angreppssätt. Och jag är inte orolig för att de projekt där jag redan använt Struts (”Classic”) ska plötsligt bli obsoleta och sluta fungera bara för att någon tycker att Struts är ”färdigt”.
  • Det roliga är att om det skulle visa sig att användarna av Struts verkligen skriker efter en ny version med någon nu okänd funktion, så kommer den att komma! Antingen som en open source-fork av Struts, eller (troligare) som ett kommersiellt tillägg. Det är ju just det som är det intressanta med open source: någon kan ta upp facklan om den tappas för tidigt.

Slutligen: med den lilla osäkerhet som finns nu med Struts (i alla fall på kort sikt) så känns det skönt att det finns gott om fullgoda alternativ, när man blir tvungen att välja. Jag tänker i första hand på Webwork och Spring, som är mina favoriter.

I denna avslutande del i min artikelserie beskriver jag det slutliga elddopet för mitt försök att implementera en design där persistensmekanismen kan bytas ut utan att klientkoden behöver skrivas om.

Ambitionen var att flytta persistenshantering till en J2EE-server och ge webappen tillgång till denna via en fasad i form av en sessionsböna. Servern jag valde var JBoss 4.0, en open-source server, flitigt använd av Javautvecklare och med en ökande marknadsandel.

Läs mer >>

Detta är del 2 i en artikelserie där jag beskriver hur jag tar min testapplikation ifrån min artikel
om Java Server Faces och bygger vidare på denna. I den första delen beskrev jag den grundläggande designen och hur jag fick enhetstestning och loggning att fungera.

I denna artikel går jag vidare och beskriver hur jag byter persistensmekanism från xml-fil till MySQL och Hibernate.

Läs mer >>

Sida 1 av 212