newz.dk - Programmering - JSF read-response og fejlbeskeder til brugeren

#37 - arne_v

arne_v — Tue, 31 Mar 2009 19:04:26 +0200

#36

Det er også bare et navn. Du kan sagtens bruge et generisk navn uafhængigt af klassen.

#36 - Windcape

Windcape — Tue, 31 Mar 2009 18:25:18 +0200

Oh, det var nok fordi at i dette her tilfælde tænkte jeg udelukkende på Managed Beans. Havde glemt at det også kunne benyttes til alm. sessions


	
		Authentication
		website.Authentication
		session

#35 - arne_v

arne_v — Tue, 31 Mar 2009 18:16:42 +0200

#34

Jeg er helt enig i at session.getAttribute(MyClass.class.getName()) er bedre end session.getAtttribute("mypackage.MyClass"), men hvorfor bruge klassenavnet ?

session.getAttribute("foobar") eller session.getAttribute(SesionKeys.FOOBAR) synes at give lidt mere fleksibilitet med hensyn til valg af et beskrivende navn fremfor at lægge sigt fast på et klasse navn.

#34 - Windcape

Windcape — Tue, 31 Mar 2009 17:56:21 +0200

Hvis jeg skal ændre et klassenavn. Så ville refractoring jo ikke opdatere værdien af en string, hvor imod hvis jeg benytter ClassName så ville det jo blive opdateret.

#33 - arne_v

arne_v — Tue, 31 Mar 2009 17:20:49 +0200

#32

Kan du forklare det lidt nærmere. Jeg er slet ikke med.

#32 - Windcape

Windcape — Tue, 31 Mar 2009 17:12:59 +0200

men jeg kan ikke rigtigt se nogen pointe i at bruge klasser som identifikation.arne_v (#31)

Refractoring ville umidbart være en god grund synes jeg.

#31 - arne_v

arne_v — Tue, 31 Mar 2009 17:03:36 +0200

#30

.setAttribute(Object key, Object value) og .getAttribute(Object key) vil tillade brug af mutable keys, hvilket kan gå grueligt galt.

.setAttribute(Class key, Object value) og .getAttribute(Class key) vil ikke tillade mutable keys, men jeg kan ikke rigtigt se nogen pointe i at bruge klasser som identifikation.

#30 - Windcape

Windcape — Tue, 31 Mar 2009 16:49:01 +0200

Men man undgår problemer med mutable keys på den måde.arne_v (#29)

Af ren og skær interesse, hvordan kan man lave en muteable key, hvis keys er en stærk type (MyClass.class i java).

Så vidt jeg kan se kan den kun ændre sig hvis man ændre navnet på klassen, hvilket jo alligevel vil kræve at man ændre sin string key.

Eller er det for at undgå 2 klasser med samme navn, i forskellige packages? Så at hvis man havde brugt en forkert (autoimports og typo's sker jo), så ville ens refractoring opdatere navnet forkert?

Eller noget helt tredje? :)

#29 - arne_v

arne_v — Tue, 31 Mar 2009 16:42:27 +0200

#27

Alle standard objekterne: application, session, request etc. bruger String som key.

Det er en restriktion. Men man undgår problemer med mutable keys på den måde.

#28 - arne_v

arne_v — Tue, 31 Mar 2009 16:36:05 +0200

#25

Det er korrekt at en ændring kræver en reload af app. Sådan er det bare.

Man låser sig ikke til en bestemt container. Syntaxen i web.xml (og kaldene i servlet API hvis man vil mixe den declarative security med lidt programmatic security) er helt standard, så din web app vil virke uændret i alle containere.

Opsætningen af bruger og rolle "databasen" er container specifik.

Tomcat kommer f.eks. med backends til:
- database via JDBC
- database via DataSource via JNDI
- LDAP via JNDI
- XML file
- JAAS
og derudover er det ret nemt at lave sin egen backend (nem som i 50 linier kode).

JBoss understøtter:
- properties file
- LDAP
- database
- certifikater
og det er også relativt nemt at lave sin egen.