Discussion :

[frankySIG]

Bonjour à tous, je voulais savoir s'il était possible de séparer les store du fichier js de mon application: j'ai beaucoup de store et je souhaiterai les mettre dans un js à part pour des raisons de lisibilité et de maintenance.
merci

[Mako 5013]

Bonjour,

A priori, si tu les déclares correctement, je ne vois pas où il pourrait y avoir un soucis. En faisant quelque chose de ce genre-là :

mesStores.js

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
 
var store_01 = new Ext.data.Store({
     // Configuration
});

maPage.js

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
 
var grid = new Ext.grid.Gridpanel({
      store: store_01 // en ayant importe mesStores.js au prealable
)};

Mako

[frankySIG]

je viens de tester ça:

-je sépare mon applications en 2 parties:
-store.js: mes stores (j'ai éssayé en variable globale et non global)
-application.js
-index.html: appel des deux scripts.

ça ne fonctionne pas, l'application ne trouve pas les stores et les stores ne trouvent pas certains élémesnt de l'application.

[takitano]

il faudrait faire du JS-POO ...

[frankySIG]

POO? oula j'ai peur, je ne sais pas ce que c'est que ce truc. En fait je voudrait simplement diviser mon appli en plusieur morceau pour que la navigation soit plus simple que dans un bloc de 2000 lignes.
j'ai essayé ça:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
function IncludeJavaScript(jsFile)
{
  document.write('<script type="text/javascript" src="'
    + jsFile + '"></scr' + 'ipt>'); 
}

et ça avec

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

IncludeJavaScript('secondJS.js')

ça charge mais c'est la cata avec mes variables (store non reconnue par d'autre fonction...).
Il n'existe pas un truc tous simple pour remplacer un bloc de code par un fichier lié?

[Mako 5013]

Le problème, ce n'est pas tant l'insertion de petits fichiers (plutôt que d'en avoir un gros) que la réutilisation de variables à travers tous ses fichiers, en faisant comme s'ils étaient à la suite les uns des autres.

Pour information, POO signifie Programmation Orienté Objet, et tu peux trouver des tutoriels pour Ext JS ici ou là.

Mako

[sekaijin]

je ne crée jamais rien de global

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

Ext.app.monobjet = new maClasse()

ainsi mon objet est attaché à app impossible de le perdre.
j'ai séparé pas mal de chose
AbstractController.js est une classe abstraite pour mes contrôleurs
pour un module de mon application je crée un contrôleur dérivé de cette classe dans celui-ci j'indique quelle est sa vue et son modèle
c'est AbstractController.js qui se charge au moment opportun de charger le modèle et la vue et de les instancier.

mes modèles sont des objets définissant une structure de donnée et les méthodes d'accès ils inclus l'appel à la persistance (dans 99% des cas Ajax mais en html5 websocket localdatasource etc.)

mes vues sont de simple JSON décrivant la vue.
c'est le contrôleur qui se charge d'instancier un objet ExtJS en fonction de la description et de créer ainsi les objets de la vues.

J'ai donc un Modèle MVC complet.
la vue ne vois que son contrôleur il est donc facile de faire les binding automatiquement.
le contrôleur lui vois le modèle et la vue il peut donc assurer le dialogue le modèle lui ne s'occupe que du métier

j'ai aussi un contrôleur Abstrait de type singleton en dérivant on obtient un singleton.

certain modules peuvent exister en plusieurs exemplaire en même temps d'autre non

exemple ClientApp sert à manipuler les information d'un client on peut ouvrir plusieurs fiches client en même temps (dans des onglets ou des fenêtres)
par contre ParameterApp est LE tableau de bord de l'application et ne doit être ouvert qu'en un seul exemplaire.

de même le desktop (peu importe son apparence l'espace de travail) n'existe qu'une seule fois.

lorsque l'utilisateur invoque un module s'il n'a pas déjà été initialisé
le run lance le chargement du modèle et de la vue ainsi que du fichier de langue associé puis il instancie le tout et démarre le contrôleur puis il donne le go avec un évènement Ready

j'ai ainsi quelque chose de très modulaire et l'ajout ou l'évolution de composant n'impacte pas le reste de l'application.

je ne peux pas vous mettre mon projet ici
il fait environ 20 000 lignes de codes dont la moitié en js et la moitié en php

je n'ai aucun code javascript généré par php que du code statique pour que le compilateur JS et le cache fonctionne au mieux.

A+JYT

[frankySIG]

Bonjour, ce que tu me dit là me parait intéressant en revanche mes compétences limités ne me permettent pas de tous comprendre.

Pour faire simple ce que j'aimerais faire c'est séparer mes stores de mon appli dans un fichier js différent et d'appeler ce fichier dans l'appli à un endroit bien précis.

Mon application se généré automatiquement avec un code Pl-SQL en fonction de ma base de données, mon soucis et de clarifier tous ça car j'atteins très rapidement un nombres de ligne important.

[sekaijin]

ce que je te dis c'est que plutôt que de faire un fichier stores qui contient tous tes stores et un fichier app qui contient toute ton appli

tu peux découper plus finement
regarde les "objets" métier que tu manipule ex:
Client, Facture, Voiture, etc.

pour chacun d'eux tu regarde toutes les fonctions dont tu as besoin et ce sans penser à l'appli ou à l'IHM. en gros quelle sont les fonctionnalité de l'objet client
tu crées ensuite une classe client qui contient toutes ses fonctions et le ou les datasources pour manipuler l'objet.

ainsi au lieu d'avoir un fichier plein de data source tu as des composants métier que tu vas pouvoir utiliser comme tu veux sans avoir à te poser la question de savoir si c'est conforme aux règles de gestion de ton objet.

tu vas aussi pouvoir tester ton objet dans un simple script en dehors de l'interface de ton appli tu pourras aussi faire évoluer les règles de gestion de ton objet sans modifier le contenu de ton appli.

de la même manière analyse l'IHM de ton application il va se dégager des modules applicatifs relativement indépendant les un des autres
facturation, CRM, gestion stock, livraison, (pour une appli commerciale)

ces modules n'offre à l'utilisateur pas les mêmes fonctionnalités mais ils se base sur les mêmes objets métiers.

plutôt que de faire un gros fichier application tu fais un fichier par module
là encore ça permet de faire évoluer une partie sans modifier tout le reste.

enfin dans l'application il y a la partie mécanique pour faire la facturation il faut instancier les objet métier qui vont bien réagir au évènement de l'utilisateur manipuler des valeurs les changer d'état etc.
et il faut afficher la présentation.

encore une fois tu peux découper ton module en deux partie un qui s'occupe de la mécanique et l'autre qui ne définit que la présentation.

ainsi si tu dois faire évoluer la présentation tu ne touche pas à la mécanique et vice versa.

ce découpage est un design pattern (MVC) de conception très répandu mis au point dans les années 1970 ce n'est pas d'hier et il a fait ses preuves.

rien qu'en lisant mon propos il saute au yeux qu'en multipliant les découpage on risque fort de se retrouver avec un gros plat de spaghetti chaque petit bout faisant référence à un autre.

en fait non pour cela il suffit d'appliquer une règles simple le découplage fort.

la partie mécanique de ton module s'appelle le contrôleur c'est lui qui se charge de gérer le module, lancement coordination destruction. il ne fait que ça et ne manipule pas lui-même les données. les données sont manipulées par le modèle (les objets métiers) de même ni le modèle ni le contrôleur n'affiche d'écran c'est la partit présentation qui le fait (appelée vue)

comment faire pour que tous ça ne s'emmêle pas les pinceaux ?
lorsque tu active ton composant tu crée le contrôleur de celui-ci et tu lui donne la main (en général un méthode init puis run) à l'init le contrôleur crée les objets métier dont il a besoin. il crée aussi la vue.

il peut donc garder lui des références sur les objet métier et sur la vue
la vue étant crée par le contrôleur au moment de l'instancier on a une référence au contrôleur. si un composant de la vue à besoin d'une source de donnée tu n'as pas besoin de garder des références des variables globale ou quoi que ce soit la vue demande au contrôleur tout ce dont elle a besoin
ainsi le seul lien qu'elle entretient c'est avec le contrôleur.

A+JYT

[takitano]

Bonjour,

je crois que franky est un peu perdu ... là ...

bon, pour ta problematique de store:

Code javascript :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
// création de ton objet store
var all_store = function(){
 
this.store_1 = new Ext.data.ArrayStore(...);
this.store_2 = new Ext.data.ArrayStore(...);
this.store_3 = new Ext.data.ArrayStore(...);
}
 
// activation de tous tes stores
// a mettre n'importe ou dans ton onReady
var store = new all_store();
 
//accéder à mon store_2, pour lancer la méthode load()
// a mettre n'importe ou dans ton onReady
store.store_2.load();

juste pour rebondir sur ce qu'à dit sekajin ...:
l'archi MVC pour le javascript, je le fais de la manière suivante (en gros):
controlleur + model => PHP
vue=> js ...
dans la réalité, un partie du controlleur se mets aussi coté client ...

[frankySIG]

Bonjour et meric pour vos réponse, en fait j'ai trouvé le point bloquant de mon problème:
j'utilise des store de librairie webmapping (GeoExt) qui sont de objet dérivé de ExtJS, le soucis est qu ces store utilise des variable de mon application (exemple layer: ma_layer) ce qui entraine un blocage lorsque je sépare les store de ces variables.