Pour m'occuper un peu et pas trop perdre la main en dev web java, je voudrais me faire un petit moteur de blog en Java.
 
je me pose des questions :  
- sur l'archi en elle-même
- sur la vue
 
pour l'archi je compte faire un truc classique en 3 couches, et surement utiliser Spring, pour voir la tete que ca a.
 
pour la vue c plus problématique : je voudrais qqc qui soit customizable.
 
il faut : préparer les données à afficher --> structurer la page --> lui appliquer un style
A la rigueur, les 2 premiers n'ont pas besoin d'être customizables, mais le dernier oui...
 
Y'a cette technique, que j'ai déjà mis en oeuvre, g cru mourir tellement c bloaté :  
http://www.javaworld.com/javaworld [...] sxslt.html
 
en gros ca consiste en aggréger les données à afficher dans un flux XML, lui faire subir une première transfo qui structure la page en le transformant en un pseudo HTML (1 xsl / page ou presque), et une seconde qui applique le style / créee le HTML (le XSL de celle ci étant commun à toutes les pages)
 
c laid parce que :  
- niveau perf c obligé de passer par XSLTC pour pas trop perdre
- faut limite une XSL par écran
- les XSL sont en général imbitables, c très difficile de pas mettre de controle dedans, et c franchement pas fait pour
 
j'avais pensé à faire des composants (menu, zones de "billets", titre, etc...) qui soient capable de se dumper en HTML
 
pour créer son template de blog, il suffirait de créer une JSP qui "appelle" ces composants, et leur demande de se dumper...ca me semble extensible parce que via la JSP on peut ajouter ses propres composants, mettre en forme la page, etc...et via la XSL, on peut meme changer l'apparence des composants existants...
 
si je suis bien, c aussi le concept de JSF non ? sinon dotclear semble fonctionner selon ce concept, via des fonctions à appeller...
 
vous en pensez quoi ? si vous avez de la littérature sur le sujet, ca m'intéresse...

up ?

up again

l'archi doit émerger toute seule.
 
tu fais une page bidon qui affiche un texte, ensuite tu la modifie pour qu'on puisse modifier le texte, tu modifie pour qu'on puisse avoir plusieurs textes sur la page, tu ajoutes de quoi afficher un nom d'utilisateur, tu ajoutes des droits, tu ajoutes des commentaires etc.
 
te fais pas chier avec du up-front

on est d'accord que le texte en question, il s'affiche parce que j'ai créé un service qui me fabrique un composant texte, et que ce composant sait se dumper en HTML ?

mais ça voudrait dire que ton composant (model) sait comment il est affiché (vue), donc s'pas cool.
 
enfin, je crois.

ben ce composant appartiendrait à la Vue si on raisonne en MVC...le modèle, c'est le contenu de la base, et les services qui permettent de fabriquer...
 
c comme un composant graphique swing, si ce n'est qu'il sait se transformer en HTML...

je parle pour moi là : en générale, j'ai des objets tout cons POJO qui représentent les données de la base. Les classes de service/dao instancient les objets, et leurs propriétés sont exposées par la JSP.  
 
Donc en gros, dans ton archi, en suivant ce raisonnement, il faudrait deux objets par éléments de modèle : un POJO, et un Helper, qui exposerait le POJO en html. et ici, le plus simple serait peut-être un tag jsp.
 
M'enfin, c'est que mon avis, et mon expérience n'est pas si longue que ça.

non, non, l'objet créé par les DAO sait lui meme s'afficher en HTML...
 
chaque objet aurait un toHTML()...c vraiment la logique des composants swing : la plupart ont un modèle (dans mon cas ca se résumerait le plus souvent à un objet String, ou date), et savent afficher les données du modèle via le fait que ce sont des composants..
 
d'après ce que j'ai compris, c'est aussi l'idée derrière JSF, et les .NET webforms...
 
dans ta JSP, tu crées ta structure de page, et tu dis : là je met un calendrier (hop, tu appelles un objet calendrier, qui sait montrer son état en HTML)), là je met un titre (idem, j'appelle un objet titre), là je mets ma liste de billets (objet complexe mais paramétrable, qui sait afficher n billets...après faut voir comment gérer la pagination, etc...)