[rd_jsfsquad] Re: Bemerkingen extval-poc

  • From: Steve Schols <steve.schols@xxxxxxxxx>
  • To: rd_jsfsquad@xxxxxxxxxxxxx
  • Date: Wed, 17 Feb 2010 13:00:53 +0100

Thx Sander :-)

Ik zal er morgenavond eens naar kijken.

Vanuit de JSP/JSF files is het geen enkel probleem om de messages op te
roepen ... maar kan ik dergelijke EL expressie ook gewoon vanuit code
oproepen, zoals vanuit een ActionListener? En zonder te moeten verwijzen
naar de ResourceBundle of deze te moeten gaan ophalen?

Damn ... die managed-bean site ben ik vandaag gepasseerd, en dat was de
tabel die ik zocht, maar gewoon overgekeken.
Een session scoped PersonListBean zal ik dus niet via managed-property
kunnen injecteren in een request scoped PersonBean, en volgens e-mail van
Rudy kan dat opgelost worden via EL ... maar ik zou niet onmiddellijk weten
hoe.
Ik zoek dit nog verder uit.

Thx.

Op 17 februari 2010 11:49 schreef Sander De Vos
<de.vos.sander@xxxxxxxxx>het volgende:

> Steve,
>
> In bijlaage de classes die ik gebruik om resourcebundles aan te spreken. Ik
> kan  bundles aanspreken via een EL-expressie:
> #{I18n.messages['action.course.view']}. Dit is wel spring specifiek dat ik
> de messageFactory laat injecteren. Op dezelfde manier kan je de I18n bean
> gebruiken maar de map kan je laten initialiseren hoe je wil...
>
> Hier kan je meer lezen over managed beans :
>
> http://www.oracle.com/technology/tech/java/newsletter/articles/jsf_pojo/index.html
>
> As you can define the lifecycle of the beans using the scope setting, you
> must take care to only refer to other beans which exist either the same
> scope or larger scope. You can not refer to another managed bean with a
> smaller scope.
>  Managed beans registered with scope: Can only refer to other managed
> beans with these scopes:  none none  request none, request, session,
> application  session none, session, application  application none,
> application
>
> Mvg,
>
> Sander
>
> 2010/2/17 Steve Schols <steve.schols@xxxxxxxxx>
>
> Dag Rudy,
>>
>> Kan je mij op weg helpen met die "iets gebaseerd op een EL expressie"?
>>
>> Ik vind zoveel verschillende dingen terug dat ik het bos door de bomen
>> niet meer zie.
>> Er waren constraints hierop dacht ik, dat je enkel iets mocht injecteren
>> via managed-property dat in een hogere scope lag dan de bean waarin je
>> injecteert ... dacht ik, of omgekeerd. Ik vind het niet meer terug via
>> google.
>>
>> Zowel voor MessageUtils als voor PersonBean zou ik niet echt weten hoe dit
>> precies met EL dient te gebeuren...
>>
>>
>> Op 6 februari 2010 15:02 schreef Rudy De Busscher <rdebusscher@xxxxxxxxx>het 
>> volgende:
>>
>> Steve,
>>>
>>> Ik heb de laatste week heel weinig tijd gehad, maar ben toch eens
>>> diagonaal door je code gelopen.  Hieronder heb ik een lijstje gemaakt van
>>> enkele belangrijke punten. Dit zijn geen absolute waarheden maar kunnen je
>>> problemen besparen of zijn geinspireerd op enkele best practices.
>>> Als er vragen hierover zijn, laat maar horen.
>>>
>>> Zal over een tweetal weken nog eens proberen de code te overlopen.
>>>
>>> groeten
>>> Rudy.
>>>
>>> -Je hebt 2 logging frameworks, probeer commons logging overboord te
>>> gooien. (Ik zet het al bij de Questions voor volgende vergadering, over het
>>> hoe en waarom)
>>>
>>> *MessageUtils*
>>> - Dit is een Myfaces specifieke klasse dus kan je niet switchen naar
>>> Mojarra.
>>> - Hierdoor moest je de resource bundle ook tweemaal specifieren, eenmaal
>>> in faces-config en eenmal in de Constants klasse.
>>> ==> gebruik dus liever iets wat gebaseerd is op een EL expressie.
>>>
>>> *UserBean*
>>> - Is op sessie en is goed om user authenticatie data bij te houden.  Maar
>>> bevat ook data welke eigenlijk op applicatie niveau (de predefined users)
>>> horen.
>>> Het is daarom beter een andere backing bean te maken, op scope
>>> application, welke de users bijhoud maar ook zal bepalen of username en
>>> paswoord correct zijn. Deze kan dan in de userBean geinjecteerd worden.
>>> - de methode authenticate is een action methode.  Deze dient in principe
>>> enkel om de navigatie te bepalen, niet de logica welke uitgevoerd moet
>>> worden bij een klik.  Dit moet in principe in de actionListener.
>>> - Je hebt een navigatie constante gedefinieerd om op de pagina zelf te
>>> blijven, return van null is voldoende en deze moet niet in
>>> faces-config-navigation gespecifieerd worden.
>>>
>>> *xxx.jsf*
>>> - Wanneer je een lege cel wenst aan te maken in een panelgrid volstaat
>>> <f:verbatim/> op de plaats en is <panelGroup> niet nodig.
>>> - In je link naar de CSS gebruik je de root, als er een war gemaakt wordt
>>> en deze app wordt onder een andere root gedeployed dan wordt de CSS niet
>>> gevonden. gebruik altijd relatieve paden.
>>>
>>> Het is beter dat je de action methoden en actionListeners voor een pagina
>>> bij de bean houdt waarin de data staan.  Dus de personBean niet gebruiken
>>> voor personList.jsp
>>>
>>> PersonListBean moet inderdaad op session staan om de sortering van de
>>> tabel mogelijk te maken. -> Jan dit is iets voor je Conversation scope in
>>> CDI.
>>>
>>> *PersonBean*
>>> - Dit kan je op request niveau plaatsen (zo veel mogelijk op request). Je
>>> hebt dan wel een probleempje op te lossen omdat PersonBean niet in
>>> PersonListBean kan geinjecteerd worden maar daarvoor bestaat er een
>>> oplossing (weeral via EL)
>>>
>>> **
>>>
>>>
>>
>

Other related posts: