CMS para Flash

Ok, ya me espero entoces.

victorcoder
@season

Entoavía no, porque está en bata y pantuflas (Oskitar es que es de la casa). Le tenemos que hacer unos pequeños cambios cosméticos y quiero que primero pruebe Oscar la funcionalidad principal.

En muy poco tiempo lo hacemos público, de veras.

orange, puedo tener acceso a ese Redmine, tb?

gracias.

He creado uno con eso, al menos para que puedas ir cacharreando (te deberían haber llegado los datos de acceso por mail). Échale un ojo y dime qué necesitas, qué no y qué necesitas que te configure a nivel de Admin del redmine.

No es importante regulero, porque se generan URL's con el nombre. Puedo poner como identificador cms_flash que siempre será algo descriptivo, pero si quieres algo molón puede ser el momento

Kitar'o'Matik?

El nombre de momento no es fundamental, así que el dices está bien, cuanta más cosas, donde has dejado las llaves y esas cosas y me pongo a subir material.

Perdonad por la tardanza, ya tenemos el redmine listo para que se puedan ir subiendo cosas (aunque todavía no sea público, que le faltan unos retoques estéticos)

Una chorrada ¿qué nombre le pongo al proyecto? ¿CMS para Flash?

Estube mirandome el código pero no lo llegue a probar. Tengo que probarlo con Flex que es lo que mas toco yo y te digo que tal.

Ha mirado alguien las clases que subí a github? son una versión decente y bastante funcional de los servicios, también incluí en su wiki unos ejemplos sobre como usar los servicios que programé. ¿La han sido útiles a alguien?
Voy a ver si preparo unos tutos sobre requisitos ,como instalar drupal y esas cosas y ejemplos básicos de uso.

Yo por mi parte no he avanzado nada, he cambiado de trabajo hace poco y tengo poco tiempo. Que tal oskitar has avanzado algo?

ei!!!
alguna novedad??
se puede ayudar en algo??
k'stamos aki!!

creo que el estudio de diseño Group94 desarrollo uno , hacen cosas chulisimas con el

Gracias pro el ofrecimiento, veremos cómo encajamos eso

Yo si queréis os hecho una mano con el diseño o la imagen de la aplicación.

He subido un update del conector a github también he colocado unos ejemplos en el wiki que ofrecen, para que veáis como acceder a los servicios.

Tenéis acceso para los siguientes métodos públicos de los servicios:
* node.get (recupera un nodo)
* node.save (salva un nodo)
* node.delete (borra un nodo )

* system.mail (envia un correo)
* system.getVariable (recupera una variable del sistema)
* system.setVariable (almacena una variable en el sistema "no volatil")

* taxonomy.getTree (recupera el árbol de taxonomias)
* taxonomy.selectNodes (recupera un conjunto de nodos etiquetados bajo las taxonomías pasadas como parámetro)

* views.get (recupera un view)

Y estos dos que son internos y no accesibles.
* system.moduleExists (comprueba que se puede acceder al servicio)
* system.connect (conecta al servicio)

Bien! parece que la cosa marcha, Lo primero que deberíamos hacer es organizarnos , decidir cuales son las areas de trabajo,los objetivos y con que recursos contamos. Supongo que a lo largo de esta semana tendremos el redmine desde los dmstk HQ, de modo que en cuanto lo tengamos online empezamos con la definición.

Si tengo alguna duda con Drupal, cuento contigo para preguntarte, de momento no me he encontrado con grandes problemas, salvo quizás la implementación a medias o sin depurar de algún módulo de servicios, pero más o menos me las he arreglado para solucionarlas.

El módulo ese que has puesto no lo conocía y resuelve un asunto importante que es hacer instalaciones personalizadas, yo no había encontrado una solución a esto.

¿Alguien más se anima a colaborar en el proyecto?

:) Mas vale tarde que nunca, no?

Vale, estoy de acuerdo, vamos a probar con AMFPHP

Yo por mi parte voy a investigar lo del concrete5, me interesa como CMS super simple y usable y cuando esté publicado lo de Drupal tb lo tunearé.

Oskitar, dime si necesitas que te ayude con Drupal, llevo mucho tiempo con el y se me resiste poco.

Algo que nos puede sevir es que tiene un sistema, personalizable de funciones, para de instalación de módulos y configuración de variables durante la instalación. http://drupal.org/node/306267 Servirá para configurar todo "de serie"

Si necesitas un Redmine, también tengo el mio http://redmine.victorcoder.com

Hola:

* La librería AMFPHP soporta el formato AMF3,al menos yo lo estoy usando sin problemas y aquí dicen que está soportado, a lo mejor no del todo, pero de momento no me ha petado la aplicación por ningún lado.

Como dices AMFPHP soporta actualmente AS3 (AMF3), salvo los bugs que tenga, claro ;-). Lo que sí parece es que Adobe está apostando por Zend, como también se ha dicho. He intentado hacer alguna cosilla con Zend y me pierdo bastante, ya que no hay tanta documentación y demos como para AMFPHP. Si finalmente os decantáis por Zend, sería el empujoncito que me falta para ponerme en serio con este framework (imagino que en un futuro acabará convirtiéndose en el standard, si sigue la colaboración con Adobe)

Muchos ánimos, de otro que sigue este hilo de "oyente" :-)

Un saludo

si necesitan un cafe o unas pastas..
para seguir con este currito.. no duden en avisar

Y tu porque no has aparecido hace un mes?!!!
Suena muy bien todo lo que comentas, así que vayamos por partes.

* La librería AMFPHP soporta el formato AMF3,al menos yo lo estoy usando sin problemas y aquí dicen que está soportado, a lo mejor no del todo, pero de momento no me ha petado la aplicación por ningún lado.

* La extensión AMF del framework ZEND no la he usado, así que no puedo opinar sobre el soporte de AMF3 pero me imagino que si han colaborado los tios de adobe con los de php estará muy bien. De todas formas no se si será necesario reprogramar el server del módulo services porque estoy casi convencido de que funciona con AMF3. Míralo a ver o si tienes mas info confírmame que no se puede usar AMF3.

* La gestión de servicios XML-RPC después de la salida de datos en XML estandar, es lo siguiente que tengo en el planning una vez acabar el core del conector AMF, sobre todo revisar que el curro no estuviera ya hecho aquí y en el enlace que has puesto de googlecode, aunque no es algo prioritario teniendo ya los AMF desarrollados.

* No tengo ni idea de como es de dificil desarrollar nuevos módulos para "concrete5", pero la interfaz y la usabilidad son una pasada así que sería muy interesante averiguar como de dificil es crear nuevos módulos y adaptarlos. Me apunto en la lista dedicarle un rato generoso a concrete5 y ver si es gratis, estable, extensible y potente.

Elegí Drupal despues de mirar distintos CMS por diversos motivos, posibilidad de crear usuarios con acceso muy restringido al CMS, la interfaz se puede reducir muchísimo para que los usuariosa que rellenen el CMS tengan solo las opciones necesarias, existen módulos maestros muy potentes y útiles para adaptarlos a los requerimientos del proyecto, sobre todo los módulos services y views....
Esta tarde he preparado los conectores con los servicios Views y Taxonomy y las posibilidades son enormes, sobre todo con el módulo Views, pongo un pantallazo de la parte de creación de un view para que veais a que me refiero.

El resultado es este:

Se pueden crear vistas personalizadas para seleccionar nodos con infinidad de criterios, seleccionar los tipos de datos que se mostrarán, para quien estarán disponibles criterios de ordenación, pasar parámetros para la selección... y luego solo hace falta hacer la llamada desde flash:


//...
vs = new DAS_view();
vs.connect("http://localhost/drupal/services/amfphp", "API");
vs.addEventListener(DrupalEvents.DRUPAL_READY,onInitService);
//...

public function onInitService(e:*):void{
vs.get_view(onGetView,onGetViewFault,"mi_vista_personalizada");
}


Y ya están disponibles todos los datos que genera la vista para manipular en flash.

En un par de dias libero el core que comunica con drupal, y haciendo una sencilla modificación se puede usar para cualquier otro servidor de AMF.

Donde está ese redmine!!!

Me presento, soy programador de un proyecto web 2.0 que está funcionando desde hace mas de un año, en el que usamos Drupal Services con Flex, que hace esto que estas haciendo oskitar y uno de los problemas que le veo a este sistema es el uso de la librería AMFPHP, ya que solo soporta el formato AMF0. Como sabeis, en una unión de fuerzas con Adobe, ahora Zend Framework incorpora el soporte de AMF3 desde la versión 1.7

Lo siguiente que voy a programar es la integración de las clases Zend_Amf como un server del módulo services de Drupal. Esto parece mucho mas adecuado que usar el antiguo formato AMF0. Como lo veis?

Por otra parte, por el momento, el modulo services implementa un servidor que funciona 100% en formato XML-RPC y que se comunica con AS usando la librería as3-rpclib http://code.google.com/p/as3-rpclib/ que funciona muy bien.

Como se ha comentado Drupal es un gran CMS pero es mucho drupal. Una opción que me parecería mas adecuada para empezar con un proyecto de este tipo (siempre que haya gente interesada) sería la posibilidad usas un CMS menos recargado y mas "user friendly" que Drupal como por ejemplo www.concrete5.org y desarrollar una extensión que permita la integración con Flash mediante XML-RPC o AMF y a la vez con HTML. Esto formaría una plataforma ágil y sobretodo sencilla para el usuario. Creo que sería posible integrarlo con Gaia y así tener lo que estamos buscando.

Poco a poco iré desvelando mas detalles de lo que quiero hacer.

Excelente!!

Nosotros por nuestra parte estamos avanzando en la instalación del Redmine, a ver si dentro de poco tienes un espacio propio para ir poniendo los avances
:)

La primera cosa que estoy pensando antes de continuar es que DrupalConnector no herede de AmfService si no que lo implemente por composición y de paso, meter el dispatch de eventos que tiene AmfService por composición a DrupalConnector.

He modificado completamente la orientación inicial del conector con servicios para darle flexibilidad al asunto podéis ver como va el desarrollo aquí : github .

Funcionamiento en comentarios:

import dffconnector.services.DAS_node;
import dffconnector.events.DrupalEvents;

// mas adelante...

private function init_conn():void{
//init AMF CONNECTOR
dac = new DAS_node();
//conectamos al servicio
dac.connect("http://localhost/drupal/services/amfphp", "API");
//cuando este conectado el servicio
dac.addEventListener(DrupalEvents.DRUPAL_READY,onInitService);
}

public function onInitService(e:*):void{
/** solicitamos el servicio node
* @param onNodeGet:Function si todo va bien
* @param onNodeFault:Function en caso de fallo
* @param valor de nodo a recuperar
* @param recuperar desde cache si ya fue solicitado.
dac.node_get(onNodeGet,onNodeGetFault,3,true);
}

public function onNodeGet(data:*):void{
//Haz algo una vez recibidos los datos
Debug.log(data+"="+data.contentAsString);
}

public function onNodeGetFault(e:*):void{
//Haz algo con el error
Debug.log(objectToString(e));
}

Hay 3 clases:
* AmfService. que contiene la petición básica de cualquier servicio Amf.
* DrupalConnector que extiende a Amf y gestiona la conexión correcta al servicio, el lanzamiento del envío periódicamente si no hay respuesta del servidor, y el cache de los datos de un servicio.
* DAS_node (Drupal-Amf-Service_node) que extiende a DrupalConnector y se encarga básicamente de implementar la solicitud de los servicios propios y manejar y formatear los datos recibidos, está es la única clase accesible las otras dos no tienen métodos públicos.

Para desarrollar el resto de servicios usuales de Drupal se deben crear de manera similar a DAS_node, por ejemplo, creamos DAS_views, necesitaremos que esa clase tenga un método para conectar y uno de manipulación de datos para devolver en caso de que el servicio se realice de manera correcta.

Antes de conectarse a un servicio se verifica que hay conexión al gateway y que el servicio existe en el servidor mediante el servicio system.serviceExist, por lo que hay que aportar una definición del servicio que usara la implementación de nuestra nueva clase conectora. Si se realiza la conexión de manera correcta se lanza un evento ready que permite empezar a solicitar servicios a los que nos hemos suscrito, de lo contrario se lanza un evento de error.
De momento no están implementados en su totalidad los eventos, no se si será necesario crear un evento onData por ejemplo que avise de la recepción de los datos.

Iré subiendo los avances a ese repositorio, esto que he colgado es una versión en pañales de lo que debe ser finalmente el conector.

Estaré muy atento a vuestras sugerencias y comentarios que siempre son de gran ayuda.

He estado avanzando hoy sobre el proyecto en la parte sobre todo de la librería AS, y la cosa de momento pinta muy bien, he creado unas clases conectoras con algunos de los servicios que implementa el módulo services de Drupal que me parece que son estos :

file
* file.get
* file.getNodeFiles
menu
* menu.get
node
* node.get
* node.save
* node.delete
search
* search.nodes
* search.users
system
* system.connect
* system.mail
* system.getVariable
* system.setVariable
* system.moduleExists
taxonomy
* taxonomy.getTree
* taxonomy.selectNodes
user
* user.delete
* user.get
* user.login
* user.logout
* user.save
views
* views.get
* views.export
* views.import

Tenemos nuestro drupal corriendo en localhost y en este ejemplo realizamos llamada al servicio que te devuelve el nodo 6.

Y esto es lo que se vería en la parte del localhost, es decir el contenido al que accede el servicio:

El funcionamiento es sencillo, se crea el servicio, se dan da alta los listeners y se envía el servicio que se necesite.


private function init_conn():void{
//init SERVICE CONNECTOR
dac = new DrupalAmfConnector("http://localhost/drupal/services/amfphp");

//add listeners
dac.addEventListener(ServiceEvent.SERVICE_RECEIVED, onServiceReceivedHandler);
dac.addEventListener(ServiceEvent.SERVICE_ERROR, onErrorHandler);
dac.addEventListener(ServiceEvent.SERVICE_STATUS, onStatusHandler);
dac.addEventListener(ServiceEvent.SERVICE_SEND, onSendHandler);

//launch service
dac.getNode(6);
}

private function onSendHandler(e:Event):void{
Debug.log ("\n - EVENT :: " + e.type + "\n - target::" + e.target + "\n - command::" + e.target.command + " \n - data send:: " + objectToString(e.target.datasend));

}

private function onServiceReceivedHandler(e:Event):void{
Debug.log ("\n - EVENT :: " + e.type + "\n - target::" + e.target + "\n - command::" + e.target.command + " \n - data received:: " + objectToString(e.target.data));
//Debug.log(e.target.data);
}

private function onErrorHandler(e:Event):void{
Debug.log ("\n - EVENT :: " + e.type + "\n - target::" + e.target + "\n - command::" + e.target.command + " \n - error::" + objectToString(e.target.error));
}

private function onStatusHandler(e:Event):void{
Debug.log ("\n - EVENT :: " + e.type + "\n - target::" + e.target + "\n - command::" + e.target.command + " \n - status::" + objectToString(e.target.status));
}

Debug.log sirve para que salgan los datos por la consola de trazas y objectToString, formatea los objetos a cadena.
De momento podemos suscribirnos a 5 eventos:
envío del servicio, error en el servicio, incidencia en Netconnection, recepción completa de datos y servicio cerrado.


public static const SERVICE_SEND :String = 'service_send';
public static const SERVICE_ERROR :String = 'service_error';
public static const SERVICE_STATUS :String = 'service_status';
public static const SERVICE_RECEIVED :String = 'service_received';
public static const SERVICE_CLOSED :String = 'service_closed';


De momento lo he preparado para que una vez recibido el evento "SERVICE_RECEIVED" los datos estén disponibles a través del conector en forma:
"e.target.data" o dac.data, según esteis dentro o fuera del scope del listener.

En cuanto tenga una versión cerrada empiezo a organizar el repositorio y el control del proyecto subo algo para que podáis ver los detalles.

Nosotros en GitHub sólo vamos a alojar el repo, el wiki y demás estará todo en Redmine (de hecho no sé ni siquiera si haría falta que el repo estuviera creado previamente, o se podría crear en ese momento). De todas formas no corre tanta prisa la creación de los repositorios, que hasta que habilitemos la nueva aplicación dentro de las máquinas de Domestika pasarán - siendo sinceros - un par de semanas por lo menos, que nosotros tenemos planificado ya este sprint y el nuevo no empieza hasta el 26 de enero.

Ya he probado github y mola mil, la versión gratuita te permite hacer todos los repositorios que quieras, en la versión gratis " Anyone may fork, clone, or view it. " pero por ejemplo el wiki si es público y puede ser editado por cualquiera cosa que no me mola tanto. De momento voy a crear 2 repositorios uno para los módulos de servicios, y otro para la aplicación de conexión de servicios.
He programado un servicio externo a Drupal al estilo "HelloWorld" y una clase conectora con ese servicio. A lo largo de mañana colocaré otro servicio de prueba ya dentro de drupal y una clase en flash que gestione varios servicios standard de drupal y en cuanto estén funcionando hago la subida a github para que les metáis mano.

Sobre lo de github, espérate que todavía no lo he probado así que estoy en modo bocachancla, con lo de repositorios públicos me refería a que cualquiera puede tocar en tu repositorio o en el wiki o algo así. Pero no tengo ni puta idea de las particularidades del gestor así que, voy a probarlo dentro de un rato a ver como funciona y ya puedo hablar sobre ello.

Github gratuito es público, pero he dado por hecho que esto tenía pinta de convertirse en un proyecto colaborativo ¿no? Te diría que interesa publicitarlo y que la gente aporte.

Yo creo que si curráis varios al final es interesante tener un entorno de desarrollo común y centralizado, pero vaya que no hay nada que una buena documentación de instalación y configuración de apache no puedan hacer.

De todas maneras lo suyo en esto es que cada uno curre en local, suba los cambios al repo, y desde el repo se hagan deploys al sitio público.