Jump to content
  • 0

Site En Php Basé Sur Filemaker ?


Tarick

Question

Bonjour,

Tiens, un nouveau projet qui va peut-être me permettre de faire un site dynamique enfin basé sur filemaker.

Soit une agence de voyage, dont je développe les outils de gestion en filemaker. (FMS 10 sur serveur dédié, ip fixe).

Soit un site internet en PHP où on pourrait composer un voyage à la carte en choisissant ses dates d'arrivée, de départ, un itinéraire, un moyen de transport, une assurance, des hébergements à chaque étape, des activités... et obtenir un devis indicatif (pdf), mémorisé et sujet à modifications/validations ultérieures. Ajoutons à ça un paiement en ligne qui déclenche les confirmations de booking.

la publication personnalisée en php permet-elle au php d'attaquer le base comme il le ferait en MySQL ?

Faut-il utiliser l'API php pour filemaker ?

Peut-on exécuter des script filemaker côté serveur ?

Où puis-je trouver de l'info sur la syntaxe des requêtes ?

Bien entendu, je prendrai un développeur php, mais celui-ci ne connait pas filemaker.

Link to post
Share on other sites

Recommended Posts

  • 0

Bonjour,

Tout cela est possible.

oui

oui

oui

dans la doc de filemaker serveur: /library/Filemaker Server/Documentation/French/fms10_cwp_php_fr.pdf

Vous pouvez aussi prendre un développeur qui maitrise filemaker et PHP, vous y gagnerez du temps...

Raphaël.

Link to post
Share on other sites
  • 0

Oui, il faut utiliser l'API PHP pour FileMaker. Sans elle point de salut !

Oui, il est possible d'exécuter des scripts côté FileMaker Server à partir de "requêtes" PHP.

Les classes disponibles sont documentées de manière succincte en HTML. On peut trouver ça dans les répertoires e documentation installées par FileMaker Server.

Link to post
Share on other sites
  • 0

Oui, il faut utiliser l'API PHP pour FileMaker. Sans elle point de salut !

Oui, il est possible d'exécuter des scripts côté FileMaker Server à partir de "requêtes" PHP.

Les classes disponibles sont documentées de manière succincte en HTML. On peut trouver ça dans les répertoires e documentation installées par FileMaker Server.

Seules certaines classes sont disponibles ou peut-on exploiter toute la puissance de php 5 ?

J'aimerais un site avec un minimum de réaffichage (AJAX), du cliquer-déposer, listes accordéons, calques...

Link to post
Share on other sites
  • 0

Oui, il faut utiliser l'API PHP pour FileMaker. Sans elle point de salut !

Il y a bien une obscure société du nom de La Source qui utilisait jadis une plateforme appelée Lasso pour interroger en script une base Filemaker ;)

En Lasso, ça donne quelque chose comme :

[inline ( -database = MaBase.fp7, -layout=Voyages , -search , 'Destination' = 'Bali' ,

-operator = gt, 'Date_depart' = '10/12/2010', -maxrecords = 100)]

[found_count] résultats pour cette recherche :

<ul>

[records]

<li>[Field : Destination] - [Field : Date_depart] - [field: Prix]</li>

[/records]

</ul>

[/inline]

On peut utiliser ce type de balises intégrées au HTML, ou écrire son code logique Lasso à part.

Aucun souci pour utiliser Ajax , la page de résultats de recherche peut très bien être générée coté serveur par Lasso et être appelée par un formulaire expédiant les critères de recherches via XHR. Je fais ça tous les jours avec jQuery.

Exemple de formulaire ajax en fonctionnement

Si tu veux jeter un oeil au langage et à ses possibilités :

Lasso Language Guide

Dominique

Edited by Dominique
Link to post
Share on other sites
  • 0

Comment ça obscure ??? :rolleyes: Oui on a encore des sites qui tournent sous Lasso, mais il est vrai qu'on privilégie désormais pour des questions de portabilité et compatibilité le langage PHP...

Pour répondre à Tarick, l'API PHP ne fait qu'ajouter des fonctionnalités à PHP 5 permettant le dialogue avec FileMaker Server. Bien sûr PHP garde toute ses capacités natives !

Link to post
Share on other sites
  • 0

Oui on a encore des sites qui tournent sous Lasso, mais il est vrai qu'on privilégie désormais pour des questions de portabilité et compatibilité le langage PHP...

Mmm...portabilité ?

Ne voudrais-tu pas plutot parler de contraintes d'hébergement ? ( mutualisé PHP discount vs hébergement Lasso spécialisé )?

Parceque pour ce qui est de la portabilité, Lasso Server tourne sur Mac, Win2003, Red Hat, Suse, CentOS ... donc ton code peut suivre ton changement de plateforme... Mais tu le sais aussi bien que moi naturellement ;)

Pour ce qui est de la compatabilité, Lasso 8.5 gère toutes les versions de Filemaker , de FMP6 à FMS10, en passant par Filemaker Pro normal (pas "server"), grâce à la publication XML personnalisée.

Ils ont toujours suivi de près les évolutions de Filemaker, je pense que les utilisateurs Filemaker forment toujours l'essentiel de leur clientèle.

Link to post
Share on other sites
  • 0

Est-ce que c'est filemaker qui gère les autorisations et jeux de privilèges ?

Est-ce que c'est filemaker qui gère le formatage de données ? (par exemple 2 zéros après la virgule, suivi de " €")

(je suppose qu'il faut formater dans la boite de contrôle de rubrique plutôt que sur le modèle)

Est-ce que c'est filemaker qui gère les sessions ?

Les solutions de paiement en ligne des banques accepteront-elles une transaction avec Filemaker via php ?

Link to post
Share on other sites
  • 0
Seules certaines classes sont disponibles ou peut-on exploiter toute la puissance de php 5 ?

Tu as toute la puissance du PHP5, mais tu ne peux pas utiliser certains frameworks/bibliothèques basés du SQL. Exit Symphony ou Doctrine, par exemple.

J'aimerais un site avec un minimum de réaffichage (AJAX), du cliquer-déposer, listes accordéons, calques...

Ce n'est pas PHP, c'est du javascript / xhtml / css. Pas de pb pour toute la partie interface

Est-ce que c'est filemaker qui gère les autorisations et jeux de privilèges ?

Est-ce que c'est filemaker qui gère le formatage de données ? (par exemple 2 zéros après la virgule, suivi de " €")

(je suppose qu'il faut formater dans la boite de contrôle de rubrique plutôt que sur le modèle)

Est-ce que c'est filemaker qui gère les sessions ?

Les solutions de paiement en ligne des banques accepteront-elles une transaction avec Filemaker via php ?

Non, ca dépend, non, oui.

En fait, en première approche, tu peux considérer FM comme un remplacant de MySQL. Donc, tout ce qui ne dépend pas directement de la base de données est faisable en PHP, qu'il y ait du FM ou du MySQL derrière.

La seule chose que tu ne puisses pas utiliser, c'est tout ce qui fait directement appel au SQL.

Yvan

Link to post
Share on other sites
  • 0

 

 

Est-ce que c'est filemaker qui gère les autorisations et jeux de privilèges ?
PHP est un utilisateur de FileMaker comme un autre utilisateur, sauf qu'il ne se connecte que ponctuellement lorqu'il a besoin de faire qque chose avec FileMaker Server. Il a donc les privilèges qui lui sont donnés par l'administrateur.
Est-ce que c'est filemaker qui gère le formatage de données ? (par exemple 2 zéros après la virgule, suivi de " €")
Non, FileMaker "stocke" l'info, il faut utiliser PHP pour formater l'info fournie par FileMaker (comme avec une base SQL).
Est-ce que c'est filemaker qui gère les sessions ?
Non, les sessions se gèrent normalement par PHP.
Les solutions de paiement en ligne des banques accepteront-elles une transaction avec Filemaker via php ?
Les solutions de paiement en ligne interagissent avec un script PHP et éventuellement un CGI fourni. Peu importe la base de données qui est derrière.
Link to post
Share on other sites
  • 0

Merci pour vos réponses.

Je vais tenter le coup comme ça. Ça fait longtemps que je veux faire ça. J'ai déjà expérimenté des solutions alternatives (CMDL, site miroir sql, export xml puis lecture dans Flash...).

J'ai lu le document"fms10_cwp_php" qui m'a bien éclairé aussi.

Je n'ai pas bien compris pourquoi il faut faire appel à un modèle, puisque c'est php qui formate les données, mais bon, on verra sur pied.

Link to post
Share on other sites
  • 0

J'ai déjà expérimenté des solutions alternatives (CMDL,

...CDML, ça c'était avec Claris Home Page, en 1998... C'était une version "Clarisée" de Lasso commandée par Filemaker. Puis Filemaker a laissé tomber le CDML en faveur de XML/XSLT, puis voyant que ça ne prenait pas vraiment, a vite introduit l'API PHP pour limiter les dégâts...

Après plusieurs changements de mains (Blue World/ Omnipilot /Lassosoft), qui a abouti à la reprise en main de la société par les développeurs, lasso poursuit son bonhomme de chemin, sans le label "officiel" de Filemaker, ce qui ne l'empêche pas d'être le meilleur middleware pour Filemaker quand on sort des APIs officiels.

Ils ont même un produit "Lasso Studio", qui est un plugin pour Dreamweaver qui reproduit un peu le feeling CDML sous Claris Home Page (on sélectionne ses tables, champs etc avec des menus qu'on inclut graphiquement dans la mise en page).

Enfin bon, bonne chance chez PHP...

Link to post
Share on other sites
  • 0

PHP interagit avec un modèle FileMaker de la même manière qu'en XML (et pour cause, PHP n'est qu'une surcouche) pour définir quelle occurrence de table doit être appelée et quelle rubrique, voire listes de valeurs, FileMaker Server va renvoyer à PHP. C'est un peu l'équivalent des parties SELECT et WHERE d'une requête SQL. Le modèle définit le tableau de réponse...

Link to post
Share on other sites
  • 0

Pour compléter ce que dit Yvan :lol:, je dirais même plus, PHP voit l'occurrence de table qui est sous-jacente au modèle, donc le contexte* relationnel lié à cette occurrence. Cela signifie qu'il faut donc créer des points de vue dans le graphe de liens qui seront utilisés par la publication web. A ne surtout pas mélanger avec les points de vue utilisés par l'interface FileMaker Pro, au risque de tout "péter" !!!

(*) Le contexte... tiens ça faisait longtemps :w00t:

Link to post
Share on other sites
  • 0

Une simple question ?

- Le booking doit-il être interfacé avec les bases de compagnies aériennes et/ou voyagistes ?

Cela permettrais d'éclairer rapidement la faisabilité en "tout" FMP... ou pas ;)

Maxence, bouc émissaire :P

Link to post
Share on other sites
  • 0

A ne surtout pas mélanger avec les points de vue utilisés par l'interface FileMaker Pro, au risque de tout "péter" !!!

Hello Olivier,

tu peux un peu développer, stp ?

Tu veux dire que, même si on a des modèles spécifiques pour la publi PHP, il est déconseillé de les appuyer sur des OT pouvant servir dans FMP, et de plutôt "dupliquer" des parties du graphe ? Et pourquoi ?

Tiens, en passant, une petite remarque que j'ai lu ailleurs et que je cite (sans l'avoir moi-même testée à fond, bien que ça tombe sous le sens) :

il est apparemment mieux de prévoir des modèles contenant uniquement ce qui est nécessaire à une page PHP donnée. (rapidité, etc.)

Si tu as par exemple un modèle dédié à PHP avec des TE, rubriques, listes... utilisé par trois pages web qui en exploitent chacune 30%, il vaut mieux créer 3 modèles, qui ne contiendront chacun que les 30% requis.

Link to post
Share on other sites
  • 0

C'est bien ce que je veux expliquer. Un modèle est fait "à la base" pour créer une interface utilisateur. Il est donc relié à une occurrence de table et son graphe... un contexte quoi ;)

Dans le cas de la publication PHP, il faut raisonner comme une nouvelle interface utilisateur, pas au sens graphique, mais "datas", l'aspect graphique étant assumé par les scripts PHP et l'HTML. J'incite dons les développeurs web à créer des modèles dédiés aux besoins d'une et une seule interface web car dans ce cas on optimise les données utilisées et retournées par FileMaker à PHP.

En résumé, si j'ai besoin d'un formulaire de recherche pour une page web, je crée un modèle avec les rubriques et listes de valeurs nécessaires à ce formulaire web. Ensuite, si je fais une recherche avec ce formulaire et que j'ai besoin d'une liste de réponse des enregistrements trouvés, je crée un modèle avec les rubriques utilisées par la recherche, le tri éventuel et affichées dans la liste de réponse.

Bref à chaque action web il faut quasiment un modèle qui crée un contexte optimisé. Et il y a de grandes chances que ces contextes ne correspondent pas à ceux utilisés pour les interfaces utilisateurs. Il y a aussi le risque de faire évoluer les interfaces pour les besoins utilisateurs et de supprimer des rubriques ou modifier des liens, des nom d'occurrences de tables, etc, et dans ce cas, rendre inopérants les développements web.

Donc, faire des graphes de liens et des modèles séparés pour les besoin web est une "bonne pratique"comme disent les ricains.

Link to post
Share on other sites
  • 0

OK, donc pour les modèles on est bien d'accord.

Pour le renommage éventuel des OT, c'est vrai que c'est un risque, et un bon argument.

(mais le problème de renomage est le même pour les rubriques, listes, etc. )

Mais, ceci mis à part et en considérant un dev fini où plus rien ne bouge, y a-t-il, comme pour le modèle dédié, une autre raison majeure d'utiliser des OT/GOT dédiés ?

Merci de ces éclaircissements, ce genre de choses théoriques un peu poussées sur la publi web étant finalement très mal documentées... ;)

PS : désolé Tarick pour l'utilisation de ton post, mais je me suis dit que ce n'était pas tout à fait H.S. ;)

Edited by lem alpha
Link to post
Share on other sites
  • 0

Dans un modele FM utilisé par un client FM, les données sont calculées / liées au fur et à mesure de leur affichage. Quand on arrive sur la fiche num 3, les calculs non stockés de cette fiche sont effectués, les liens sont mis à jour, etc...

Comme (en gros) on ne travaille que sur un enreg (au pire qques uns), ca ne pose pas réellement de problème.

Ca, c'est ce que j'ai compris.

Maintenant, ce que j'ai constaté :

Maintenant, quand tu travailles avec un modèle utilisé par PHP, TOUS les calculs et TOUS les liens vont être mis à jour pour l'ensemble de TOUS tes enregs de ton GOT quand tu fais une requête. Donc, ca fait du boulot, et si tu fais des choses "inutiles" (champs, calcul ou lien présents alors que cela n'est pas nécessaire), les perfs s'en ressentent méchamment.

Ma règle : "si c'est inutile, on l'enlève. Si c'est utile, voir comment on pourrait s'en passer".

Donc, oui, quand tu fais tu PHP, il faut travailler avec un contexte minimal du coté de FMP.

Yvan

Link to post
Share on other sites
  • 0

champs, calcul ou lien présents alors que cela n'est pas nécessaire

Ah oui, ça va jusque là... Effectivement ça fait un argument supplémentaire.

Je concevais bien le fait que tout ce qui est sur le modèle allait être évalué/calculé/pris en compte, mais je n'étendais pas le raisonnement aux liens.

Bon de toute façon, Olivier m'avait déjà convaincu, et ça va me faire du boulot...

Comme dit, c'est dommage que ce genre de choses ne soit pas mieux documenté, ça permettrait de partir de suite sur des bases saines...

Rajouter un modèle dédié ça va (à peu près), mais recréer des GOT et modifier ses pages PHP en conséquence a posteriori, arf...

Link to post
Share on other sites
  • 0

Prend le pb dans l'autre sens : regarde ce qu'il te faut en php, et créé tes modèles / got en fonction.

Les choses qui seront à modifier en php sont

- le nom des modèles utilisés (perso, je préfixe tous les modèles php par "php_". Le truc vachement original, quoi...)

- la création des calculs (il est souvent préférable de refaire le calcul dans php que de le faire dans fm)

Pour ce qui est de la doc, il faut reconnaitre qu'elle est assez peu étoffée en anglais, et franchement maigrichonne en français.

Yvan

Link to post
Share on other sites
  • 0

Re...

(Tarick, tu nous vires quand tu veux ;) )

bien sûr que je prendrais dorénavant le problème comme ça, mais là j'ai une série de pages PHP qui tournent déjà avec des modèles dédiés (préfixe WEB_), des scripts dédiés (préfixés), mais juste sur mes OT "classiques"...

Donc faudra juste que je fasse des petits rechercher-remplacer dans mon code PHP... :D

Pour ta remarque sur les calculs, tu peux préciser de quels "calculs" tu parles ? (ou donner des exemples)

C'est votre faute aussi, à chaque réponse vous rajoutez un élément intéressant qui m'interpelle... :blush:

Link to post
Share on other sites
  • 0

Imaginons un truc tout à fait hors du commun : l'affichage d'une facture (oui, je sais, on se demande où je vais chercher des exemples aussi tordus).

Le montant total de cette facture est dans une rubrique calculée non stockée (oui, je sais, il ne faut jamais faire ce genre de truc sans précaution, mais là c'est juste pour l'exemple), qui est égal à somme des lignes.

L'idée, c'est de ne pas mettre le champ "total" dans le modèle, mais au contraire de le recalculer à la demande via php.

Si tu le mets dans le modèle, le total de toutes les factures va être recalculé à chaque fois.

Si tu le mets dans php, tu te cognes en php la somme des lignes (éventuellement via une TE dans ton modèle web_facture, ou via un autre modèle web_facture_lignes qui va contenir uniquement les lignes. Pour choisir entre les deux, il faut faire des chronos sur des tables représentatives).

J'espère avoir été clair.

Yvan

Link to post
Share on other sites
  • 0

L'idée de fond est que FileMaker Server n'est pas optimisé pour la publication web. Son premier job est de servir des clients FileMaker. C'est pas MySQL ou MS SQL Server. Donc plus on optimise le contexte dans lequel PHP requête FileMaker Server plus c'est efficient et moins on est sujet à des problèmes de tenue en charge.

Donc on en demande le moins possible à FileMaker Server. GOT minimaliste, le scrict nécessaire pour les rubriques sur les modèles utilisés par PHP. Et on fait bosser le plus possible PHP.

Pour la petite histoire, je me souviens même avoir optimisé un site en faisant 2 requêtes (1 à la table principale, récup de l'ID de jointure, puis 1 avec cette ID pour obtenir les enregistrements liés) plutôt que de faire une seule requête sur un modèle avec une table externe. Je ne me souviens plus précisément du contexte exact, mais ça avait nettement amélioré les temps de réponse (benchmark à l'appui).

Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Answer this question...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...