Jump to content

Loraga

Membres
  • Posts

    137
  • Joined

  • Last visited

  • Days Won

    2

Loraga last won the day on February 11

Loraga had the most liked content!

About Loraga

  • Birthday 05/06/1995

Profile Information

  • Gender
    Homme
  • Location
    Salon-de-Provence
  • Interests
    Programmation/Web/Réseaux

FileMaker Profile

  • FM
    FMPA 17, FMS 16
  • OS
    MacOS 10.14 - Win10
  • Certif.
    --Non certifié--
  • Claris Partner
    --Non membre--

Recent Profile Visitors

1367 profile views
  1. Pour le coup, le triple slash après file est correct ; d'ailleurs, si je prends une image sur mon ordi, et que je l'ouvre avec mon navigateur, son lien est bien "file:///C:/chemin/vers/mon/image.jpg", c'est ainsi que le navigateur formate son lien local. C'est en fait la norme RFC, plus d'infos ici 😊 Après, je pense que file:// fonctionne ou est automatiquement reformaté par tous les navigateurs récents, j'imagine que le WebViewer le fait aussi. On se fait facilement avoir, c'est vrai 😊 Les fonctions comme Obtenir ( CheminBureau ) s'occupent de tout, même du dernier slash du chemin ^^ Mais dans le cas de @Dominique Joly, on fait appel ici à des rubriques CheminDossier01 et NomFichierAvecExtension, qui sont, j'imagine, des calculs. J'ai l'impression que comme votre image se trouve à la racine du disque dur Volumes, logiquement, le calcul de la rubrique CheminDossier01 renvoie "" soit rien, puisque l'image n'est pas dans un dossier... d'où l'apparition de ce double slash ?
  2. Je vais peut-être dire une bêtise mais dans le chemin vers l'image générée, c'est correct le fait qu'il y ait deux slashes après file:///Volumes ? J'aurais tendance à penser que le chemin correct serait : file:///Volumes/033280340110_0003510001.jpg Mais je n'en suis pas sûr du coup. D'ailleurs, d'où vient ce double slash ? Dans le calcul, on en ajoute qu'un seul : Cliches::CheminDossier01 & "/" & Cliches::NomFichierAvecExtension
  3. Je confirme : tout ce qui se trouve entre les balises <head> n'est pas affiché dans une page web. La balise <style> peut tout à fait se retrouver dans le <head>, mais pas le contenu destiné à être affiché dans le webviewer, ici la balise <img>. Je trouve cependant bizarre que le webviever fonctionne avec ce code en FM14... Peut-être que FM14 ignore le <head>...? Corrigez comme ceci et testez, normalement ça devrait fonctionner à nouveau : "data:text/html," & "<html> <head> <style type=\"text/css\">html, body { border: 0; margin: 0; padding: 0} </style> </head> <body> <img src=\" " & Si ( Abs ( _Ressources::z_TOUT_PlateformeSysteme ) = "1" ; DocumentsGraphiques::CheminDossier01 & "/" & DocumentsGraphiques::NomFichierAvecExtension ; Si ( Abs ( _Ressources::z_TOUT_PlateformeSysteme ) = "2" ; DocumentsGraphiques::CheminDossier02 & "/" & DocumentsGraphiques::NomFichierAvecExtension ; "" ) ) & "\" style = \"max-width: 90%;height: auto;\"> </body> </html>"
  4. Je crois que c'est réglé (j'ai moins la tête en vrac le matin) : j'ai remplacé l'adresse du fichier (je mettais 'monsite.dns.org') par l'adresse locale du serveur '172.16.10.xxx' et tout fonctionne ! Je trouve ça bizarre, car tout fonctionnait avec l'adresse distante depuis 1 an et jusqu'au mois dernier. Entre temps, j'ai eu une panne réseau, j'ai du restaurer mon routeur à son état d'usine pour lui charger une sauvegarde de sa configuration... Du coup, rien n'a changé normalement. Je ne comprends pas 😂 Oui pardon je n'ai pas été très clair ^^ j'avais aussi remplacé l'adresse là (c'est un backoffice sur lequel je veux éviter de rendre l'adresse publique...
  5. Merci Lucie, c'est bien le cas dans mon script, mais pour des raisons évidentes de sécurité je ne les publie pas sur le forum...
  6. Bonjour à tous, Je rencontre aujourd'hui un drôle de souci sur un FileMaker Server 16, plus précisément sur la publication web personnalisée avec PHP. En PHP, sur une simple requête de recherche comme ceci : <?php $fm = new FileMaker('MonFichier', 'MonAdresse', 'Login', 'MotDePasse'); $layouts = $fm->listLayouts(); $layout = $fm->getLayout('Suivi_Master'); $request = $fm->newFindCommand('Suivi_Master'); $request->addFindCriterion('Suivi_Master::ClefSuivi', $_SESSION['laClef']); $request->addFindCriterion('Suivi_Master::Annee_Suivi', $_SESSION['schoolYear']); $result = $request->execute(); if (FileMaker::isError($result)) { echo "<pre>"; var_dump($result); echo "</pre>"; } else { $FoundRecords = $result->getRecords(); $enqueteEstRemplie= $FoundRecords[0]->getField('EnqueteEstRemplie'); } Le var_dump sur $result me renvoie ceci (j'ai volontairement réduit et enlevé les infos sensibles) : ["error_message_prefix"]=> string(0) "" ["mode"]=> int(1) ["level"]=> int(1024) ["code"]=> int(6) ["message"]=> string(65) "Communication Error: (6) Could not resolve host: MonAdresse" ["userinfo"]=> NULL ["backtrace"]=> array(7) { [0]=> array(6) { ["file"]=> string(86) "/Library/FileMaker Server/Web Publishing/publishing-engine/php/sierra/lib/php/PEAR.php" ["line"]=> int(945) ["function"]=> string(11) "__construct" ["class"]=> string(10) "PEAR_Error" ["type"]=> string(2) "->" ["args"]=> array(5) { [0]=> string(65) "Communication Error: (6) Could not resolve host: MonAdresse" [1]=> int(6) [2]=> NULL [3]=> NULL [4]=> NULL } } J'utilise un service de DNS dynamique pour avoir un nom de domaine qui pointe toujours sur l'IP du serveur local ; là, si j'ai bien compris, FileMaker n'arrive pas à résoudre le nom. Je n'ai jamais rencontré cette erreur auparavant. Je ne sais pas où chercher : du côté du FMS, de mon routeur, du serveur en lui même...? ça semble être une erreur réseau, or, je n'aime pas trop les réseaux mais je me débrouille... Sauf là ^^ Si quelqu'un a des indices à me donner je suis preneur ! Je reprends les investigations demain matin et vous tient au courant si j'avance... Merci d'avance
  7. Je rêve d'un endroit où on puisse saisir et lister toutes ces trouvailles, qui sont intéressantes et précieuses dans certains cas précis 😊 J'ai appris tellement de trucs et astuces sur ce forum, ou en regardant les vidéos des FM conférences aussi, ce serait top d'avoir une sorte d'index dans lequel on liste et classe par catégorie ce genre de détournements hyper pratiques. Merci @Jérémie Gimenez 😊
  8. Via un script, on pourrait stocker la valeur initiale de la rubrique dans une variable globale dès que l'utilisateur sélectionne la rubrique (SurEntreeObjet). Si l'utilisateur clique sur annuler, on restaure alors la valeur initiale de la rubrique avec l'aide de cette variable. Logiquement, la rubrique sera déjà au bon format HH:MM:SS, on ne devrait donc pas à avoir à s'embêter en extrayant séparément les heures, les minutes et les secondes pour ensuite recréer l'heure avec la fonction Heure() (enfin je crois ?).
  9. J'arrive après la guerre, mais une petite chose intéressante qui peut servir pour l'affichage, notamment dans un modèle d'email : On peut formater les données d'une rubrique de fusion, toujours via l'inspecteur > onglet données. Dans ma capture ci-dessous, j'ai à la fois reformaté l'affichage de la date et de l'horaire, alors que l'ensemble n'est qu'un simple bloc texte contenant les rubriques de fusion. Ça peut servir... Edit : Oups, je n’avais pas vu la page 2 😂 Oui, tout est permis sauf si on contrôle l'entrée de la rubrique par un calcul (via l'onglet Validation de la rubrique, dans gérer > bases de données - j'aime pas trop cette méthode car je trouve les boites de dialogues assez embêtantes et bloquantes pour l'utilisateur) L'autre solution, c'est de permettre à l'utilisateur de saisir l'heure comme il veut et ensuite reformater sa saisie via un script qu'on déclenchera sur la validation. Ainsi, peu importe s'il tape 9h12, 09h12 ou même 9:12, l'idée, c'est de corriger automatiquement et en toute transparence 😊
  10. Mais je pars du fait qu'avec FileMaker, il y a toujours un moyen de contourner et d'arriver à ses fins (c'est un peu ça qu'on aime aussi non ? Le défi 😂) Perso, je reste sur l'idée de la double rubrique : une rubrique texte réservée à l'interface pour la saisie/modification par l'utilisateur, une autre calcul qui renvoie l'heure au bon format et qu'on utilisera uniquement côté BDD, scripts, pour les calculs de durée, etc. ça fait un peu beaucoup à gérer pour peu, mais je pense que ça peut marcher. D'ici demain si j'ai un peu de temps je vais tester ça...
  11. Ah oui, je n’avais pas compris du tout 😂 Effectivement, chez moi aussi j'ai ce comportement, mais je doute sincèrement qu'on puisse y faire quoi que ce soit. Après, mon contexte est un peu différent, car l'utilisateur ne saisit une heure que lorsqu'il crée l'enregistrement (à ce moment-là, la rubrique est vide). C'est plutôt rare qu'il doive la modifier, mais j'ai l'impression que mes utilisateurs n'ont ni remarqué ce détail, ni même été gêné par celui-ci... ! Moi-même, je ne l'avais pas remarqué... Et bien si ! Mais en fait ce n'est pas si frustrant que ça. Un simple déclencheur de script sur la validation permet de reformater la saisie. L'utilisateur saisit "17h45" est le script remplace ça par "17:45:00" et ça marche bien. Je ne vois pas d'autre solution que de travailler avec deux rubriques : une texte, pour la saisie et l'affichage, l'autre en calcul, qui prend le contenu de la rubrique texte et le renvoie au format heure... Pas hyper pratique à gérer mais je n’ai pas mieux comme idée... De cette façon, lors de la modification de la rubrique texte, on aurait toujours le format "HH:MM" ou même "HH\hMM" d'affiché.
  12. Salut Matessias, Oui et je pense qu'on n’a pas le choix. C'est la même chose pour les bases de données SQL par exemple, qui attendent une heure au format HH:MM:SS. Généralement, on ignore les secondes (elles valent alors 00 par défaut), il suffit de gérer l'affichage côté modèle ainsi qu'à la saisie. C'est la même chose avec les dates : FileMaker à besoin d'une date complète pour la saisie (ex : 07/06/2021) mais on peut aisément modifier ce format à l'affichage pour une date courte comme 07/06. On peut aussi saisir une date courte et FileMaker se débrouillera tout seul pour y rajouter l'année courante, même si on ne la voit pas à l'affichage. On doit faire avec 😊 J'ai des rubriques similaires aux tiennes dans une appli de gestion d'immobilisations. L'utilisateur peut créer une feuille de prêt lorsque du matériel sort de l'agence, il doit alors saisir une date et une heure de départ et une date et une heure de retour. Pour l'heure, l'utilisateur saisit par exemple "09:30", et c'est "09h30" qui sera affiché sur le modèle. Il n'y a rien de compliqué et je ne me souviens pas avoir galéré pour mettre en place cet affichage : Côté base de donnée, rien à signaler de particulier à part que ma rubrique est de type "heure" Côté modèle, tout se fait via l'inspecteur, onglet données, j'ai choisi comme format "hhmm" et comme séparateur un simple "h". Je joins les captures mais je n'arrive pas à comprendre pourquoi FileMaker t'embête avec ce format alors que chez moi, non... Je n'ai peut-être pas bien compris ton souci, désolé d'avance si c'est le cas !
  13. Bonjour Jérémie, merci pour ta réponse ! 😊 C'est bien ce que je voulais savoir, mais ne trouvant aucune info à ce sujet, je pensais alors avoir rêvé. C'était @David Julot qui m'en avait parlé en formation et m'avait averti en 2018, il me semble... Si @Lucie Guilbert a quelques infos supplémentaires à ajouter, je suis preneur 🙂 Dans tous les cas, je sais maintenant qu'il est temps de se mettre à la Data API pour les prochains projets ! Edit : on poste en même temps 🙂 Merci Lucie pour ces infos ! Étant actuellement en PHP 7.4 sur un serveur web en production, j'avais contourné ce souci de compatibilité avec le FileMaker PHP-API de Romain Dunand, mais du coup j'appréhendais le passage à PHP 8. Merci encore en tout cas, j'ai plus qu'à consulter vos liens et vidéos et je sais maintenant quoi apprendre cet été haha
  14. Bonjour à tous, Personne n'a d'info à ce sujet ? 😢 Je reformule ma question au cas où ce n'était pas bien clair : Pour les développements actuels et futurs, lorsqu'on a besoin d'utiliser sa base FileMaker sur le web avec PHP, est-ce qu'il vaut mieux travailler avec la FileMaker Data API ou avec la publication web personnalisée ? Merci et bonne semaine à tous 😊
  15. Bonjour à tous, À l'époque de FileMaker 17, j'avais cru entendre en formation que la publication web personnalisée avec PHP ne serait un jour plus supportée. Qu'en est-il aujourd'hui ? Je n'arrive pas à trouver d'information ce sujet. J'avais peut-être mal compris (en tout cas j'espère 😂). Quand j'ai besoin d'utiliser FM sur le web avec PHP, j'installe systématiquement ce dépôt FileMaker PHP API qui est vraiment pratique et qui m'a permis d'utiliser PHP 7.4 avec un FMS 16 par exemple. Je n'ai pas essayé la FileMaker Data API, on peut aussi l'utiliser avec PHP a priori, mais il faut que je me forme là-dessus. Du coup, en 2021 et pour l'avenir à long terme, qu'est-ce qui est le mieux : continuer à travailler avec la publication web personnalisée ou faut-il mieux travailler avec la data API ? Merci d'avance pour votre aide,
×
×
  • Create New...