Aller au contenu

paolodelmare

Hubmaster
  • Compteur de contenus

    280
  • Inscrit(e) le

  • Dernière visite

Messages postés par paolodelmare

  1. Jette un il à contao (ex typolight).

    C'est un des cms les plus sûrs et proprement codés.

    Le templating est en php, mais le système permet de gérer pas mal de choses depuis l'admin.

    Pour une boutique simple, l'extension catalog permet de réaliser simplement des listes diverses avec des champs personnalisés (produits, petites annonces)

    Si c'est pour du e-commerce (du "vrai"), prestashop est plus indiqué.

  2. Pour ceux qui ne seraient pas encore informés: webUx et Sudweb sont deux conférences web d'envergure qui auront lieu à Nimes le 26 et 27 mai prochain.

    L'initiative est sympathique et participe à décentraliser de la capitale ce genre d'évènements.

    Les inscriptions sont ouvertes.

  3. Tu peux évidemment développer un système de sauvegarde: ça peut se faire à la demande, ou à intervalle réguliers, via un cron par exemple. Tu peux y inclure un dump de la base, si elle n'est pas trop volumineuse.

    Attention toutefois à la manière dont le client va récupérer sa sauvegarde, afin de ne pas risquer d'exposer des données sensibles: utiliser un protocole adéquat (ssl, ssh etc).

    Si tu veux une fonctionnalité d'undo dans ton admin, il faut versionner chaque modif de chaque champ important et en conserver un historique limité. Ainsi, l'utilisateur peut revenir en arrière et annuler ses changements.

  4. Il est préférable d'éviter de parler de black sur un forum, fréquenté par des prestataires qui ont le plaisir de payer des charges.

    Vu la pléthore d'outils existants,il est difficile de faire son choix. Dans tous les cas, il y aura une phase d'apprentissage pour maitriser le cms et le système de templates.

    Si tu penses à faire du travail collaboratif, tu devras évaluer le workflow de validation des solutions envisagées pour qu'il te convienne.

    Dans ton cas, un moteur de wiki pourrait être envisagé.

  5. Assembler différents scripts avec des bouts de ficelles, c'est jamais terrible. Chaque adaptation nécessite de la part du développeur des compétences sur l'outil concerné.

    De surcroit, les différences d'ergonomie des divers backoffices risquent d'être pénibles pour les administrateurs., sans compter les problèmes de maintenance/sécu évoqués par Patrick.

    Question coût, c'est bien trop vague. Il y a un bon travail de spécification et de prototypage à réaliser en amont, notamment pour le workflow de validation des données utilisateurs.

    Les fonctionnalités requises sont classiques et font partie de la panoplie d'outils constituée par tout développeur/agence. Le niveau d'adaptation requis va influer directement sur le devis.

    Ça peut se développer sous joopal et consorts, mais je suis d'avantage partisan d'un dev spécifique.

  6. Je suis entièrement d'accord sur les compatibilités avec php4.

    Quant à django, mon avis est fait depuis longtemps. En termes de puissance et de robustesse, c'est symfony (voir ce slidede Nicolas Perriault )

    Après, comme je l'écrivais, un fw ou un language, ça doit te convenir. Prends toi 1 journée pour essayer si tu es curieux, tu te feras une idée plus objective que ce que je pourrai t'en dire.

  7. Premièrement, je développe avec un framework python (django), je ne te serais pas d'une grande aide au niveau implémentation php.

    Je travaille en définissant des blocs de contenus dans une classe. Par exemple, un bloc texte va contenir le texte proprement dit, un classe et un id css.

    Chaque page contient des blocs de contenus agencés selon le bon vouloir du rédacteur. Les pages peuvent contenir des champs communs (les méta par exemple, ou le statut de publi).

    Le tout est traduit en db (par le framework) avec des relations adéquates.

    Chaque type de champ dispose de ses propres validateurs (c'est dans le framework).

    Donc on se retrouve avec une table par type de bloc de contenu.

    Le design pattern est un mvc (en toute rigueur c'est un modele template view)

    Quand une requête est reçue, le script détermine dans une liste de patterns d'url la plus adaptée, lui fait correspondre une vue.

    La vue va piocher dans la db en fonction du modèle les données nécessaires et alimente un template .

    Par backend je désignais l'interface d'admin (auto générée par le framework)

  8. C'est évidemment possible. Je développe ce type de solutions pour certains clients qui ont plusieurs sous domaines ou domaines.

    Ça finit par générer pas mal de requêtes, mais ça reste très raisonnable, et la génération des pages reste très rapide. De plus, un système de cache et les optimisations de bases donnent d'excellents résultats.

    Par contre, j'évite de gérer différents clients sur un même backend. Ça complique la gestion de la sécurité, notamment avec des sites qui offrent des fonctionnalités parfois très différentes.

    Mais ça se fait couramment sur toutes les plateformes de blogs.

    Wordpress par exemple, dispose d'une option multisites (anciennement dans wp mu)

  9. La méthode est par définition conçue pour la modélisation OO.

    Cependant certains diagrammes sont utilisables: diagramme de navigation, cas d'utilisation, maquettes, diagramme d'interaction.

    Ceci dit, si tu veux développer sérieusement, la POO est juste indispensable.

  10. L'installation d'une solution CMS nécessite de la part du prestataire une modification, amélioration, rajout de modules,fichiers et sa configuration suivant les paramètres techniques des serveurs, donc il y a que le prestataire qui a fait tout le boulot qui peut vraiment faire quelque chose en cas de dysfonctionnement à moins de repartir à zéro ce qui n'est pas évident en matière de commerce !!!

    C'est vrai que la reprise d'ouvrage est parfois délicate sur une solution CMS.

    Sur une solution hébergée c'est juste pas possible.

×
×
  • Créer...