Coincoin (Le premier qui dit panpan s'en prend une ;))
Bon, voilà, j'ai un problème métaphysique. les feuilles de style personnalisées c'est bien, mais je trouve pas ça encore assez marrant.
Donc l'idée que j'ai dans un coin, c'est en fait de fournir simplement de quoi faire sa propre page, en utilisant des données communes, en passant par un certain nombre de fonctions disponibles. En gros, on a quelque chose du genre :
SGBD --> fonction d'accès données --> diverses pages personnalisées
Bon, tout ça, c'est bien gentil, mais ... si les pages sont personnalisées", ça implique qu'elles ne devraient pas être hébergées sur le même serveur que le reste à priori.
Bon, donc il y a un vague transfert de données entre le serveur et le client. Alors deux choix s'offrent à moi :
* fournir juste les fonctions, et la page chez le "client" se démerde.
Avantage : très simple. Inconvénient : ça risque de générer un maximum de traffic (beaucoup de requêtes/réponses). Cet inconvénient est partiellement résolu dans la mesure ou le HTTP permet maintenant des connexions persistentes. Mais ça génère tout de même plus de hits que la normale.
* fournir un serveur/client de chaque côté. Chacun se charge de communiquer avec l'autre. Avantage : je peux ainsi regrouper les requêtes en une ou deux (moins de hits). Inconvénient majeur : faut avoir un serveur http de chaque côté.
Je sais d'avance que à priori la meilleure idée est la première, mais le problème est que souvent les hébergeurs marchent au nombre de hits/heure. Et si je fais ainsi, je fais exploser ce chiffre. C'est très artificiel, mais les faits sont là.
Donc je me retrouve plus ou moins dans l'incertitude. Personnellement, je sens mieux le premier, le second m'amuserait beaucoup à faire, histoire de toujours en apprendre plus, et je sais pas quoi faire.
De plus, peut-être qu'il y a d'autres solutions auquelles je n'aurai pas pensé.
Donc si quelqu'un a l'argument génial, l'idée génial, je suis clairement preneur.
Merci bien, et ... bon vent !
Forum Programmation.perl blogogoud ...
29
juin
2004
# panpan
Posté par Pinaraf . Évalué à 1.
Bon, perso je vois plutôt comme solution d'obliger le client à envoyer sa page perso dans un langage qui TU définis (surtout pas de PHP ou autres...) puis tu fais un mini-script PHP qui se charge de remplir la page...
Comme ça tout le boulot se fait côté serveur, sauf 1 envoi par modification de la page, ce qui n'est pas énorme encore...
# tu peux t'inspirer des squelettes de SPIP
Posté par Nap . Évalué à 2.
[^] # Re: tu peux t'inspirer des squelettes de SPIP
Posté par iznogoud . Évalué à 1.
Enfin bon. L'idée est effectivement celle-là. Le souci, c'est que chaque squelette est distant, sur un autre serveur que celui des données. Ce qui implique du traffic en données et surtout en hits/h. Parce que chaque balise php va faire l'objet d'une requête.
Alors oui, je pourrai, dans l'absolu, faire héberger les pages faites par les clients sur le serveur, ce qui simplifierait un peu la donne, mais qui m'oblige à faire un module permettant d'envoyer des pages sur le serveur, et surtout, de manière plus ou moins sécurisée. Je veux pas chopper des pages à la con, et j'ai un peu autre chose à faire que de controler chaque page. Je veux dire, je fournis mes fonctions d'accès et _rien d'autre_. Permettre d'envoyer sa page permet d'avoir accès à d'autres trucs fournis par le serveur. Ce que je ne veux pas.
# Soit j'ai rein compris.
Posté par Jerome Herman . Évalué à 3.
Tu fournis un ensemble de données hierarchisés, éventuellement une ou deux feuilles de style et tu laisse le soin aux personen qui veulent se greffer dessus de faire la mise en forme qui les interresse en incluant/excluant les données qu'ils veulent ou ne veulent pas.
C'est effectivement beaucoup plus puissant que les CSS persos, mais c'est plus complexe a gerer aussi...
Kha
[^] # Re: Soit j'ai rein compris.
Posté par iznogoud . Évalué à 1.
Je veux pas envoyer un fichier de 40Mo, là où parfois seuls 1Ko suffit.
Je veux dire, imagine une page qui n'affiche que les titres des journaux posté dans le blog. Sachant que les articles dépassent presque tous les 3000 caractères, et qu'il y en a quelques dizaines par mois (mais rien n'empêche d'en avoir beaucoup plus), je veux pas envoyer avec l'ensemble du contenu des articles.
L'idée est donc de pouvoir "sélectionner" les données à envoyer, avant de passer à l'étape de flux XML. Et cette selection n'est pas toujours magique. Je veux dire comment demander "je veux les vingt derniers articles parlant des mouches, sachant que tu m'as déjà dit qu'il y en avait 25" (exemple bidon, c'est le sachant que qui importe ici).
En gros, le dernier flot de donnée pourrait être conditionné par des requêtes précédentes.
Avec un système à deux serveurs, je dois pouvoir me démerder pour regrouper tout ça. Problème : faut deux serveurs, et une architecture "complexe".
[^] # Re: Soit j'ai rein compris.
Posté par Jerome Herman . Évalué à 2.
Je ne parlais pas d'un flux de données, mais d'un flux de catalogue (ce qui va sans dire va encore mieux en le disant).
Je pense a une achitecture du type :
[Object class="article" date="22/10/2002"]
[keywords]
grenouille
mouches
foret tropicale
amazonie
[/keywords]
[contenu]
[principal]
Url1
Url2
Url3
[/principal]
[illustrations]
Url1
Url2
Url3
[/illustrations]
[commentaires]
url1
url2
url3
[/commentaires]
[Liens]
url1
url2
url3
[/liens]
[/contenu]
[/Object]
Ca existe forcément.
Même si le catalogue est "gros" si on effectue que des appends dedans et aucune modification il y a possibilité d'utiliser le mode retrieve pour ne pas avoir a le retelecharger a chaque fois.
Partant de la on peut construire une CSS qui inclut exclusivement les articles interressant avec/sans les liens, les photos, les commentaires ...
Kha
[^] # Re: Soit j'ai rein compris.
Posté par iznogoud . Évalué à 1.
Tiens, j'profite d'être dans programmation.perl, pour demander si y'aurait pas quelqu'un qui veut jouer à chercher des failles dans mon blog ...
J'y ai récemment trouvé un petit bug (que je vais essayer de corriger ce soir), mais pas affolant. Logiquement le code est pas trop crade, donc ça devrait être faisable.
Le tout se trouve sur http://www.varaldi.org/dev/blogogoud.html(...)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.