Jump to content

ypicot

Membres
  • Posts

    943
  • Joined

  • Last visited

  • Days Won

    13

ypicot last won the day on December 9 2016

ypicot had the most liked content!

About ypicot

  • Birthday 10/01/1963

Contact Methods

  • Website URL
    http://www.ypicot.fr

Profile Information

  • Gender
    Homme
  • Location
    banlieue sud de Paris

FileMaker Profile

  • FM
    FMP14
  • OS
    Windows-Linux
  • Claris Partner
    --Non membre--

Recent Profile Visitors

16852 profile views

ypicot's Achievements

Newbie

Newbie (1/14)

26

Reputation

  1. Fabrice, comme tu sais, je suis à l'aise avec FM, à condition de ne pas y toucher. Pour moi, tous ces trucs de développeurs... Là j'ai simplement l'occasion de faire un peu de Vue.js, ce qui me change agréablement de PHP (Ca reste moins agréable que Python et d'autres bricoles, mais c'est une autre histoire...). Et comme d'habitude, je suis toujours prêt à partager mon ignorance avec d'autres Yvan
  2. Bonjour Vos posts me titillent un peu. Magalie, j'ai essayé de passer par un bout de code PHP pour récupérer le token du DataApi, qui ensuite était envoyé au client. Résultat, quand je faisais une requête en utilisant ce token (à partir du client, cette fois), je me prenais une erreur "token invalide" dans les gencives. J'ai donc viré la couche PHP pour récupérer directement le token à partir de JS, et là je n'ai plus eu aucun problème. J'en avais déduis (probablement de façon erronée) qu'il fallait que l'adresse IP (ou tout autre information envoyée à FMS) soit identique entre la demande de token et l'utilisation dudit token. Romain, je comprends que te connecter via un compte générique sur la DataApi soit pour le moins dangereux, mais quid d'un compte spécifique par utilisateur ? Si chaque utilisateur de ton appli utilise un login/pw qui lui est propre, et qui correspond à un seul compte coté FM, et chaque compte relié à un profil ayant des droits limités qui vont bien, où est le problème ? Certe cela implique que FM va devoir créer un compte par utilisateur, mais cela semble se faire sans trop de difficulté par script. Accessoirement, content de me retrouver parmi la bande de fous Yvan
  3. Pour compléter la réponse d'Apophis : sur ton modèle, tu as défini le format en secondes (donc juste l'affichage). Or ce format n'est pas "visible" par PHP : seule compte la valeur interne du champ.
  4. Autant que je me souvienne (cela fait longtemps que je n'ai pas fait de FM), php se moque complètement des liens "internes" et ne regarde que ce qu'il trouve dans ton modèle. Si tu as tes tables externes B et C sur le modèle dont l'ancre est A , le code pour B et C devraient être quasi-identiques : $related_recordB = $recordA->getRelatedSet('occB');foreach($related_recordB as $recordB){ echo $recordB->getField('occB::ID');}$related_recordC = $recordA->getRelatedSet('occC')foreach ($related_recordC as $recordC){ echo $recordC->getField('occC'::ID).'<br>';} Yvan
  5. J'en suis sûr, vous adorez les réglementations qui vous expliquent comment faire votre métier... Bon, ok... Cela concerne notamment ceux qui développent dans et pour leur entreprise, mais aussi les clubs et tout organisme qui stocke des données personnelles. Pour les professionnels (c'est à dire ceux qui bouffent grâce à FM), je pense nécessaire de suivre la chose pour en informer vos clients, ou au moins ne pas tomber des nues si on vous en parle. Je vous fais grâce de la version originale, le wikipedia présente l'essentiel : https://fr.wikipedia.org/wiki/Règlement_général_sur_la_protection_des_données Un lien un peu plus complet tout en restant lisible : https://www.brainwavegrc.com/fr/besoins-brainwave/besoins-techniques-en-securite-informatique-brainwave-grc/gdpr-reglement-general-sur-la-protection-des-donnees-rgpd/ Yvan
  6. Si tu as trouvé un généreux donateur pour une version à peu près récente (on va dire >=12), très bien. Sinon, tu peux te plonger dans le monde de l'open source, et notamment Dolibarr qui est un produit utilisé par de nombreuses sociétés. Yvan
  7. Un site sympa et actuel (responsive et tout) sur lequel les produits ne sont même pas chinois... pfff... aucun intérêt, je ne peux même pas balancer mon fiel... Yvan
  8. Bonjour Hypothèse de départ : tu connais aussi bien FM qu'APEX (ou tu es prêt à te mettre à niveau). Si tu ne connais pas APEX, attention, le produit est un gros poil plus complexe à appréhender que FM, et l'admin Oracle est plus péchue que l'admin FMS. Je dirais que les points centraux sont la complexité de l'application et le design des écrans / états. - appli simple (principalement du CRUD), avec des formulaires (et surtout des états) complexes / chargés : avantage à FM, avec lequel tu gagneras beaucoup de temps sur le design des modèles. - appli complexe, nécessitant par exemple une analyse poussée de flux des données, et des formulaires simples : APEX. Un des soucis d'APEX sont les technos annexes à maitriser si tu veux une interface un peu travaillée : CSS, mais aussi javascript et souvent jquery / bootstrap / ... (heureusement pour moi, je suis toujours resté dans les templates de base). Le temps que tu vas passer à fignoler tes écrans / pdf peut largement bouffer le prix des licences. Dans une appli complexe, le temps de développement sera plus ou moins le même dans les deux environnements (à compétence égale), et la différence de prix des licences devient sensible. Autre point (mineur) : si tu penses à maxapex pour ton hébergement, je te déconseille celui à $14 : jasper report est très utile. Plusieurs autres arguments sont à prendre en considération : - le fait que l'existant est en FM : les utilisateurs ne seront pas dépaysés (gains sur la formation, et le coût invisible du temps d'adaptation est diminué) - comme cité plus haut, APEX est plus difficile à maitriser - les compétences APEX sont assez rares en France (le produit a beaucoup moins bien pris qu'en Allemagne / Benelux / Angleterre, pour ne citer que l'Europe) - les deux points précédents posent le pb de la pérénité pour APEX. Détail important : je n'ai pas fait d'APEX 5 (j'ai bossé avec la v2 et la v4), je ne connais donc pas la dernière version, et le gap de version est souvent sensible chez Oracle (ça, c'est pour les "évolutions" de FM14 à FM15). Il est donc possible que certains arguments soient moins pertinents avec la v5. Yvan
  9. Réaction suite à mes premiers essais : mais c'est GENIAL ! En plus, le truc semble assez modulaire, donc facilement adaptable. Par contre, un chouilla plus complexe que 2 tables liées et 5 lignes de script. Il va falloir que je fasse tourner en pas à pas pour regarder comment ça marche, et surtout comprendre (et progresser). Un peu mis en forme, cela pourrait tout à fait figurer dans une bibliothèque de script. Je n'hésiterai pas à revenir ici s'il y a un point que je ne comprends pas (pour l'instant, la table list_ est un peu mystérieuse, mais je vais m'appliquer à décortiquer son utilisation dans les scripts. Il me semble que c'est le coeur de la Virtual List évoquée dans ce fil). Grand merci à Eric et Philippe pour ce travail remarquable ! Yvan
  10. ypicot

    Le bon coin

    Autant que je me souvienne, l'usage des robots (et donc de toute api) pour la lecture est même interdit par les CGU du boncoin (à vérifier cependant). Je ne serai pas surpris que l'interface de vente fasse appel à des routines javascript ou autre, ce qui rend l'interface plus agréable mais son automatisation plus délicate. C'est la raison pour laquelle j'ai tendance à utiliser des services tiers : ils assurent la compatibilité entre tes besoins et l'interface web. Si l'interface web change (ce qui arrive assez régulièrement, même si ce n'est pas visible à l'oeil nu), c'est à eux de se dém... pour adapter leurs routines de transfert. Yvan
  11. Oula... ca chauffe dur... J'ai complètement la tête dans le guidon (sur une problématique toute autre), et je constate sans aucun plaisir que je fais parti des moins actifs sur ce fil . Même pas de neurone dispo ne serait-ce que pour lancer FM. La situation devrait grandement s'améliorer dès ce week-end, et je regarderai avec beaucoup d'attention vos différentes contributions. En tous cas, merci par avance. Yvan
  12. ypicot

    Le bon coin

    Je te suggère de jeter un oeil sur lbcposter.fr Yvan
  13. En gros, Alex veut créer un export. Il créé donc un modèle, dans lequel il choisit des champs, qu'il ajoute (ou enlève). Il peut partir d'un modèle existant (un "modèle modèle") comme tu le suggères (ce qui est une excellente idée). Par exemple, il va créer un export "adresse", contenant uniquement les données postales des clients. Béa peut également créer un export de son coté, différents de celui d'Alain (concernant le CA du mois de chaque client). Bien sûr, Alex, Béa et Chris (un troisième larron) peuvent, par la suite, utiliser l'un ou l'autre des modèles pour reproduire l'export sans redéfinir les champs à chaque fois. Yvan
  14. Désolé la réponse tardive, j'ai eu pas mal de lait sur le feu... En fait, chaque utilisateur peut créer un ou plusieurs modèles, auxquels tous les autres utilisateurs ont accès. Donc pas de problème de droits d'accès de ce coté-là. Pour info, j'utilise déjà le mode tableau (mais de façon beaucoup plus primaire que dans la vidéo) quand j'ai des utilisateurs qui sont hélas très marqués par excel et ne veulent pas trop de changement. Philippe, ta solution ne permet pas hélas d'enregistrer la structure de l'export (ce qui fait parti de mes besoins), mais je te remercie pour l'effort. Merci tcolles pour cette vidéo, mais as-tu l'autorisation de la personne qui présente les tableaux (un certain Tanguy je-sais-pas-quoi) pour diffuser la vidéo ? (ok, je sors...) Yvan
  15. FM peut être utilisé en arrière-plan (pour la partie admin du site), mais pour le site lui-même, ce n'est peut-être pas la solution idéale. Les solutions FM sont soit mal adaptées à ton cas (incompatibilité connue de WebDirect avec Firefox) soit demandent un temps de développement non négligeable, avec une courbe d'apprentissage assez raide (passage par PHP). Des solutions utilisant des formulaires pur web clé en main (genre typeform) ont été évoquées sur ce forum. Il te restera un certain nombres d'opérations à faire à la main (transfert des données du web vert FM via un fichier .csv, ...), mais qui dit "pas de prog" dit souvent "à faire à la mimine". Yvan
×
×
  • Create New...