jmvanel
Modularisation en applications classiques (contacts, calendrier, ...)
This step
- create 2 companion SBT projects for projects catalog and contacts management
- dependency projects_catalog ---|> banana-rdf projects_catalog ---|> semantic_forms
- service /page in forms_play
- landing page in projects_catalog
- "applications" link near "tools" in generic application
NOTE: later the generic application should be extracted in a specific SBT project, leaving a core providing just the from generator and SPARQL cache.
The big picture
Ca fait longtemps que je pense à pouvoir créer des vues Scala XHTML templates, en particulier plusieurs pages d'accueil, sans manipuler le fichier routes: Use Scala XHTML templates without a special entry in conf/route for each #69 Et ça se précise. Je pense écrire un nouveau contrôleur Play générique, SemanticControler, qui répond sur /page à des requêtes telles que:
/page=dbpedia:CMS
Chacune de ces pages d'accueil renverra vers la fonctionnalité indiquée, ici CMS.
Via une simple map des URI vers l'implémentation. Les implémentations implémenteront ceci:
def result(request: Request): NodeSeq
sans dépendance à Play. On n'aura donc pas à manipuler le fichier routes à chaque fois.
De toute façon, comme vous savez, Play, a plusieurs inconvénients (instbilité, documentation insuffisante), et n'est pas le seul framework web Scala, il y a Scalatra, Lift, Spray.
L'URI donnée au service pourra être soit une fonctionnalité, résultant vers la page d'accueil de ladite fonctionnalité, soit celle d'une page afférente à cette fonctionnalité.
Les pages qui constituent une fonctionnalité pourront être gérées par une machine d'état, à la hypermédia (je crois que c'est Simon qui m'a parlé d'hypermedia l'autre jour).
En fait, ces URI et implémentations dans la map ne sont pas sans rapport avec celles dans la description formelle de SF: http://semantic-forms.cc:9112/forms.cc%3A9112%
c'est à dire:
Parmi ceux -ci , on s'intéresse à ceux destinés à l'utilisateur final, pas au développeur;
ce dernier correspondant plus ou moins à la page /tools .
Et on va ajouter:
- CMS
- blog
- forum
- annotation collaborative à la Diigo (sémantique bien sûr)
- gestion de contacts
- gestion de catalogue projets
- gestion de calendrier
- partage de ressources (lieux, matériel, etc)
Il y a là l'esquisse d'une ontologie (thésaurus disons) des applications les plus courantes pour les individus et communautés. On pourrait faire de même pour les entreprises.
Et bien sûr, chaque application va avec ses vocabulaires RDF.
Donc, pour résumer, à la place de l'unique page d'accueil de l'application générique, on va créer des pages d'accueil pour quelques applications typiques.
