A voir également:
- Script pour prendre rendez vous
- Script vidéo youtube - Guide
- La poste est prête à prendre en charge votre envoi. dès qu'il nous sera confié, vous pourrez suivre son trajet ici. - Forum Consommation & Internet
- Prendre photo avec webcam - Guide
- Prendre une photo avec son mac - Guide
- Prendre un instantané pdf ✓ - Forum PDF
2 réponses
Yo,
bon avant php il faut d'abord une base de données, parce que php une fois que tu as fermé ton navigateur voire changé de page il retiendras aucune information(donnée).
de réservation de plages horaires ou prise de rendez-vous
mysql est une base typique est gratuite, il en existe plein avec chacune leur spécificité. mysql en plus d'être gratuit à l'avantage d'être simple, rapide, en revanche il est limité dans d'autres domaines.
Je vais dégrossir un peu cette étape, pas au niveau technique mais conceptuel, les données minimum dont à besoin l'ensemble de l'application:le système de gestion des bases pour les intimes.
_Une date de rendez-vous, jour mois, année et une heure de rdv(heure, minute)
_Le nom de la personne avec lequel on a un RDV
_Le nom de la personne qui doit se rendre au RDV
Il y a là le strict minimum pour gérer le truc:
Une fois chacune de ces informations dans la base toutes les fonctionnalités dont tu parles sont déductibles(oon les dit calculables); par exemple:
Donner la possibilité aux membres du site de choisir leur rendez-vous dans la plage horaire de leurs choix en fonction des disponibilités restantes
En effet l'on enregistre que Mr Machin a RDV avec MR Truc le 23 Mai 2010 à 17h30. Lorsque que l'on affiche un calendrier toutes les dates/plage horaires sont possible sauf le 23 Mai 2010 à 17h30.
On admet pour la démonstration que Mr Machin n'est pas bête et ne va pas prendre des RDV les jours ou il ne travaille pas, le dimanche par exemple et pendant ses congés et qu'il peut estimer la durée d'un RDV et son temps de déplacement. Cependant toute ces informations sont bien des données que l'on DEVRAIT retenir pour que le programme empêche les erreurs.
Nou nous aperçevons aussi que la date du RDV est composée en fait de plusieurs données au lieu d'en être une seule:
_Le jour, le mois, l'année peuvent être regroupées en une seule
_L'heure et les minutes doivent être indépendants puisqu'on peut à un jour donnée avoir plusieurs RDV
J'ai parlé du minimum de données mais on peut en rajouter de façon illimitée, voici quelques unes des plus évidentes:
_Le lieu du RDV(lui aussi est en fait composé de plusieurs données qui pour plus de rigueur doivent être séparées: Ville, Rue+numéro de rue, Bâtiment s'il y a lieu, Code Postal).
et comme vu dans l'exemple de Mr Machin:
_La période de congés(2 données distinctes: un début et une fin)
_Le type de RDV s'il y a lieu d'avoir plusieurs types
_La durée (moyenne) d'un RDV
et bien d'autres:
_L'issue du RDV
_Du matériel nécessaire à emporter
_etc...
En retenant le lieu de RDV la personne qui doit s'y rendre peut évaluer son temps de trajet. On peut bien sûr ajouter cette information dans la base de données(un temps de trajet moyen donc la distance à parcourir, le moyen de transport...) ce qui permets d'éviter les erreurs au maximum.
Retenir la période de congés évite l'erreur humaine de pouvoir prendre un RDv alors que l'on n'est pas présent, le logiciel bloqueras/avertiras la prise d'un RDV pendant ces périodes.
Le type de RDV est dépendant du besoin d'avoir à indiquer ce type; exemple s'agit t'il d'un entretien commercial pour vendre ou d'un service à domicile(différencier plusieurs personnes et leur compétences; à voilà encore d'autres données qui permettront éventuellement de remplacer ou attribuer un RDV à quelqu'un fonction de ses compétences)
La durée d'un RDV permet que le logiciel puisse avoir une marge horaire entre chaque prise de RDV
L'issue du RDV une autre information qui peut être capitale suivant la nature de l'activité entreprise.
Le matériel une autre données réduisant la marge d'erreur/le temps de travail humain ou pouvant servir à obtenir facilement les dépenses dans le cas d'une infirmière devant utiliser des compresses lors d'une visite médicale.
Ce tri est un travail intellectuel nécessaire qui assure la pertinence du logiciel, la durée dans le temps(on doit pouvoir prévoir que l'on aura à rajouter des trucs maintenant sans changer tout le système donc pas repartir de zéro si l'on veut/doit diversifier ou ajouter des fonctionnalités(investissement réduit le cas échéant, gouffre financier dans l'autre cas), éviter que le logiciel puisse retenir des données erronées, assurer la simplicité d'utilisation(le but 1er de toute outil: gagner du temps pas en perdre)...)
Bon pour répondre à ta question sinon l'idéal serait de s'orienter vers un CMS, quant aux trucs tout fait ils auront toujours l'inconvénient de ne pas être adaptés au spécificités de ton activité, ce qui comme j'ai essayé de le démontrer peut compliquer la chose plutôt que l'améliorer et provoquer des erreurs ou omissions(perte de temps là encore).
bon avant php il faut d'abord une base de données, parce que php une fois que tu as fermé ton navigateur voire changé de page il retiendras aucune information(donnée).
de réservation de plages horaires ou prise de rendez-vous
mysql est une base typique est gratuite, il en existe plein avec chacune leur spécificité. mysql en plus d'être gratuit à l'avantage d'être simple, rapide, en revanche il est limité dans d'autres domaines.
Je vais dégrossir un peu cette étape, pas au niveau technique mais conceptuel, les données minimum dont à besoin l'ensemble de l'application:le système de gestion des bases pour les intimes.
_Une date de rendez-vous, jour mois, année et une heure de rdv(heure, minute)
_Le nom de la personne avec lequel on a un RDV
_Le nom de la personne qui doit se rendre au RDV
Il y a là le strict minimum pour gérer le truc:
Une fois chacune de ces informations dans la base toutes les fonctionnalités dont tu parles sont déductibles(oon les dit calculables); par exemple:
Donner la possibilité aux membres du site de choisir leur rendez-vous dans la plage horaire de leurs choix en fonction des disponibilités restantes
En effet l'on enregistre que Mr Machin a RDV avec MR Truc le 23 Mai 2010 à 17h30. Lorsque que l'on affiche un calendrier toutes les dates/plage horaires sont possible sauf le 23 Mai 2010 à 17h30.
On admet pour la démonstration que Mr Machin n'est pas bête et ne va pas prendre des RDV les jours ou il ne travaille pas, le dimanche par exemple et pendant ses congés et qu'il peut estimer la durée d'un RDV et son temps de déplacement. Cependant toute ces informations sont bien des données que l'on DEVRAIT retenir pour que le programme empêche les erreurs.
Nou nous aperçevons aussi que la date du RDV est composée en fait de plusieurs données au lieu d'en être une seule:
_Le jour, le mois, l'année peuvent être regroupées en une seule
_L'heure et les minutes doivent être indépendants puisqu'on peut à un jour donnée avoir plusieurs RDV
J'ai parlé du minimum de données mais on peut en rajouter de façon illimitée, voici quelques unes des plus évidentes:
_Le lieu du RDV(lui aussi est en fait composé de plusieurs données qui pour plus de rigueur doivent être séparées: Ville, Rue+numéro de rue, Bâtiment s'il y a lieu, Code Postal).
et comme vu dans l'exemple de Mr Machin:
_La période de congés(2 données distinctes: un début et une fin)
_Le type de RDV s'il y a lieu d'avoir plusieurs types
_La durée (moyenne) d'un RDV
et bien d'autres:
_L'issue du RDV
_Du matériel nécessaire à emporter
_etc...
En retenant le lieu de RDV la personne qui doit s'y rendre peut évaluer son temps de trajet. On peut bien sûr ajouter cette information dans la base de données(un temps de trajet moyen donc la distance à parcourir, le moyen de transport...) ce qui permets d'éviter les erreurs au maximum.
Retenir la période de congés évite l'erreur humaine de pouvoir prendre un RDv alors que l'on n'est pas présent, le logiciel bloqueras/avertiras la prise d'un RDV pendant ces périodes.
Le type de RDV est dépendant du besoin d'avoir à indiquer ce type; exemple s'agit t'il d'un entretien commercial pour vendre ou d'un service à domicile(différencier plusieurs personnes et leur compétences; à voilà encore d'autres données qui permettront éventuellement de remplacer ou attribuer un RDV à quelqu'un fonction de ses compétences)
La durée d'un RDV permet que le logiciel puisse avoir une marge horaire entre chaque prise de RDV
L'issue du RDV une autre information qui peut être capitale suivant la nature de l'activité entreprise.
Le matériel une autre données réduisant la marge d'erreur/le temps de travail humain ou pouvant servir à obtenir facilement les dépenses dans le cas d'une infirmière devant utiliser des compresses lors d'une visite médicale.
Ce tri est un travail intellectuel nécessaire qui assure la pertinence du logiciel, la durée dans le temps(on doit pouvoir prévoir que l'on aura à rajouter des trucs maintenant sans changer tout le système donc pas repartir de zéro si l'on veut/doit diversifier ou ajouter des fonctionnalités(investissement réduit le cas échéant, gouffre financier dans l'autre cas), éviter que le logiciel puisse retenir des données erronées, assurer la simplicité d'utilisation(le but 1er de toute outil: gagner du temps pas en perdre)...)
Bon pour répondre à ta question sinon l'idéal serait de s'orienter vers un CMS, quant aux trucs tout fait ils auront toujours l'inconvénient de ne pas être adaptés au spécificités de ton activité, ce qui comme j'ai essayé de le démontrer peut compliquer la chose plutôt que l'améliorer et provoquer des erreurs ou omissions(perte de temps là encore).
