Le forum (ô combien francophone) des utilisateurs de Powerbuilder.
Bonjour,
Petite question :
Est-il possible d'avoir une PBL qui contiendrait des petites fonctions fort utiles pouvant être utilisée dans plusieurs projets? Et qui n'est pas forcément propre au Workspace. Une sorte de source control sur une seule et unique PBL.. j'espère avoir été clair
Merci
Hors ligne
Oui ( deja fait )
Mais elle doit etre completement independante
Hors ligne
Pour ma part j'ai des PowerTools : ce sont des pbl communes a chacunes des applications powerbuilder de mon client et elles me permettent (en théorie) par exemple d'ajouter le tri automatique si on clique sur l'entete d'une colonne dans une datawindow
Hors ligne
Nephtis a écrit:
Pour ma part j'ai des PowerTools : ce sont des pbl communes a chacunes des applications powerbuilder de mon client et elles me permettent (en théorie) par exemple d'ajouter le tri automatique si on clique sur l'entete d'une colonne dans une datawindow
C'est a peut près ça chez nous.. on voudrait isoler toutes ces fonctionnalités dans une PBL. Comment gérer le fait que cette PBL soit commune à plusieurs appli?
Hors ligne
thezerg a écrit:
C'est a peut près ça chez nous.. on voudrait isoler toutes ces fonctionnalités dans une PBL. Comment gérer le fait que cette PBL soit commune à plusieurs appli?
Il suffit de mettre cette PBL en tête de la library list de chaque appli (juste après l'objet application et ton framework).
Par contre, il faut que cette PBL ne soit accessible qu'en lecture pour ces appli, afin d'éviter que n'importe qui puisse modifier les objets qui y sont référencés.
Il est aussi recommandé d'hériter des objets de ta PBL de référence dans chaque appli, plutôt que de taper directement sur ces objets...
Hors ligne
foon a écrit:
thezerg a écrit:
C'est a peut près ça chez nous.. on voudrait isoler toutes ces fonctionnalités dans une PBL. Comment gérer le fait que cette PBL soit commune à plusieurs appli?
Il suffit de mettre cette PBL en tête de la library list de chaque appli (juste après l'objet application et ton framework).
Par contre, il faut que cette PBL ne soit accessible qu'en lecture pour ces appli, afin d'éviter que n'importe qui puisse modifier les objets qui y sont référencés.
Il est aussi recommandé d'hériter des objets de ta PBL de référence dans chaque appli, plutôt que de taper directement sur ces objets...
Oui voila l'idée c'est avoir une sort de checkin/checkout seulement sur cette PBL pour pas la modifier n'importe comment..
Hors ligne
Regardes si avec ton outil de source contrôle tu ne peux pas gérer ta PBL de référence à part des autres PBL, avec des droits d'accès aux sources différents suivant le profil de l'utilisateur.(Il me semble que c'est possible, par exemple, avec PVCS)
Hors ligne
foon a écrit:
Regardes si avec ton outil de source contrôle tu ne peux pas gérer ta PBL de référence à part des autres PBL, avec des droits d'accès aux sources différents suivant le profil de l'utilisateur.(Il me semble que c'est possible, par exemple, avec PVCS)
On utilise l'outil fournit avec PB !
Hors ligne
thezerg a écrit:
On utilise l'outil fournit avec PB !
Si le contrôle source était paramétré sur les targets, et non sur le workspace, ça aurait été plus simple...
Bon, je ne vois que la solution d'une restriction d'accès sur le répertoire de la PBL commune (Administration Windows):
Les développeurs lambda n'y ont accès qu'en lecture, les autres en lecture/écriture.
Mais c'est bourrin et je ne sais pas comment va réagir le control source PB...
Si un membre du forum a une meilleur idée...
Hors ligne
Essaie de ne pas fournir au public la PBL, mais uniquement une PBD...
Monte une Target spécifique sur un répertoire accessible seulement au développeur de ta boîte à outils. Cette Target te permettra de compiler une PBD. C'est cette PBD que tu rendras publique et pas la PBL d'origine.
Libre ensuite à chacun d'inclure la PBD publique dans la liste des bibliothèques de ses projets. La PBD ne contenant pas de code source, tu garantis l'intégrité de ta boîte à outils.
Hors ligne
Heu peut-être...
Pourquoi ne pas intégré directement une version compilée de la PBL dans les autres target (une PBD donc ) puisque c'est possible en PB...
Hors ligne
FMolinas a écrit:
Essaie de ne pas fournir au public la PBL, mais uniquement une PBD...
Monte une Target spécifique sur un répertoire accessible seulement au développeur de ta boîte à outils. Cette Target te permettra de compiler une PBD. C'est cette PBD que tu rendras publique et pas la PBL d'origine.
Libre ensuite à chacun d'inclure la PBD publique dans la liste des bibliothèques de ses projets. La PBD ne contenant pas de code source, tu garantis l'intégrité de ta boîte à outils.
ARGL grillé à 1 min...
Hors ligne
Merci à tous pour votre participation
Distribution des pépites plus tard
Hors ligne
Chrnico a écrit:
ARGL grillé à 1 min...
Héhé Je savoure, d'habitude c'est moi qui me fais griller à force de composer des romans en guise de messages !
Pour rendre ce post pas totalement inutile, j'ajouterai que la technique de la PBD présente un avantage supplémentaire : une compilation séparée permet d'être certain que la boîte à outils ne présente pas, cachées au fond d'un script, de dépendances vicieuses vers des objets externes.
Hors ligne