Surveiller ce forum | 
Commencer une nouvelle discussion
| RE: Framework SVG intégré au fw ERGO W3C [ Répondre ] Par : Xavier PRINCE on 2007-02-19 01:43 | [forum:52497] |
|
Je pense qu'une solution indépendante du navigateur est primordiale dans le cadre de la fabrique ACube. Par rapport à cette nécessité et compte tenu des évolutions actuelles (cf. les posts de Steve), il me semble que l'approche Flex2 semble la plus pérenne. Sans compter qu'elle nous ouvrirait la porte vers de possibilité qui aujourd'hui ne sont pas visible dans les autres technologies (principalement une approche multimédia full : image, vidéo et son). |
|
| RE: Framework SVG [ Répondre ] Par : Xavier PRINCE on 2007-02-19 01:39 | [forum:52496] |
|
Pour le découpage je suis d'accord. Je propose d'intégrer à tout ceux-ci, au sein de la petie technique une couche de gestion des erreurs permettant : - soit de déclencher un rechargement de la page avec affichage de la page d'erreur, - soit d'appeler un des éléments de présentation avec affichage de l'erreur (sur le modéle du composant erreur du Framework Ergonomique) |
|
| RE: Framework SVG intégré au fw ERGO W3C [ Répondre ] Par : Jean Pierre ETIENNE on 2007-01-18 15:38 | [forum:52429] |
|
Suite à la publication du document explicatif de la maquette graphique et sa mise à disposition (Acube/Suivi/Developpers Feature Request Acube-FRED) Voici la procédure pour sa mise en oeuvre : 1/ Installer : Adobe SVG Viewer 6.0 (si vous ne trouvez pas, merci de me le signaler, je le mettrai à disposition). Aprés son installation copier les fichiers du répertoire : Program Files\Common Files\Adobe\SVG Viewer 6.0\Plugins (trois fichiers). vers le répertoire Plugins de FIREFOX. 2/ Configurer le serveur APACHE : Editer le fichier HTTPD.CONF du serveur Apache, pour ajouter un type MIME comme suit : # # TypesConfig describes where the mime.types file (or equivalent) is to be found. # TypesConfig conf/mime.types AddType *.svg image/svg+xml 3/ Décompresser l'archive (maquette_graphique.zip) dans le répertoire DocumentRoot 4/ L'ouvrir : http://localhost/maquette_graphique/index.html Le petit plus du viewer ADOBE : - CRTL + bouton gauche de la souris : défini une zone de zoom - ALT + bouton gauche + deplacement souris: permet de se déplacer dans le SVG - clic droit : ouvre le menu contextuel du plugin et permet par : original view de revenir à la taille initiale. Le plus petit plus de la maquette : - lors du deplacement de la souris sur un point représentatif d'une courbe ou un element d'histogramme une "bulle" donne la valeur exacte de l'élémént. (fonctionne bien sur, si l'on a au prealable fait le zoom d'une zone). - Composant à onglets . il apparait sur la sélection d'un pays . l'onglet selectionnné le reste lorsque l'on change de pays . il est effacé sur la selection d'un autre pays - Fenetres de presentation de données : . elles apparaissent sur la selection (clic gauche souris) d'un pays . pour les bouger, se placer sur l'entete + clic gauche et les deplacer . elles peuvent etre minimisées et évidemment maximisées (icone en haut, a droite de la fenetre) . elles sont effacées sur la déselection (clic gauche) du pays concerné. J'ai peut etre oublié quelques trucs et astuces, mais je pense que l'essentiel y est. |
|
| RE: Framework SVG intégré au fw ERGO W3C [ Répondre ] Par : Steve PEGUET on 2007-01-18 12:45 | [forum:52428] |
|
Il est certain que lors de la production de rapport la génération de courbes, camemberts.. est préférable de le faire côté serveur. Mais lors de consultation de données par l'intermédiaire d'un tableau issu du framework ERGO, il serait intéressant pour l'utilisateur de pouvoir aussi consulter ces données d'une manière graphique sans forcément avoir un développement supplémentaire à faire. Exemple : Programmation budgétaire, je suis entrain de saisir une programmation budgétaire à l'issue duquel je la consulte d'une manière globale à l'aide d'un tableau. Il serait intéressant pour voir la répartition de cette première saisie de la consulter sous la forme d'un camembert par exemple... Sinon je suis d'accord sur l'approche pragmatique de Benjamin de partir sur un framework technique maitrisant la compatibilité MSIE et Firefox partant sur le principe SVG inline justement pour éviter lors de la consultation d'un tableau de devoir rechercher le flux de données pour l'afficher sous la forme d'un camembert. |
|
| RE: Framework SVG intégré au fw ERGO W3C [ Répondre ] Par : Jean Pierre ETIENNE on 2007-01-17 15:19 | [forum:52426] |
|
Les différentes stratégie que l'on entrevoit (MSIE / FIREFOX) laisse présager bien des difficultés pour etre compatible avec tous les navigateurs. Je rejoins l'avis de Benjamin préconisant l'utilisation des rapports coté serveur (camenbert/histogrammes...)et aussi le composant SVG inline. Le composant inline devrait nous permttre de s'affranchir du plugin ADOBE. Il nous resterait alors à nous concentrer sur un framework ergonomique destiné à la cartographie sur intranet (et si les oracles nous sont favorables... n'avoir qu'un seul navigateur..(devinez lequel !). J'ai publié dans documents/guide de mise en oeuvre le document présentant la réalisation d'une maquette graphique, utilisant le plugin ADOBE. Les composants de données y sont présentés, ainsi que des composants de présentation (composant à onglets et fenetres mobiles). la représentation de données sur une carte support y est également présentée. |
|
| RE: Framework SVG intégré au fw ERGO W3C [ Répondre ] Par : Benjamin Leperchey on 2007-01-15 15:57 | [forum:52416] |
|
Nota : l'exemple de CodeProject ressemble fortement à ce que j'ai écrit indépendamment pour le composant SVG inline, c'est rassurant. Sur la discussion générale (SVG/VML/Flash), je n'ai pas véritablement d'avis... si ce n'est qu'on pourrait faire une bibliothèque à deux niveaux : - FW technique SVG pur, dans un premier temps, pour FF et IE+ASV, - surcouche "applicative" du genre de celle décrite dans le CodeProject dans un second temps. A mon avis, le critere de choix est : pour qui veut-on faire du SVG ? Tant que ça reste en intranet, il me semble raisonnable de viser Firefox, et je ne vois pas d'applications Internet de SVG : pour les animations, Flash reste supérieur. SVG/VML ont une plus-value du côté génération automatique (camemberts etc.) et pour la manipulation des cartes. De toute façon, à part pour les cartes, le domaine du SVG est encore très flou... les cämemberts etc. devraient plutôt être intégrées aux rapports générés côté serveur -- à part pour la navigation dans les données de type OLAP, mais c'est un besoin très spécifique. |
|
| RE: Framework SVG intégré au fw ERGO W3C [ Répondre ] Par : Steve PEGUET on 2007-01-15 12:10 | [forum:52413] |
|
Une autre URL précisant les différences entre VML et SVG peut permettre d'aider pour ce débat : http://www.codeproject.com/jscript/jbridge.asp Quelques urls pour faire du flash en Open Source : http://osflash.org/ http://www.asdt.org/ Merci d'avance pour vos idées... |
|
| RE: Framework SVG intégré au fw ERGO W3C [ Répondre ] Par : Steve PEGUET on 2007-01-15 11:36 | [forum:52412] |
|
Bonjour tout le monde, un portail intéressant sur le sujet est disponible sur : http://svgfr.org Une news aborde le problème de l'abandon par Adobe du plugin SVG vis à vis de sa stratégie sur Flex 2. Ceci a tendance à privilégier une implémentation SVG native du type Firefox ou Opera. Reste le quid de compatibilité avec MSIE???? Sinon une des normes sortant sur le sujet et d'avenir semble le SVG Tiny 1.2 (en cours de validation W3C) qui pourrait servir de base de support dans notre implémentation. Mais reste le problème de prise en compte de MSIE en sachant que Microsoft a pour stratégie de plutôt imposer la norme VML (en cours de validation au sein du W3C) plutôt que la norme SVG. On voit que le problème reste entier et que la problèmatique de norme sur le sujet et d'intégration de ces normes par les solutions d'éditeur risque de freiner le mouvement. Aujourd'hui, la seule position viable serait de partir sur un Wrapper technologique permettant d'effectuer du SVG natif d'une part et du VML natif d'autre part. Est-ce que ce serait envisageable? Est-ce que ce serait délirant dans son investissement? ou est-ce que ce serait pas plus judicieux de carrément faire du flex en libre? Je pense que la question reste entière et vraiement problématique.... |
|
| RE: Framework SVG intégré au fw ERGO W3C [ Répondre ] Par : Thierry RIGAL on 2007-01-15 00:36 | [forum:52410] |
|
Une simple remarque d'ordre lexical : Le framework client se nomme FrameworkERGO et non fw W3C. Escamoter son nom peut entraîner des confusions chez le lecteur néophyte. |
|
| Framework SVG [ Répondre ] Par : Benjamin Leperchey on 2007-01-12 17:34 | [forum:52402] |
|
Il faudrait pour cadrer les développements SVG définir un framework technique, à l'image de celui qui existe pour le FW W3C. L'expérience à a montré que les questions suivantes (au moins) devraient être traitées : - gestion des flux XML : le plugin Adobe offre des méthodes "DOM3", qui ne fonctionneront pas en SVG inline avant quelques années. Prévoir une implémentation de fw_xml.js pour les SVG (la même légèrement amendée ?) - Création et manipulation du DOM : pour le SVG inline, document.createElement ne marche pas pour les éléments SVG (problème de NS sous Firefox, problème de documents imbriqués sous IE). Un wrapper de base (createDocument+createTextNode) devrait suffire -- voir la proposition de composant SVG inline. - un composant SVG inline, justement. Ce FW technique devrait fonctionner à la fois au sein du plugin Adobe (mode "tout-terrain") et en SVG inline (mode "avancé"), pour normaliser les développements dans les deux technologies. Nota : le fw XML est optionnel dans le mode "inline" puisqu'on peut appeler le flux depuis le javascript du HTML avec le fw_xml.js du fw W3C. Tout ceci devrait bien sûr être accompagné de normes et de bonnes pratiques. A ceci s'ajouterait, comme pour le fw W3C, un framework ergonomique : - composant de données (courbes, camemberts etc) - composants de présentation (onglets, fenêtres etc) Qu'en pensez-vous ? |
|
