Lors du développement de vos projets Flex avec Flex Builder 3, vous avez peut-être utilisé, comme moi, des marqueurs comme des tâches pour se rappeler de ce que vous aviez a faire, ou comme des signets pour retrouver l’emplacement de fonctions que vous modifiez souvent. Malheureusement avec Flex Builder 3 la gestion de ces marqueurs souffrait de quelque bugs, les vues d’ensemble ne permettaient pas toujours de retrouver les marqueurs que vous aviez mis.

Maintenant dans Flash builder 4, ces bugs sont résolus. Quand on ajoute une tâche, elle se retrouve bien dans la vue d’ensemble des tâches de même que pour les signets.

Et facilité de recherche et de développement, Abobe a créé une nouvelle vue permettant de retrouver tous les marqueurs placés dans vos projets que ce soit les tâches, les signets, les erreurs mais aussi les warnings ainsi que les points d’arrêts et les conflits SVN.

Aucun d'article en relation

Cela fait maintenant plus de 6 mois que nous développons sur la nouvelle version de Flex Builder, version s’appelant désormais Flash Builder 4. Nous avons commencé sur la beta 1, et sommes désormais sur la beta 2. Nous en sommes à 4 projets dont 2 qui sont en production ce qui nous donne un certain recul sur cette nouvelle version, sur les avantages, inconvénients par rapport à la version 3.

Nous entamons donc une série de billets qui vont porter sur les nouveautés de Flash Builder 4, de Flex 4, mais aussi sur les points qui peuvent poser des soucis dans le développement de tous les jours. Dans ces billets, nous posterons parfois des exemples qui contiendront bien évidemment le code source. Afin de compiler ce code source, il vous faudra au minimum le sdk Flex 4 pour l’installer sur eclipse ou Flex Builder 3 (disponible sur http://opensource.adobe.com/wiki/display/flexsdk/Download+Flex+4) ou bien de télécharger Flash Builder 4 beta 2 (disponible http://labs.adobe.com/technologies/flashbuilder4/). Si vous disposez d’un numéro de série pour Flex Builder 3, vous pouvez obtenir un numéro de série pour Flash Builder beta2 pour étendre la période d’essai (disponible sur https://freeriatools.adobe.com/flashbuilder4beta/).

Avant de commencer la série de billets, nous voulions donner notre avis sur l’adoption de Flash Builder 4. Au sein de Matsiya, il est clair que nous ne souhaitons plus repasser sur Flex builder 3, les améliorations apportées par la version 4 surpasse de très loin les points négatifs de cette beta, qui seront, nous l’espérons, corrigés dans la version finale. De plus, cette version devrait être disponible cette année, donc il n’est pas inconscient de commencer un projet à l’heure actuelle sur cette version beta 2, qui reste très stable pour une version beta.

A très vite.

Aucun d'article en relation

Voici une rich internet application développée en Flex/Flash pour un tour opérateur spécialisé dans les séjours de golf. Utilisation de web services et de la cartographie Google Maps.

RIA Flex – Agence de voyage from Matsiya on Vimeo.

Aucun d'article en relation

Nous avons développé plusieurs applications AIR / Flex. La plupart sont soumises à des clauses de confidentialité, mais heureusement quelques unes ne le sont pas, nous pouvons ainsi vous montrer le chargement.

Pour chaque application, nous réalisons un loader personnalisé à l’identité de la société qui indique l’état de chargement de l’application et le numéro de version.

En effet, au démarrage de l’application, nous pouvons être amenés à charger des modules ou des datas. Le temps de chargement et d’initialisation de l’application AIR peut prendre plusieurs secondes, il est donc important d’informer l’utilisateur de ce chargement.

Loader AIR from Matsiya on Vimeo.

Aucun d'article en relation

C’est parti !! Adobe lâche les betas de Flash Builder 4 et Flash Catalyst…(pour ceux qui auraient manqué l’info, Flex Builder a été rebaptisé Flash Builder). C’est un lot de nouveautés pour Flash Builder 4, pour en savoir plus, je vous invite à lire l’article « What’s new in Flash Builder 4 beta » de Tim Buntel.

Flash Catalyst, plutôt destiné aux designers, va permettre de simplifier considérablement le lien designer/développeur, vous trouverez ici quelques vidéos et tutoriaux pour la prise en main.

Aucun d'article en relation

Si l’intérêt d’utiliser BlazeDS pour faire communiquer une application Flex avec des services distants n’est plus à prouver, il en résulte souvent un manque d’interopérabilité des services.

Dans le cas d’une application qui pourrait avoir des interfaces multiples (web, ajax, swing etc …) il est alors préférable d’utiliser des services de type SOAP ou REST. On peut par exemple imaginer une application Air et une application pour iPhone développée en Cocoa qui accèdent au même applicatif serveur et qui partagent la même session hibernate. Une solution simple serait alors de dupliquer les classes de services, mais cela engendrera par exemple la duplication de la connexion à la base de donnée. L’utilisation de Spring peut alors grandement nous faciliter la tâche, en effet il est possible de partager un contexte entre servlet et donc de n’accéder qu’à une seule instance que ce soit par Axis2 ou BlazeDS.

1) Création du projet

Nous n’utiliserons ici qu’un seul et même projet, pour ceux qui connaissent Spring cette partie ne devrait pas poser de problème :

DaoFactory :

Ici on récupère le context parent avec parentContextRef.getFactory()

public class DaoFactory {

private static ApplicationContext appctx= null;

static {

try {

String locatorFactorySelector = « serviceContext.xml »;

String parentContextKey = « serviceContext »;

BeanFactoryLocator locator = ContextSingletonBeanFactoryLocator.getInstance(locatorFactorySelector);

BeanFactoryReference parentContextRef = locator.useBeanFactory(parentContextKey);

appctx = (ApplicationContext) parentContextRef.getFactory();

} catch (Exception e) {

e.printStackTrace();

}

}

public Object getBean(String name){

return appctx.getBean(name);

}

}

AppFactory :

public class AppFactory {

private static DaoFactory dao;

public static DaoFactory getDao()

{

if (dao == null)

dao = new DaoFactory();

return dao;

}

}

2) Web.xml

Il va maintenant être nécessaire d’ajouter quelques lignes dans les fichiers web.xml de BlazeDS et d’Axis2 :

<listener><listener-class>org.springframework.web.context.ContextLoaderListener</listener-class></listener><context-param><param-name>contextConfigLocation</param-name><param-value> </param-value></context-param><context-param><param-name>locatorFactorySelector</param-name><param-value>classpath:serviceContext.xml</param-value></context-param><context-param><param-name>parentContextKey</param-name><param-value>serviceContext</param-value></context-param>

On assigne la valeur serviceContext à parentContextKey que l’on va définir dans notre fichier serviceContext.xml. C’est ici que Spring va récupérer le context d’exécution en cours. Si le context parent n’existe pas il sera alors automatiquement créé.

3) applicationContext.xml et serviceContext.xml

Pour ceux qui connaissent Spring , déclarez votre applicationContext.xml comme à l’habitude. Pour les autres IDE, de bons tutoriels sont disponibles sur le net.Le fichier serviceContext.xml sera défini de la manière suivante :

<beans>

<bean id= »serviceContext » class= »org.springframework.context.support.ClassPathXmlApplicationContext »>

<constructor-arg>

<list>

<value>applicationContext.xml</value>

</list>

</constructor-arg>

</bean>

</beans>

4) Déploiement

Grâce à Ant nous allons pouvoir déployer tout l’ensemble assez facilement. Les services Axis ne contiendront que les class Axis2Service, DAOFactory, AppFactory et le fichier serviceContext.xml qui se trouvera dans le classpath d’Axis2. Pour BlazeDS nous procédons de la même manière , seul les class de BlazeDSService, DAOFactory, AppFactory et le fichier serviceContext.xml sont déployés dans les répertoires WEB-INF/classes. Les beans seront quand à eux mis dans un .jar qu’on placera dans le répertoire lib de Tomcat. De cette manière BlazeDS et Axis2 y auront accès de la même manière. On pourrait très bien disposer ce .jar ailleurs dans l’arborescence, cela serait surement plus propre mais nécessite un peu plus de configuration et ce n’est pas l’objet de cet article.Un fichier build.xml vaut mieux qu’un long discours ! En voici un que j’ai fait juste pour cet article, il devrait permettre à ceux qui connaissent un peu, de comprendre à quoi va ressembler le tout une fois déployé.

<project name=« BlazeDSAxis2″ basedir=« . » default=« generate.service »>

<property environment=« env »/>

<property name=« TOMCAT_HOME » value=« /Users/home/j2ee/apache-tomcat-6.0.18″/>

<property name=« AXIS2_HOME » value=« /Users/home/j2ee/apache-tomcat-6.0.18/webapps/axis2/WEB-INF »/>

<property name=« BLAZEDS_HOME » value=« /Users/home/j2ee/apache-tomcat-6.0.18/webapps/blazeds/WEB-INF »/>

<property name=« build.dir » value=« build »/>

<path id=« tomcat.classpath »>

<fileset dir=« ${AXIS2_HOME}/lib »>

<include name=« *.jar »/>

</fileset>

<fileset dir=« ${TOMCAT_HOME}/lib »>

<include name=« *.jar »/>

</fileset>

<fileset dir=« ${BLAZEDS_HOME}/lib »>

<include name=« *.jar »/>

</fileset>

</path>

<target name=« compile.service » >

<mkdir dir=« ${build.dir} »/>

<mkdir dir=« ${build.dir}/classes »/>

<!–First let’s compile the classes–>

<javac debug=« on »

fork=« true »

destdir=« ${build.dir}/classes »

srcdir=« ${basedir}/src »

classpathref=« tomcat.classpath »>

</javac>

</target>

<target name=« clean »>

<delete dir=« ${build.dir} »/>

</target>

<!– generate WSDL –>

<target name=« generate.wsdl »>

<taskdef name=« java2wsdl »

classname=« org.apache.ws.java2wsdl.Java2WSDLTask »

classpathref=« tomcat.classpath »/>

<java2wsdl className=« services.Axis2Service »

outputLocation=« ${build.dir} »

targetNamespace=« http://www.matisya.eu »

schemaTargetNamespace=« http://www.matsiya.eu/xsd »>

<classpath>

<pathelement path=« ${tomcat.classpath} »/>

<pathelement location=« ${build.dir}/classes »/>

<pathelement location=« ${basedir}/ressources/META-INF/services.xml »/>

</classpath>

</java2wsdl>

</target>

<target name=« generate.service » depends=« clean, compile.service, generate.wsdl »>

<copy toDir=« ${build.dir}/classes »>

<fileset dir=« ${basedir}/resources/META-INF »/>

</copy>

<!– jar beans –>

<jar destfile=« ${TOMCAT_HOME}/lib/MyApp.jar »>

<fileset dir=« ${build.dir}/classes »>

<exclude name=« services/*.* »/>

<exclude name=« serviceContext.xml »/>

<exclude name=« services.xml »/>

<exclude name=« core/* »/>

</fileset>

</jar>

<!– copy each service –>

<!– BLAZE DS –>

<copy toDir=« ${BLAZEDS_HOME}/classes »>

<fileset dir=« ${build.dir}/classes »>

<!– include your services here –>

<include name=« services/BlazeDSService.class »/>

<include name=« core/*.* »/>

</fileset>

<fileset dir=« ${basedir}/resources/META-INF »>

<include name=« serviceContext.xml »/>

</fileset>

</copy>

<!– AXIS 2 : aar service up –>

<jar destfile=« ${AXIS2_HOME}/services/MysService.aar »>

<fileset dir=« ${build.dir}/classes »>

<!– include you services here –>

<include name=« services/Axis2Service.class »/>

<include name=« core/*.* »/>

</fileset>

<fileset dir=« ${basedir}/resources/ »>

<include name=« **/services.xml »/>

</fileset>

</jar>

<!– copy contextServices to AXIS2/classes –>

<copy toDir=« ${AXIS2_HOME}/classes »>

<fileset dir=« ${basedir}/resources/META-INF »>

<include name=« serviceContext.xml »/>

</fileset>

</copy>

</target>

</project>

Aucun d'article en relation

Si inclure une animation flash dans magento est relativement simple, la faire communiquer avec les services existants l’est nettement moins. En effet magento fournit une API basée sur le prorocol SOAP peu respectueuse des conventions et Flex/Flash n’aime pas ça …. Nous avons donc du modifier le SDK de flex afin de pouvoir utiliser simplement les services disponibles. Bien qu’il soit possible d’en créer des nouveaux, ces services sont mal adaptés à une interface de type RIA et les taux de transfert sont très faibles.

Nous avons donc décidé de prendre la voie de l’AMF, bien plus rapide et permettant le chargement de plus gros volumes de données. Magento étant basé sur Zend framework , nous avons utilisé Zend AMF présent dans la version 1.7 (possibilité de l’inclure dans des versions antérieures) et après quelques modifications de Zend AMF, nous avons réussi à exposer la totalité des méthodes de l’API existante en AMF. Il reste quelques points à régler (gestion des droits ACL de zend par exemple) pour fournir un framework installable et utilisable en quelques clicks mais il est déjà possible de développer des modules Flash/Flex pour l’administration ou pour le catalogue de vos sites e-commerce Magento.

Aucun d'article en relation

Ryan Stewart lance son show nommé « Tech Talk with Ryan Stewart » sur Adobe TV. Le premier épisode concerne Flex 4, l’open source..etc. Invité d’honneur Matt Chotin, Flex Product Manager.

Aucun d'article en relation

Voici une publication PDF de l’API actionscript 3 pour le développement de vos RIA Adobe Flex et Air.

Article Devnet Adobe :

Adobe technology platform ActionScript reference for RIA development

Document PDF :

Adobe technology platform – ActionScript Reference – Rich Internet Application Development

Aucun d'article en relation

Voici un aperçu du backoffice Flex de la solution ecommerce. Nous n’avons pas encore skinné l’application…

Post concernant le site public

Aucun d'article en relation