dans le XVII tu trouves en fonctionnel :
- un moteur en client/serveur pour gerer des graphes et collections de graphes
- une API de requetes pour interoger le moteur
- un ensemble d'objets pour mapper des objets perl sur des sous-graphes
- un langage de templating pour faire du rendu de contenu
- un modele de donnée pour le rendu via des templates
- un toolkit SJAX/AJAX
- un ensemble d'objets pour mapper des objets JS sur des sous-graphes
- une GUI web assez moche mais tres efficace pour presque tout faire sans un shell
par contre, il peut manquer plein de petits trucs cool comme outils pour que cela soit tip-top :(
le probleme du SQL est qu'il n'est pas adapté à ce type d'usage.
un noeud dans un graphe contient un ensemble d'attribut typé.
le typage est dynamique par l'intermédiaire des classes d'objets pour le mapping.
[^] # Re: le modele relationnel est peu compatible avec la gestion des graphes
Posté par Mouns . En réponse au message Modéliser un gros graphe. Évalué à 2.
- un moteur en client/serveur pour gerer des graphes et collections de graphes
- une API de requetes pour interoger le moteur
- un ensemble d'objets pour mapper des objets perl sur des sous-graphes
- un langage de templating pour faire du rendu de contenu
- un modele de donnée pour le rendu via des templates
- un toolkit SJAX/AJAX
- un ensemble d'objets pour mapper des objets JS sur des sous-graphes
- une GUI web assez moche mais tres efficace pour presque tout faire sans un shell
par contre, il peut manquer plein de petits trucs cool comme outils pour que cela soit tip-top :(
le probleme du SQL est qu'il n'est pas adapté à ce type d'usage.
un noeud dans un graphe contient un ensemble d'attribut typé.
le typage est dynamique par l'intermédiaire des classes d'objets pour le mapping.