Gestion d'une application "multipage".

Bonjour,

Après avoir avancé et vue un peut l'étendu de Flex je voudrais savoir la manière dont ça fonctionne pour une application.

Dans une page web basique, il y a la notion de page. Pour passer d'une page à une autre ont utilise généralement des liens avec éventuellement des paramètres.
Admettons que la première fenêtre de mon application soit une page d'identification. Si l'utilisateur s'identifie je pense pas qu'ont passe dans un autre fichier Swf. Je suppose que ça ne passe passe pas comme des pages web.
J'ai bien l'idée d'utiliser un système avec des onglets mais je crains qu'au finale l'application soit vraiment trop lourd à gérer.
En faite, je veux juste comprendre la logique du système dans ce domaine et les mots clés à chercher pour que je puisse fourrer mon groin dedans.

Merci.

Bonjour,

Avec Flex, on fait de la RIA (Rich Internet Application) ce qui n'a rien à voir avec les applications Web classique qui suivent le page par page contraint par le protocole HTTP.

Le raisonnement page par page est à oublier en Flex (comme en GWT ou Silverlight d'ailleurs). On raisonne en évènementielle et tu dois concevoir ton application comme une application de type Swing, SWT ou autre. Si tu veux faire du page par page il faudra revenir au HTML, ça sera plus simple. Les RIA comme Flex sont là pour raisonner autrement et fournir aux utilisateurs une application très proche des applications de bureau avec un comportement plus fluide et plus user-friendly. Pour le code, il faudra raisonner par composant et plus par page. Tu peux faire des onglets, des menus. Tu peux aussi utiliser des ViewStacks pour mettre plusieurs vues dans ton application et afficher celle qui va bien au bon moment. Et sinon pour plein d'exemple tu as le Flex 3 component explorer qui reste indispensable à tous développeurs Flex, débutant comme confirmé.

Bon courage

Merci pour ton explication. En faite, j'avais bien compris que ce n'est pas en raisonnement page par page et utiliser Flex dans ce genre de concepte est limite ridicule. La notion de composant je l'ai bien saisie et utilisé ce week end. Dans mon projet cette notion est indispensable et me permet de monter l'application bien plus rapidement qu'en HTML (ouf! merci Adobe).
En faite, tu viens de me donner le mot clés que j'avais besoin de connaitre : ViewStacks . Je vais fourrer mon nez dedans. J'en ai entendu parlé et vu des tutorials mais ils étaient tellement anorexique que j'ai pas vu ces réelle possibilités.

Merci, je vais creuser dans ce domaine.

Si tu as bien saisi la notion de composant, et le passage de paramètres, ca va aller tout seul pour ta ViewStack et ton application alors :ccool:

Citation:

---

Envoyé par Krazymins

Si tu as bien saisi la notion de composant, et le passage de paramètres, ca va aller tout seul pour ta ViewStack et ton application alors :ccool:

---

Oui, j'ai regardé le code du ViewStack, en faite, c'est une sorte de conteneur. Il y a rien de féroce dedans.
Il me reste juste à gérer l'envoi de formulaire mais je pense qu'il y a rien de difficile. Un tutorial parlant de cela doit pas manquer :).

Bonjour,

Si tu souhaites dans Flex une notion similaire aux pages HTML je te conseille les 'states'.

Bien à toi

Citation:

---

Envoyé par vilveq

Bonjour,

Si tu souhaites dans Flex une notion similaire aux pages HTML je te conseille les 'states'.

Bien à toi

---

Merci, j'ai également vu cette notion mais je rassure tout le monde, je souhaite pas trop avoir la même notion de page HTML. J'ai quitter le monde HTML en partie pour ça.
Mon seul souci c'est l'éventuelle taille du projet. Donc, du chargement de l'application.
Mais, j'ai vais utiliser une technique nommé "Technique de la griffe du loup". Je fais une version AIR. :mrgreen:

Le véritable mot clef est MODULARITE.

Le découpage de l'application en modules permet de charger sur le poste client les modules au fur et à mesure de leur utilisation et donc avoir un délai initial de chargement moins long.

Cela permet également de réduire la taille mémoire utilisée qui peut rapidement devenir très importante...:cry:

Citation:

---

Envoyé par jylaxx

Le véritable mot clef est MODULARITE.

Le découpage de l'application en modules permet de charger sur le poste client les modules au fur et à mesure de leur utilisation et donc avoir un délai initial de chargement moins long.

Cela permet également de réduire la taille mémoire utilisée qui peut rapidement devenir très importante...:cry:

---

Là, tu m'ouvres un tas de questions à poser. Tant pis :D

Une module peut être un ensemble de composants ?
Et donc une application peut être un appelle à chaque module selon les besoins ?
Comment se comporte les modules. Ils se charge au moment de l'appelle de ce module ou ils sont tous compactée dans le SWF ?
Merci

Les modules sont en effet chargé au moment ou tu décides de les charger, par exemple un clic sur un bouton dans ton appli principal. Il n'est pas compilé dans le même binaire que ton application. Regarde les tuto sur le sujet, la classe ModuleLoader pourras déjà t'aider a comprendre le chargement/déchargement d'un module.

Un module est un fichier SWF qui ne peut pas être exécuté directement par le Player Flash (ou AIR) mais uniquement au sein d'une application hôte.
Un module peut être optimisé pour une application (dans ce cas les classes utilisées par l'application ne sont pas incluses dans le module) ou utilisable par différentes applications.

ok, je comprend maintenant le principe de module. En gros, un module est un sous-ensemble qui peut "éventuellement" être composé de sous-ensemble de composant. Je suppose que le passage de paramètre doit se passer plus ou moins comme les composants.
Je vais donc faire une map pour les composants que j'ai besoin et les modules dont sera composé l'application. Pour finir, quel module à besoin de telle composant. C'est pas une question ;) .
Il y a pas à dire, Adobe a bien géré son bébé :D .

Citation:

---

Envoyé par jylaxx

Un module est un fichier SWF qui ne peut pas être exécuté directement par le Player Flash (ou AIR) mais uniquement au sein d'une application hôte.
Un module peut être optimisé pour une application (dans ce cas les classes utilisées par l'application ne sont pas incluses dans le module) ou utilisable par différentes applications.

---

Excuse moi mais je reviens sur la phrase mis en gras.
Je voulais voir un peut comment créer un module. Flex Builer m'a proposé si c'était optimisé pour telle ou telle application. De là, je me suis souvenue de ce que tu viens de dire. Si je fais en sorte qu'il soit optimisé pour une application, le module se retrouvera allégé des classes déjà existante dans l'application et devient totalement dépendante d'elle.
Ai-je bien compris ?

oui c'est cela :ccool:

Juste pour savoir vu qu'on parle ici de taille d'app et de modularité.
Quel est la taille maxi à ne pas depasser pour une appli Flex (je parle du SWF généré en fait)?
Cette taille au delà de la lenteur de chargement, peut elle influencer negativement l'initialisation de l'application elle-même? (La je parle des eventuels HTTPService ou URLLoader qui sont lancé a travers l'évènement initialize de <mx:Application>)

Merci

Citation:

---

Quel est la taille maxi à ne pas depasser pour une appli Flex

---

C'est la taille correspondant à un temps d'attente supportable pour l'utilisateur...;)

Citation:

---

Cette taille au delà de la lenteur de chargement, peut elle influencer negativement l'initialisation de l'application elle-même? (La je parle des eventuels HTTPService ou URLLoader qui sont lancé a travers l'évènement initialize de <mx:Application>)

---

Je vois pas en quoi la taille peut influencer les performances des requêtes au serveur. Si par contre il y a un milliard de requêtes exécutées au cours de l'initialisation il y aura peut-être un léger temps d'attente supplémentaire :mouarf: Mais cela n'a rien à voir avec la taille du fichier swf initial. A moins que quelque chose m'échappe dans la question ?