Réflexion architecturale

Répondre


Cette question est un moyen d’empêcher des soumissions automatisées de formulaires par des robots.
Smileys
:D :) :( :o :shock: :? 8-) :lol: :x :P :oops: :cry: :evil: :twisted: :roll: :wink: :!: :?: :idea: :arrow: :| :mrgreen: =D> #-o =P~ :^o :non: :priere: 8-|
Voir plus de smileys
  Revue du sujet
 

  Étendre la vue Revue du sujet : Réflexion architecturale

par Sékiltoyai » 05 sept. 2007, 21:59

Tiens, je m'attendais pas à te voir par là :)

Ecoute, je ne suis pas persuadé, il y a certaines choses un peu spécifiques dans mon projet dont je doute qu'elles existent… Mais si tu as un lien ou des explications détaillées, pourquoi pas…

par B.Moncef » 05 sept. 2007, 21:19

Bonjour,

En fait Sekil, si je comprends bien ce que tu veux expliquer, je crois qu'un projet de la sorte est deja en cours. My WebSite Plugins.

En fait le projet est base sur ZF. Au debut on comptais tous faire nous meme, mais a la sortie de la 1.0.0 de ZF, on a decide de se baser dessus.

En gros c'est un script qui reunis beaucoup de modules, news, chat, livre d'or, etc. et qui peut etre utilise a la fois comme CMS complet, ou bien n'en utiliser que certains modules dans un site deja fait, comme les news ou le livre d'or.

Je ne sais pas si c'est exactement ce que tu comptais faire.

par naholyr » 28 août 2007, 10:52

J'ai aussi beaucoup aimé le système d'autoload que j'ai même bourrinement amélioré personnellement : au lieu de se baser sur le nom de fichier, on parse tous les .php à la recherche de définition de classe :P (de toute façon ça n'est fait qu'une fois et mis en cache, donc autant y aller sans douceur).
Cela me permet d'utiliser des librairies mal nommées (comme par exemple NuSoap dont les noms de fichier sont un grand n'importe quoi), mais c'est surtout pour le côté gadget qui-se-la-pète :lol: ;)

par pascaltje » 28 août 2007, 10:41

alors qu'est-ce que ça donne ?

pour le coté modularité, l'approche de symfony est chouette :
_ installation d'un module via pear
_ code non pollué: le module/plugin se trouve dans /plugin/NomDuPlugIn
_ on peut personnaliser le module simplement, par un système "d'écrasement" de fichier, mais la config de base est toujours là

qu'en est-il des schémas ?

A+

Pascal

par Sékiltoyai » 25 août 2007, 11:46

Je me faisais justement cette remarque en lisant le sujet : attention quand même à pas trop partir dans l'abstraction, c'est comme ça qu'on en arrive à pondre une usine à gaz :roll: Il ne faut pas perdre de vue le besoin.
Mais je ne cherche pas à faire quelquechose d'ultra performant, pour cela, on programme en procédural et on optimise toutes les lignes. Et même mieux, on troque le php pour autre chose. je suis plutôt dans les optiques que j'ai donné, sans pour autant exécuter 10 lignes de code de gestion pour une ligne de code productif.

par Calimero » 25 août 2007, 11:41

Hein ?
Non, là tu n'y es pas du tout, c'est une conception architecturale beaucoup plus abstraite. Ca ne se résume surtout pas à changer la sortie texte d'un script. C'est toute la gestion du script qui est concernée.
Je me faisais justement cette remarque en lisant le sujet : attention quand même à pas trop partir dans l'abstraction, c'est comme ça qu'on en arrive à pondre une usine à gaz :roll: Il ne faut pas perdre de vue le besoin.

par momox » 25 août 2007, 11:32

Quand je disais ca, c'était pour résumer, car j'ai parfaitement compris ce que tu souhatais voir, c'est un exemple parmi tant d'autres non?
Enfin bon, on pense ptet pas le framework de la même facon non plus...

par Sékiltoyai » 25 août 2007, 02:06

Donc ce que tu aimerais, c'est une classe de forum qui ne retourne pas de code html mais un tableau plutôt que tu puisses mettre en forme par la suite?
@+
Hein ?
Non, là tu n'y es pas du tout, c'est une conception architecturale beaucoup plus abstraite. Ca ne se résume surtout pas à changer la sortie texte d'un script. C'est toute la gestion du script qui est concernée.

par momox » 25 août 2007, 00:09

Oui, en effet, j'ai bien insisté au niveau de l'utilisateur, mais le fait est que pour permettre à l'utilisateur de construire lui même son site, avant de lui fournir des outils super évolués pour le faire, il faut lui donner la structure.
On était parti d'une réflexion sur les forums, et j'avais justement dit que pour moi, le plus gros problème des forums est leur manque, d'une part de modularité, et d'autre part de possibilités de transparence au niveau des modules de même type (j'appelle transparence le fait que l'on puisse utiliser indifféremment 2 modules sans que l'application n'ai un comportement différent). Et le problème est pour moi de taille quand l'on voit, et cela a encore été souligné dernièrement, le monolythisme du plus gros script de forum du monde, qui est impossible à modifier sans justement modifier le code. Il est là le concept.
Donc le principe est là, et comme je l'ai dit, bien évidemment ensuite, le but est de fournir des outils d'administration plus ou moins évolués à l'utilisateur pour modeler son site, et ce de manière plus ou moins assistée, de manière à ce que le résultat convienne aussi bien à un utilisateur confirmé qu'à quelqu'un qui n'a pas de culture en informatique. Ces outils étant bien entendu là aussi modulable, et totalement dispensables pour le fonctionnement de l'application qui doit faire le minimum de choix techniques possibles, laissant le total contrôle des outils à installer à l'utilisateur.

Sur le fait que tu dis que c'est impossible de fournir une interface d'administration, comme je t'ai dit l'idée est de fournir le maximum, même si l'utilisateur lambda ne peut au final pas forcément maîtriser la totalité des fonctionnalités de l'application, on a quand même au final une structure qui permet plus de modularité, et ce serait une grande avancée par rapport à actuellement puisqu'amha, on part de loin. Donc quitte à faire une structure très permissive en développements et une administration qui l'est moins que le contraire.

Si tu veux, je suis bien entendu près à te donner des détails (je peux même te transmettre les shémas que je suis en train de faire en message privé vu qu'apparement tu es le seul intéressé). Par contre, si tu veux des précisions ce serait plus sur quels points ?
Donc ce que tu aimerais, c'est une classe de forum qui ne retourne pas de code html mais un tableau plutôt que tu puisses mettre en forme par la suite?
@+

par Sékiltoyai » 24 août 2007, 19:01

Ok, je vais les numériser dans les prochains jours alors (c'est surtout du texte à tapper en fait :) )

par Hywan » 24 août 2007, 18:58

Hey :)

Oui j'aimerais bien tes schémas. Je te poserais plus de questions suite à ça. Je suis dans le retour des vacances, j'ai (enfin) terminé de trier mes 4470 spams*, j'ai terminé de ranger toutes les affaires etc. Je vais mettre un peu de temps à me remettre dans le train train de la programmation, donc commence par m'envoyer tes schémas ;-).

Merci :).

* sérieux, 4470 spams en 24 jours devient invivable ...

par Sékiltoyai » 24 août 2007, 18:48

Oui, en effet, j'ai bien insisté au niveau de l'utilisateur, mais le fait est que pour permettre à l'utilisateur de construire lui même son site, avant de lui fournir des outils super évolués pour le faire, il faut lui donner la structure.
On était parti d'une réflexion sur les forums, et j'avais justement dit que pour moi, le plus gros problème des forums est leur manque, d'une part de modularité, et d'autre part de possibilités de transparence au niveau des modules de même type (j'appelle transparence le fait que l'on puisse utiliser indifféremment 2 modules sans que l'application n'ai un comportement différent). Et le problème est pour moi de taille quand l'on voit, et cela a encore été souligné dernièrement, le monolythisme du plus gros script de forum du monde, qui est impossible à modifier sans justement modifier le code. Il est là le concept.
Donc le principe est là, et comme je l'ai dit, bien évidemment ensuite, le but est de fournir des outils d'administration plus ou moins évolués à l'utilisateur pour modeler son site, et ce de manière plus ou moins assistée, de manière à ce que le résultat convienne aussi bien à un utilisateur confirmé qu'à quelqu'un qui n'a pas de culture en informatique. Ces outils étant bien entendu là aussi modulable, et totalement dispensables pour le fonctionnement de l'application qui doit faire le minimum de choix techniques possibles, laissant le total contrôle des outils à installer à l'utilisateur.

Sur le fait que tu dis que c'est impossible de fournir une interface d'administration, comme je t'ai dit l'idée est de fournir le maximum, même si l'utilisateur lambda ne peut au final pas forcément maîtriser la totalité des fonctionnalités de l'application, on a quand même au final une structure qui permet plus de modularité, et ce serait une grande avancée par rapport à actuellement puisqu'amha, on part de loin. Donc quitte à faire une structure très permissive en développements et une administration qui l'est moins que le contraire.

Si tu veux, je suis bien entendu près à te donner des détails (je peux même te transmettre les shémas que je suis en train de faire en message privé vu qu'apparement tu es le seul intéressé). Par contre, si tu veux des précisions ce serait plus sur quels points ?

par Hywan » 24 août 2007, 18:21

Bonjour bonjour :)

Je ressors le sujet de la poussière ! Je suis de retour de vacances, c'était super :P Les îles Lofoten valent le détour vraiment. Et le cap Nord : ça fait son petit effet. Bref. 9226 km, et toujours bien décider à comprendre ce que Sékiltoyai veut nous dire ;-) (au passage, je vais ouvrir un topic qui risque d'être intéressant, 24 jours de réflexions tout de même !).


Le sujet n'a pas tellement évolué depuis que je suis parti. Il aura fait seulement 4 jours. Mais je pense qu'il y a une idée intéressante derrière tout ça. Un CMS oriente déjà trop la façon d'utiliser un "système". On doit plus penser au niveau du Framework. Mais ce que je ne comprends pas, c'est que Sékiltoyai nous parle de l'utilisateur. J'imagine donc qu'on aura une interface pour construire l'application ? C'est ici que je te perds. Si je comprends ton idée, il faut améliorer l'approche de la programmation à la fin de la rendre plus évidente pour les profanes. Mais si un utilisateur doit toucher le code, c'est un "programmeur", du moins, il doit avoir des notions. Si tu ne veux pas qu'il touche le code, une application relais doit aider l'utilisateur à construire son application. Mais ça me semble bien impossible ...

Une autre chose, tu mets également en relief le fait d'avoir une interopérabilité des applications entre elles. Là encore, je ne vois pas 50.000 solutions. Seuls les standards peuvent résoudre ce problème. On va créer un PHPC (PHP Consortium) ? :P.


PS : ah oui, t'être que je ferais une petite compil' des photos des Norvèges. Si ça dit quelqu'un, n'hésitez pas à me demander ;-)

par fab » 04 août 2007, 01:58

Apres niveau perf c'est autre chose mais là c'est un maniac du ms qui parle ( un Hubert 2 )
Après tests de montée en charge sur un site que l'on vient de mettre en production, je suis très satisfait des perfs. Il faut bien penser qu'il y a des paramètres spécifiques à mettre en route en prod : limiter la quantité de logs, mettre en cache, supprimer le mode debug.

Rien qu'avec ça on a un rapport de 1 à 100 en terme de perfs par rapport au serveur de dev ;)
Je verrais bien pour l'instant je débute juste et j'apprend à manier le sql et les models mais bon j'avoue avoir peu de temps en ce moment pour ça :)

par Theri le Vorace » 03 août 2007, 23:19

Je suis actuellement en train de travailler sur symfony c'est vrai qu'il est très bien pensé et largement modifiable et implémentable :)
Légère digression
Je ressors.. :lol: