hello,

In a "classical" login module with a class mapped VO (freely stolen from Cliff toturial and answers to Shinan  ) , I return the MemberVO object representing the whole profile of user if he is known in db or return false if not.

On my LoginProxy class, everything seems ok. I can cast event.result to MemberVO class but the instance I get is null.

:

private function onResultHandler(event:ResultEvent):void{
   if (!event.result){
      setData(null);
   }else{
      trace("id="+event.result.id+"     nickname="+event.result.nickname);     //works fine! I get ID and nickname...
      setData(event.result);
      var memberVO:MemberVO=event.result as MemberVO;   //no complain !
      trace("memberVO.id="+memberVO.id)     //Error #1009: Cannot access a property or method of a null object..   
   }
   sendNotification(LOGIN_RESPONSE,event.result);   

maybe i missed something
Thx for any help.

(This post is to mention a significant error in the french translation of the "Best Practices" document)

Aux lecteurs francophones de la documentation de PureMVC.

Outre quelques erreurs mineures que vous aurez surement relevées, la version actuellement en ligne du document "Meilleures Pratiques" comporte une coquille importante rescapée par la fatigue des nombreuses vérifications et manipulations.

Dans la section "Les Proxys- Encapsuler la logique domaine dans les proxys" (page 42 - dernier paragraphe) au lieu de :

Un changement dans le modèle la vue, ni le contrôleur éventuellement. Un réagencement des parties vue/contrôleur.

il faut lire:

Un changement dans le modèle impliquera souvent un réagencement des parties vue/contrôleur.

Mille excuses à ceux qui se sont empressés d'imprimer le document dès sa mise en ligne.

Par ailleurs, n'étant pas traducteur professionnel, je vous remercie par avance de toute remarque ou suggestion susceptibles d'améliorer cette traduction.

Eric


MISE A JOUR  DU 25 avril : la version PDF maintenant en ligne incorpore la correction mentionnée précédemment.
                                                Merci Cliff !

I"m trying to adapt CafeTownsend login sample into a generic shell (based on Daniele Ugoletti's AppSkeleton)

My app preloads and loads correctly, jumps from a SplashScreen and stops on a MainScreen that now contains a memberLogin view (eq to CafeTownsend  EmployeeLogin view)

Unfortunately, when I fill in form and press login button, APP_LOGIN event  is never catched by the corresponding mediator.

As mixing structures is complex to figure out, that's pretty hard for me to determine where my bug may come from so I'm stalled.

Considering theses two samples, does an expert can see a trap in mixing them ?

(for example, as MainScreen level does not exist in CT, should  MemberLoginMediator be registered into MainScreenMediator rather than in ApplicationMediator ?!)


Thx

Hi,

I can't catch differences and (dis)advantages between :

- the use of an unique SimpleCommand class registering model and view once (like StartupCommand in arch_101)
and :
- the use of a multi command class calling his turn, two simple commands (ModelPrepCommand and ViewPrepCommand) as described in BestPractices doc

Thank's for your answer.

Hi,

Studying the Arch101 sample, I understand that in a multi component app (several Flex mxml file...) there is a unique trio of folders (model/view/controller) wherein we put all related files to each component

Though, it would sound more intuitive to keep each comp in a dedicated folder,each one MVC organized.

I suppose your approach is better but can figure out why... 

Thank's for your work, your support...and your answer !