DataSnap o LAMP

[Chris]

Compañeros, me encuentro en un dilema ahora. No sé que camino tomar. Quiero REdesarrollar una aplicación desde cero (me encanta reinventar la rueda :D). La aplicación que existe ahora es cliente-servidor con Firebird. Tiene sus defectos por la arquitectura y además cuando la hacía no tenía mucha experiencia en cliente-servidor ni Delphi.

Por esa razón, quiero enmendar los problemas que esa pobre aplicación tiene volviéndola a hacer desde cero. Con su mejoras y funciones nuevas claro! Pero no me decido que arquitectura usar: DataSnap con o sin Intraweb, Cliente-Servidor o simplemente usar LAMP.

Realmente más prefiero hacerla en LAMP (usando Django y PostgreSQL), sinceramente porque me gusta sentir que tengo todo bajo control y puedo incidir fácilmente sobre cada parte de la aplicación y su GUI. Lo que me detiene a hacerla de este modo es tener que empezar a lidiar con JavaScript, CSS y HTML.

Hacerla con DataSnap o cliente-servidor me evitaría tener que aprender un nuevo lenguage, usar mucho del conocimiento ya adquirido en Delphi. Sin embargo, la aplicación heredaría inconvenientes que no los quiero, como no ser multiplataforma por ejemplo. En este sentido, vi que para el cliente se puede usar Intraweb, pero aún así el servidor estaría esclavizado a funcionar en Windows Server.

En sintesis, estos son los pro y los contra que tengo:
LAMP
Pros:

Multiplataforma (Cliente y Servidor)
GUI más rica y fácil de hacer gracias a HTML, CSS, Javascript
Facilmente puede ser accedida desde cualquier parte
Las estaciones de trabajo no tienen que configurar nada
Se puede tener acceso desde dispositivos móviles
Todos los beneficios de la nueve (esto es relativo)

Contras:

La combinación de HTML, CSS y Javascript es poco productiva comparada con Delphi.
No se tiene acceso a los recursos del sistema (mi aplicación necesita imprimir y a clientes de correo como Outlook o Thunderbird)
Hacer una buena GUI me requerirá de un trabajo enorme de ensallo y error.
.

Por el lado de DataSnap
Pros:

Puedo reutilizar código y conocimiento ya adquirido.
La creación de la interfaz cliente es más fácil.
Acceso a los recursos locales (impresoras, clientes de correo y Word por medio de COM)

contras

No hay mucho control sobre la GUI si utilizo Intraweb
Pegado en una sola plataforma
La movilidad del usuario se ve afectada (se necesita disponer del cliente para entrar al sistema)
Hay que recurrir a la API de Windows para enriquecer la GUI
Si se quiere en dispositivos móviles, hay que desarrollar el cliente (aunque esto también puede ser necesario en LAMP)


Bueno, esos son los puntos que he considerado, aunque creo que alguno se me escapa.

Realmente espero que me puedan brindar sus opiniones. Yo las consideraré y agradeceré. Quiero ya decidirme porque espero empezar el desarrollo en la próxima semana.

De antemano, muchas gracias :)

[mcs]

Hola,

La verdad es que este es un dilema que yo también tengo. Debo actualizar una aplicación de escritorio, cliente/servidor. El servidor es un MySQL que está en un server de Internet, y la aplicación está escrita en Java, y todavía no sé por dónde tirar.

En principio quería ir a lo fácil: Delphi + Firebird. Peeeero lo más fácil no es siempre lo más eficiente. Por un lado hay el inconveniente del "lag" en la comunicación aplicación <--> base de datos, y por otra parte hay el detalle de las actualizaciones.

Si se convierte la aplicación a web, todos estos problemas se solucionan (incluso otro que tengo, de ajuntar una web Joomla con datos de esta aplicación). Las actualizaciones, pues nada más simple: se actualiza en el servidor, y el cliente ya lo tiene automáticamente, sin enterarse. Y el lag entre cliente y bbdd tambien desaparece, al correr todo en la misma máquina.

Cual es, entonces, el auténtico problema? En mi caso, el cambio de filosofía de pasar a desarrollar web. Hasta ahora he programado cosas muy simples para página web (un pequeño "cms", algunas modificaciones a paquetes cómo Prestashop, etc). Pero el salto a toda una aplicación web entera es complicado...

Realmente, no creo que haya ninguna respuesta "buena". Todo son ventajas e inconvenientes, por una parte y por la otra...

Saludos,

Marc

P.D.: El tema imprimir es muy simple: generas un PDF y el usuario pulsa el botón "Imprimir".

[Chris]

Gracias mcs por tu opinión. También creo que el tema de las actualizaciones es uno de los puntos a favor que tendría hacerla en Web. Además comparto ese, lo que creo es, miedo natural al cambio. Pero no me gusta sentirme así, soy un desarrollador aún muy joven y no puedo estarme permitiendo negarme al cambio. Aún así, creo que me encantaría la experiencia que adquiriría, pero lamentablemente no sólo depende de mí, sé que tendré la presión encima y no sabía si mis jefes soportarán ir al paso de un inexperto como yo. Tomándome mi tiendo haría un clon de Facebook, pero no sólo depende de mí. No es que no me guste que me presionen, pero si lo llegan a ser, me sentiría impotente de hacer algo más rápido por mi falta de experiencia en este tipo de desarrollo.


P.D.: El tema imprimir es muy simple: generas un PDF y el usuario pulsa el botón "Imprimir".

"He allí el detalle" cómo decía Cantinflas. Incurriría en desarrollo extra convertir todos los documentos creados. Pero bueno, tengo que barajar las posibilidades.

[D-MO]

Bueno Chris, en lo personal me inclinaría por la versión con Django, el framework "para perfeccioniscas con tiempo límite":D

Haciendo un comparativo de los pros y contras que le ves a ambas soluciones es fácil darnos cuenta que los contras del ambiente web (que no sería LAMP) con Django no son nada comparados con los pros.

La combinación de HTML, CSS y Javascript es poco productiva comparada con Delphi.

Aquí estás en lo cierto, con Delphi diseñas una pantalla muy rápido, sin embargo, html te dá mucha flexibilidad. Para empezar podrías utilizar algún editor para crear los prototipos de pantallas, como dreamweaver en win (aunque para código mas limpio yo, en lo personal, prefiero hacerlo en un editor de texto plano), y utilizas un framework css que te facilite esta tarea, fluid960gs (http://www.designinfluences.com/fluid960gs/) sería mi recomendación, pero hay muchos otros bastante buenos.

No se tiene acceso a los recursos del sistema (mi aplicación necesita imprimir y a clientes de correo como Outlook o Thunderbird)

Acá no entiendo muy bién el problema, si quieres imprimir puedes generar reportes en pdf y que los imprima el cliente, ¿cual es el problema?... para Django/Python reportlab (http://www.reportlab.com/software/opensource/) te ayuda en eso.

Lo segundo en esta sentencia no lo he entendido.

Hacer una buena GUI me requerirá de un trabajo enorme de ensallo y error.

Volvemos al primer punto. Diseña tus pantallas con un editor que te genere el (x)Html y luego los editas para incluir las variables que envíes desde las vistas de django hacia las plantillas. Además, esto podrías subcontratarlo si tu empresa lo quisiera para agilizar el desarrollo.

Por último, arriba te escribí que no sería LAMP en esta situación, te lo explico:

LAMP es el acrónimo de Linux + Apache + MySQL + PHP, y aunque al final PHP lo reemplazas por Python, la parte de MySQL la reemplazas por PostgreSQL, entonces ya no sería LAMP

[roman]

Una pregunta: ¿por que cambiar de Firebird a Postgre? Si tu aplicación es tipo web también puedes usar Firebird ¿no?

Otra cosa sin importancia: creo que el término LAMP no es el más adecuado pues se refiere a Linux, Apache, MySQL, PHP.

Edito: Se me adelantó D-MO con lo de LAMP :)

// Saludos

[D-MO]

Una pregunta: ¿por que cambiar de Firebird a Postgre? Si tu aplicación es tipo web también puedes usar Firebird ¿no?

Obvié esta parte en mi post anterior, Django también tiene soporte para Firebird de manera extraoficial, con la biblioteca django-firebird (http://code.google.com/p/django-firebird/)


Saludos.

[Chris]

Muchas Gracias por tus observaciones D-MO

Lo de LAMP, pues decidí usar el termino por simpliciad, ya que muchos después podría ser que no entiendan de sus variaciones. Me entiendes?


No se tiene acceso a los recursos del sistema (mi aplicación necesita imprimir y a clientes de correo como Outlook o Thunderbird)
Aquí he redactado mal. Me refería a que no tendría acceso directo a las impresoras y también acceso a los clientes de correo por medio de MAPI a cómo lo he venido haciendo ahora. Por ejemplo, lo que hago es presentar una ventana de redacción de correo ya rellenada con el asunto, contenido e incluso adjuntos. Esta funcionalidad no la podría reproducir en la Web porque las API Web no están tan avanzadas, eso creo.

Por otro lado, cuando trabajo con HTML y CSS suelo utilizar poco los editores visuales. Soy programador y me gusta trabajar a nivel de código. Además que tengo hasta el más mínimo control sobre lo producido. Es por eso que te digo que hacer una interfaz rica (así como Facebook) requiere de bastante código en HTML, CSS y ni mencionar Javascript, que en ése sí que estoy "crudo".

Pero aún así estoy abierto a probar editores que me ayuden en el trabajo. Siempre y cuanto me hagan sentir en control.

[D-MO]

...Se me adelantó D-MO con lo de LAMP :) Por apenas unos segundos...

Y hablando de lo mismo, la parte de la "P" podría referirse a Perl, PHP, Python y cualquier otro lenguaje que empiece por p, lo que si no encaja acá es la "M" que si es exclusiva de MySQL.

Saludos

[Chris]

Una pregunta: ¿por que cambiar de Firebird a Postgre? Si tu aplicación es tipo web también puedes usar Firebird ¿no?

A cómo ha dicho D-MO, si puedes usar Firebird. Lo que pasa es que no es oficial hasta dónde entiendo y no me quiero llevar "sorprecitas" después. Ustedes talvez me entenderán.

Además quiero usar un motor algo más "popular", en caso de tener que mover el servidor o alquilar uno virtual o compartido al final -lo más probable sería compartido porque aquí son tacaños-. En ese sentido, nuestro apreciado Firebird aún no es ofrecido por muchos vendedores de servicios en la nube. Además, de Postgre me gusta lo de crear procedimientos almacenados en lenguajes de alto nivel.

[roman]

Aquí he redactado mal. Me refería a que no tendría acceso directo a las impresoras y también acceso a los clientes de correo por medio de MAPI a cómo lo he venido haciendo ahora. Por ejemplo, lo que hago es presentar una ventana de redacción de correo ya rellenada con el asunto, contenido e incluso adjuntos. Esta funcionalidad no la podría reproducir en la Web porque las API Web no están tan avanzadas, eso creo.


Pero, para qué quieres mandar un correo a través de un cliente como Thunderbird o Outlook si puedes mandarlo directamente desde tu aplicación? Y esto aplica tanto para una aplicación web como para una de escritorio.

// Saludos

[Chris]

... podrías subcontratarlo si tu empresa lo quisiera para agilizar el desarrollo.
Eso, DESCARTADO! :mad:

[D-MO]

Aquí he redactado mal. Me refería a que no tendría acceso directo a las impresoras y también acceso a los clientes de correo por medio de MAPI a cómo lo he venido haciendo ahora. Por ejemplo, lo que hago es presentar una ventana de redacción de correo ya rellenada con el asunto, contenido e incluso adjuntos. Esta funcionalidad no la podría reproducir en la Web porque las API Web no están tan avanzadas, eso creo.

Acá el problema no es que las "bibliotecas WEB" no estén tan desarrolladas para acceder a la agenda del cliente de correo, sino que por razones de seguridad ninguna aplicación web debe acceder a tu equipo sin autorización. Remarco la parte de sin autorización porque podría decirse que (estoy imaginandome un caso) puedas desarrollar un plugin para el navegador que haga de "puente" entre el cliente de correo y la web cada ves que encuentre una cabecera en el html :rolleyes:, nunca lo he hecho, solo se me ocurre que así podría hacerse.

Otra posibilidad sería que la agenda de clientes esté almacenada en un servidor, no en los clientes de correo. Una, de muchas soluciones de este tipo sería utilizar un servidor LDAP y configurar todos los clientes para que utilicen este como repositorio de contactos y a la vez a Django para que lea estos datos cada vez que lo necesite.

Acá hay un poco de la sincronización de los clientes de correo con el LDAP: http://www.sudleyplace.com/LDAP/index.en.html


Por otro lado, cuando trabajo con HTML y CSS suelo utilizar poco los editores visuales. Soy programador y me gusta trabajar a nivel de código. Además que tengo hasta el más mínimo control sobre lo producido. Es por eso que te digo que hacer una interfaz rica (así como Facebook) requiere de bastante código en HTML, CSS y ni mencionar Javascript, que en ése sí que estoy "crudo".
Concuerdo en esto, yo también prefiero la edición en texto plano :cool:. Prueba con un framework CSS, como el que cite arriba, fuild960gs, 960gs, blueprint, y una lista larga de sitios que hablan al respecto (http://www.google.com/search?q=frameworks+css). Te darás cuenta de la facilidad con que terminarás desarrollando/diseñando interfaces web.

Saludos.

[Chris]

Pero, para qué quieres mandar un correo a través de un cliente como Thunderbird o Outlook si puedes mandarlo directamente desde tu aplicación? Y esto aplica tanto para una aplicación web como para una de escritorio.

Lo que pasa es que se necesita tener la posibilidad de que el usuario revise y haga modificaciones al correo generado. Adjunte nuevos archivos o modifique el contenido del mensaje. :-/

[D-MO]

Eso, DESCARTADO! :mad:

... Y yo que esperaba el trabajo :(:o:p:D

Saludos.

[roman]

Eso, DESCARTADO! :mad:

No veo porqué del enojo. Puedo entender que no exista la opción pero negarse sólo por querer tomar el control total no me parece una buena razón.

Gran parte de las aplicaciones WEB requieren de un diseñador profesional. Dudo mucho, por ejemplo, que Facebook esté diseñado por un programador.

// Saludos

[roman]

Lo que pasa es que se necesita tener la posibilidad de que el usuario revise y haga modificaciones al correo generado. Adjunte nuevos archivos o modifique el contenido del mensaje. :-/

¿Y? Todo esto lo puedes hacer, con aplicaciones web o de escritorio. No entiendo.

// Saludos

[Chris]

Acá el problema no es que las "bibliotecas WEB" no estén tan desarrolladas para acceder a la agenda del cliente de correo, sino que por razones de seguridad ninguna aplicación web debe acceder a tu equipo sin autorización. Remarco la parte de sin autorización porque podría decirse que (estoy imaginandome un caso) puedas desarrollar un plugin para el navegador que haga de "puente" entre el cliente de correo y la web cada ves que encuentre una cabecera en el html :rolleyes:, nunca lo he hecho, solo se me ocurre que así podría hacerse.


En realidad me refería a una aplicación Web accediendo a otra aplicación web por medio de una API, a cómo accedes a datos de Facebook, Twitter o Google. Además necesito más que simplemente acceder a una lista de contactos. Necesito poder hacer un correo y permitirle al usuario hacer una revisión final a éste. Es como si yo desde mi aplicación pudiera redirigir al usuario a una ventana de redacción de GMail previamente auto rellenada con datos proporcionados por mi aplicación.

Pero me gusta e interesa esa idea de la PlugIn que me has mencionado. :-/

Bueno, al final creo que podría prescindir de esta funcionalidad y mandar a todos a hacerlo a la antigua, que redacten sus correos manualmente a cómo lo hacían hasta hace unos años.

[Chris]

No veo porqué del enojo. Puedo entender que no exista la opción pero negarse sólo por querer tomar el control total no me parece una buena razón.

Gran parte de las aplicaciones WEB requieren de un diseñador profesional. Dudo mucho, por ejemplo, que Facebook esté diseñado por un programador.

// Saludos

Es que no es por mí Roman, es porque sé que mis jefes lo descartarán. Ni se los propondría de hecho.

[Al González]

Hola Chris.

Dada tu situación y experiencia con Delphi, mi consejo en cuanto a las interfaces de usuario sería que hagas en Web lo que estrictamente hablando deba poder usarse desde cualquier computadora con navegador y conexión a Internet. El resto, mientras no haya reparos para usar Windows, en Delphi. Es un error común creer que toda la interfaz de usuario debe estar en una misma plataforma.

En cuanto a las capas en la parte Delphi, si no hay una necesidad real de contar con un servidor de aplicaciones, entonces usa tres capas "lógicas": en un módulo de datos los componentes de acceso directo a la base de datos (recomiendo dbExpress) y sus proveedores, y en otro los objetos TClientDataSet; y las clases debidamente separadas en unidades .pas de lógica de negocios por una parte, y en otras unidades las clases, rutinas y manejadores de eventos que tienen que ver directamente con la interfaz de usuario. Todo compilado como una sola aplicación.

Pero cuando sea inminente el establecimiento de tres capas físicas, divides tu aplicación Delphi en dos partes: tomando por un lado los elementos que son necesarios para compilar un servidor de aplicaciones y por otro lado lo que corresponde a la interfaz de usuario. Y agregas entonces los elementos DataSnap adicionales para lograr la comunicación entre las dos aplicaciones.

Lo que no tengo claro del todo, y con este comentario me uno a tus inquietudes esperando alguna orientación de quienes ya lo han logrado, es cómo hacer que una interfaz de usuario Web tenga franca comunicación y aprovechamiento de un servidor de aplicaciones Win32 creado en Delphi. Es decir, que el servidor de aplicaciones (capa intermedia) sirva tanto a interfaces de usuario Windows, como a interfaces de usuario Web. ¿Han visto algún material por ahí que lo explique con claridad?

Saludos.

Al González. :)

[D-MO]

Bueno, al final creo que podría prescindir de esta funcionalidad y mandar a todos a hacerlo a la antigua, que redacten sus correos manualmente a cómo lo hacían hasta hace unos años.
¿Porqué prescindir si puede estar integrada en la aplicación?, te planteaba el caso porque pensé que era de si o si trabajar con el cliente de correo, pero si este no es el caso, concuerdo con Román, integrar toda la funcionalidad en la aplicación, deríamos que creas un pequeño CRM que almacena información de los usuarios y puedas enviarle un correo, con una plantilla predefinida le muestras al usuario un "textarea" con este texto para que modifique o lo deje así y pueda cargar archivos para enviarle. Esto es mucho mas fácil que integrarlo con el LDAP o el Plugin para el navegador.

Saludos.

[roman]

Dada tu situación y experiencia con Delphi, mi consejo en cuanto a las interfaces de usuario sería que hagas en Web lo que estrictamente hablando deba poder usarse desde cualquier computadora con navegador y conexión a Internet. El resto, mientras no haya reparos para usar Windows, en Delphi. Es un error común creer que toda la interfaz de usuario debe estar en una misma plataforma.

Esto, en teoría, suena muy bonito. Pero en la práctica termina uno duplicando esfuerzos. Por eso es que, si bien común, no es tan erróneo. Yo lo he hecho, pero no siempre es factible dividir todo en dos grandes grupos: lo que puede hacerse en web y lo que puede hacerse en escritorio. Siempre hay funcionalidades que requieres en ambos casos y terminas codificando cosas similares para ambos ambientes.

// Saludos

[Chris]

Gracias Al por tus comentarios.


Lo que no tengo claro del todo, y con este comentario me uno a tus inquietudes esperando alguna orientación de quienes ya lo han logrado, es cómo hacer que una interfaz de usuario Web tenga franca comunicación y aprovechamiento de un servidor de aplicaciones Win32 creado en Delphi. Es decir, que el servidor de aplicaciones (capa intermedia) sirva tanto a interfaces de usuario Windows, como a interfaces de usuario Web. ¿Han visto algún material por ahí que lo explique con claridad?
El modelo puede ser este:
http://delphimax.files.wordpress.com/2010/12/server-layout.png

Lo ví en esta entrada del blog de Jon Lennart Aasenden (http://delphimax.wordpress.com/2010/12/01/intraweb-forgot-all-about-it/) (muy bueno y lo recomiendo de hecho)

Por otro lado, no me queda claro el termino "Servidor de Aplicaciones". No sé si es algo así como un servidor web, que en lugar de servir páginas HTML, "sirve" aplicaciones :o. O algo más bien cómo "Un servidor que sirve/envía datos a las aplicaciones"

[Chris]

Si ven la arquitectura que les proporcioné, notarán que casi todo depende de Windows, es por eso que no es de mi simpatía. Además hacer dos clientes, uno para Intraweb y otro un "cliente ligero" hecho en Delphi me parece redundar tu trabajo. Trabajar doble en términos prácticos.

[Chris]

¿Porqué prescindir si puede estar integrada en la aplicación?, te planteaba el caso porque pensé que era de si o si trabajar con el cliente de correo, pero si este no es el caso, concuerdo con Román, integrar toda la funcionalidad en la aplicación, deríamos que creas un pequeño CRM que almacena información de los usuarios y puedas enviarle un correo, con una plantilla predefinida le muestras al usuario un "textarea" con este texto para que modifique o lo deje así y pueda cargar archivos para enviarle. Esto es mucho mas fácil que integrarlo con el LDAP o el Plugin para el navegador.

Es una buena idea. Talvez como incluir como parte de mi aplicación un redactor de correos. Talvez una versión modificada de RoundCube Mail (http://roundcube.net/) talvez. Trabajo extra, pues sí. Pero ofrecerle una buena aplicación a tus clientes, no tiene precio... :P.

[Al González]

[...] Siempre hay funcionalidades que requieres en ambos casos y terminas codificando cosas similares para ambos ambientes.
Entiendo el punto, es algo a tomar en cuenta. :)

Chris: Gracias por el enlace, lo estudiaré. En cuanto al término que refieres, yo lo entiendo de la misma forma que la ayuda de Delphi, Wikipedia, etc. (application server).

[D-MO]

Es una buena idea. Talvez como incluir como parte de mi aplicación un redactor de correos. Talvez una versión modificada de RoundCube Mail (http://roundcube.net/) talvez. Trabajo extra, pues sí. Pero ofrecerle una buena aplicación a tus clientes, no tiene precio... :P.
Quizá no estamos hablando de lo mismo, ¿quieres simplemente mandar mensajes de correo a los clientes o un completo cliente de correo (sea web o de escritorio)?

[Chris]

En cuanto al término que refieres, yo lo entiendo de la misma forma que la ayuda de Delphi, Wikipedia, etc. (application server).

Creo que el termino aún así es muy ambiguo si lo usamos en Delphi. Más en caso de las aplicaciones en tres capas hechas con el IDE. Donde la aplicación o solución está hecha por tres partes. Bueno, no sé. Creo que le daré su interpretación dependiendo el contexto en que se use :-/

[roman]

Es una buena idea. Talvez como incluir como parte de mi aplicación un redactor de correos. Talvez una versión modificada de RoundCube Mail (http://roundcube.net/) talvez. Trabajo extra, pues sí. Pero ofrecerle una buena aplicación a tus clientes, no tiene precio... :P.

Ni tan extra, a menos que de verdad quieras reinventar tooooda la rueda. Hay muchos editores wysiwyg que puedes integrar a tu aplicación. Por ejemplo, TinyMCE (http://tinymce.moxiecode.com/).

// Saludos

[D-MO]

Ni tan extra, a menos que de verdad quieras reinventar tooooda la rueda. Hay muchos editores wysiwyg que puedes integrar a tu aplicación. Por ejemplo, TinyMCE (http://tinymce.moxiecode.com/).
Exacto, todo dependerá de lo que quiera hacer:


Si solo será enviar correos a los clientes/contactos, bastará con utilizar un textarea (reemplazado por el editor wysiwyg preferido, si lo quisiera) y enviarlos desde la misma aplicación, que hablando de django, acá está el como: http://docs.djangoproject.com/en/1.3/topics/email/
Si quisiera un completo cliente de correo, allí si, mejor vincular el sistema con cualquiera ya funcional, como el roundcube.


Saludos.

[roman]

¿Django lo puedes integrar a interfaces de escritorio? Porque he visto algo de lo que puede hacerse con, por ejemplo, WxPython, y, aquí sí, creo que puede ser buena opción para hacer interfaces duales (web y escritorio) pues puedes usar el mismo código.

// Saludos

[Chris]

Quizá no estamos hablando de lo mismo, ¿quieres simplemente mandar mensajes de correo a los clientes o un completo cliente de correo (sea web o de escritorio)?

Mira, lo que sucede es que los usuarios de mi aplicación necesitan enviar correos electrónicos -claro!-. La utilidad que brinda mi aplicación es que ésta puede automatizarle gran parte del trabajo al crearles un correo que ya tenga cuerpo y asunto -el cuerpo del mensaje se toma de algún archivo de Word previamente guardado en el sistema-.

Te lo muestro con imágenes:
En esta ventana de la aplicación, el usuario elige los archivos que adjuntará en el nuevo correo y además con que archivo de Word iniciará la redacción del nuevo correo.
http://waodelphi.files.wordpress.com/2011/03/new-mail.png

Luego, cuando el usuario da clic en "Enviar", la aplicación por medio de MAPI hace un enlace al cliente de correo principal instalado en la máquina, en este caso Thunderbird. La ventana de redacción que aparece ya se ha previamente rellenado con un Asunto, un cuerpo y con archivos adjuntos.
http://waodelphi.files.wordpress.com/2011/03/mail-composition.png
Ahora, por último el usuario tiene la posibilidad de hacer cambios al correo, elegir un remitente de la lista y adjuntar más archivos si así lo desea. El cuerpo del correo que ves, fue tomado de un archivo word elegido por el usuario en la ventana anterior.

Esa es la funcionalidad que me gustaría reproducir en una aplicación Web y que veo díficil hacerla.

[roman]

A ver. En general podría decirse que en una aplicación web te vas a encontrar más dificultades para crear interfaces amigables, aunque se ha avanzado mucho y hay bibliotecas que tienen widgets muy buenos. Pero en sí, no veo que esto que describas no puedas hacerlo en web. Ni siquiera veo porqué optaste por hacerlo así (enlazar con MAPI) en la aplicación de escritorio.

Todo, adjuntos, encabezados, texto predeterminado, etc. lo puedes hacer en una aplicación web.

// Saludos

[D-MO]

¿Django lo puedes integrar a interfaces de escritorio? Porque he visto algo de lo que puede hacerse con, por ejemplo, WxPython, y, aquí sí, creo que puede ser buena opción para hacer interfaces duales (web y escritorio) pues puedes usar el mismo código. La verdad no he evaluado esta posibilidad, django es realmente un framework para aplicaciones web, se encarga del manejo de sesiones, urls, peticiones, plantillas html, etc... está construido con la visión de ser usado en la web exclusivamente. Sin embargo, viendo el caso, se me ocurre que, con el conocimiento necesario, se podría desarrollar una aplicación con que tome como base los modelos definidos en django (en los modelos se definen toda la lógica del negocio) para utilizarlos con una interfaz gráfica con wxPython, pyGtk, pyQt, etc...

Pero yo preferiría proveer un servicio (webservice) en la aplicación django que sirva para comunicar una aplicación cliente (Delphi, Java, Python, etc...) con la aplicación web.

Saludos.

[Chris]

Ni siquiera veo porqué optaste por hacerlo así (enlazar con MAPI) en la aplicación de escritorio.
¿De que otra forma lo hubiese poder hecho Román?

[roman]

Si no me equivoco, tú también has trabajado con PHP ¿no? Si es así, ¿cómo ves uno contra otro? Digo, porque se me antoja aprender python y a la larga me late que sería mucho mejor. ¿Qué opinas?

// Saludos

[D-MO]

Todo, adjuntos, encabezados, texto predeterminado, etc. lo puedes hacer en una aplicación web.

Completamente de acuerdo, la aplicación (web o de escritorio) puede hacer esta tarea sin mucho esfuerzo, cargas losa adjuntos, muestros el texto a enviar, te conectas a un smtp y enviado. Todo desde la misma aplicación (web o escritorio).

Saludos.

[roman]

¿De que otra forma lo hubiese poder hecho Román?

Hubiera usado Indy para mandar los correos. Además, se adaptaría más a tu filosofía de tener todo bajo tu control :p

// Saludos

[Chris]

Si no me equivoco, tú también has trabajado con PHP ¿no? Si es así, ¿cómo ves uno contra otro? Digo, porque se me antoja aprender python y a la larga me late que sería mucho mejor. ¿Qué opinas?


No sé si me lo has preguntado a mí o a D-MO, pero igual yo voy a dar mi opinión :p. He usado PHP pero no me gusta. Para mí ese lenguaje debería llamarse C++Script. Me gusta Python porque lo siento más moderno, sencillo. En realidad mayormente evito PHP por el hecho de su estilo C++ de hacer las cosas. A estos chicos de PHP solo les faltó usar los archivos *.H

[roman]

Ja, ja. Nada más te faltó como mamcx, decir que es el VB de la web. La verdad es que yo no lo veo tan mal y no me disgusta la sintaxis C, pero lo poco que he visto de python me entusiasma.

// Saludos

[Chris]

Hubiera usado Indy para mandar los correos. Además, se adaptaría más a tu filosofía de tener todo bajo tu control :p

// Saludos

Jajaja, si pero aveces también hay que saber delegar el trabajo... Hubiese sido demasiado trabajo porque además de enviar el correo, se tenía que guardar copia con IMAP. Era demasiado, mejor le redirigía el trabajo al cliente de correo.

[Chris]

Ja, ja. Nada más te faltó como mamcx, decir que es el VB de la web
jajaja, no pues mamcx ya exagera. Es cierto que PHP complica demaciado las cosas para ser un lenguage Script. Pero tampoco no es tan Shi* como VB, VisualShit como le dice Azid :p.

[D-MO]

Si no me equivoco, tú también has trabajado con PHP ¿no? Si es así, ¿cómo ves uno contra otro? Digo, porque se me antoja aprender python y a la larga me late que sería mucho mejor. ¿Qué opinas?
Si el mensaje va dirigido hacia mi, estás en lo cierto, he trabajado (y sigo trabajando) con PHP.

Comparar uno con otro, se me hace muy difícil. Con Python tengo apenas unos meses (quizá un año), y podría decir que lo domino mejor que PHP, con el que llevo varios años (de 5 a 6).

La razón por la que me dicidí a probar Python fué por la "necesidad" de aprender a utilizar los muy "famosisisisimos" frameworks web. Estaba cansado de hacer todo desde cero, repetir lo mismo con cada aplicación (que a decir verdad no han sido muchas).

El primero que probé fué Symfony, basado en PHP, no me gustó. Probé Cake, no me gustó, probé un montón en PHP que no me convencieron, y no me refiero a pruebas de media hora, sino al menos una semana cada uno tratando de desarrollar lo mismo, determiné que tratar de desarrollar un blog + admin + usuarios/roles podría darme una idea de las prestaciones que me daría el framework. Con algunos logré algo avanzado, otros me dieron muchos dolores de cabeza.

Después de mi decepción con los frameworks de PHP, decidí ir por otros rumbos, probé Ruby on Rails, por ser el que mas popularidad tenía (no se si aun la tiene), al principio me gustó, lo sentí mas rápido (el desarrollo) pero al llegar a implementar algunas funciones específicas me sentí atado de manos, quizá por mi nulo conocimiento de ruby (que lo iba aprendiendo de la mano con rails).

Al conocer Ruby incluso pensé en aplicar la misma lógica en PHP, desarrollar un "mini-framework" que me facilitara el trabajo. Podría decir que lo llegué algo avanzado, pero no me parecía muy eficiente, no me gustaba la idea de reinventar la rueda.

Desde que empecé a probar los frameworks, había leido sobre python pero lo veía con desprecio, extrañaba las "migraciones" de rails, entre otras cosas. Sin embargo, ya después de haber probado un montón decidí a probarlo, de entrada con el tutorial en la página de django, muy bien explicado. Descubrí la interfaz de administración automática, un gran punto a favor. Empecé a familiarizarme con el framework, estudiar un poco de python, etc, etc...

Después de unos 3/4 meses probando uno y otro me quedé con Django, no soy ningún experto, pero me gusta y lo siento mas flexible que muchos otros. Lo he instalado incluso en cuentas compartidas en servidores web sin soporte para python, una belleza :D.

Espero que mi relato sirva de algo.

Saludos.

[roman]

Gracias por la opinión. La valoro en lo que es. Precisamente porque sabía que tú usabas PHP. Creo que en ocasiones se devalora a PHP más que por una razón real, por un sentimiento de que lo popular es malo y creo que muchas veces esas opiniones se basan, como dices, en pruebas de media hora.

Pero siendo tú un programador medianamente experimentado en ambos lenguajes, el relato que haces dice mucho y me da un empujón más para acercarme a python :).

// Saludos

[D-MO]

...en pruebas de media hora...
Esto es lo que siempre me ha molestado cuando alguien dice A es mejor que B, cuando yo se que esas opiniones se basan lo que leyeron en un lado u otro, casualmente, donde hay inclinación por uno en específico.

Si yo aquí pregunto, Delphi vs Java, obvio que todos me dirán Delphi, de una vez. Si pregunto en un foro Java, obvio que dirán que Java. Muchos se basan solo en eso, en lo que leen, ven o escuchan, no en la puesta en prueba de ambas herramientas con el mismo escenario.

Yo sigo trabajando con PHP, me gusta mucho Drupal (con Django no he encontrado un CMS que me convenza) y sigo trabajando con el.

Ánimo en tus caminatas por estos rumbos, python es un lenguaje que me ha demostrado ser muy potente, y Django, no digamos.

Saludos.

[D-MO]

Dos posts arriba escribí sobre las migraciones (http://guides.rubyonrails.org/migrations.html) de rails que era lo que extrañaba en django. Olvidé agregar que después de probar y quedarme con Django encontré una herramienta que me gusta mas incluso que la herramienta de Rails. Esta se llama South (http://south.aeracode.org/). La herramienta me permite, teniendo un modelo inicial en una aplicación, modificarlo y mantener un histórico de la estructura de cada modelo/clase, automatizando la migración de una versión a otra de mi aplicación. Todo esto olvidándonos del SQL. Prácticamente es lo mismo que las migraciones de Rails, pero con el toque personal de Django, mas "perfeccionista" :D

No es por quitarle mérito a Rails, la verdad que lo admiro por ser de los primeros frameworks para la web que facilitan en gran medida el trabajo. Gracias a este han nacido muchos otros buenos frameworks, entre ellos, Django.

Saludos.

[roman]

Lo he instalado incluso en cuentas compartidas en servidores web sin soporte para python, una belleza :D.


¿A qué te refieres con esto?

// Saludos

[D-MO]

¿A qué te refieres con esto?
Interesante... ¿No? :D

Como sabemos, no todos tenemos la plata para pagar un servidor dedicado y muchas veces las aplicaciones no tendrán tanta demanda como para justificar este gasto. Ese es el punto fuerte de PHP, me atrevería a decir que todos los proveedores de hospedaje web compartido ofrecen soporte pare este. Con Python/Django la situación es otra :o:(.

Cualquier aplicación/script python puede correr en el servidor web de varias formas, mi favorita es FastCGI (aquí (http://docs.python.org/howto/webservers.html) las demás).

Entonces, lo que necesitamos para tener django corriendo en un servidor web es, Python en el Servidor y soporta para FastCGI (en mi caso).

FastCGI es soportado casi en la mayoría de los servidores web, aquí el punto a favor.

Python está en casi todas las distribuciones linux desde que se instala, sin embargo, para instalar django es necesario agregar a nuestro "PYTHON_PATH" la ubicación tanto de Django, como de todos las herramientas adicionales que utilizaremos (reportlab, pil, etc) que de manera predeterminada no estarán en el servidor. El problema se presenta al momento de quered instalar estas herramientas, podemos hacerlo manual, agregando una a una las ubicaciones de estos paquetes dentro de el archivo de arranque del fastcgi, pero sería un trabajo sucio.

La solución a esto es:

Primero: Compilar los fuentes de Python e instalarlo dentro de la carpeta de usuario en el servidor, así tendríamos una instalación privada de python. En mi caso fué muy fácil gracias a que en esta cuenta tengo acceso vía ssh, pero pienso que igual podría compilarlo en local y cargarlo al servidor.

Compilados los fuentes, podemos instalar cualquier paquete python, descargamos los fuentes de estos y ejecutamos /home/<user>/bin/python setup.py install. Este comando instalará el paquete en la ruta de nuestro python, no el que tenía el servidor. Así instalamos django y cualquier otro que necesitemos.

Segundo: Como tenemos soporte fastcgi, tenemos que crear un archivo en nuestro directorio cgi-bin (el comun en servidores compartidos), llamémosle "cargadorfcgi.py", con el siguiente contenido:


#!/home/<user>/bin/python

import sys, os

os.environ['DJANGO_SETTINGS_MODULE'] = "djangoproject.settings"

from django.core.servers.fastcgi import runfastcgi
runfastcgi(method="threaded", daemonize="false")


Importante la primera línea, pues indicames en que ubicación está el interprete de este código, así el FastCGI ejecutará el archivo y el SO lo pasará a nuestro interprete.

Luego indicamos en la tercera línea el módulo que deberá cargar con la configuración del proyecto.

y sobreescribimos la url para que todas las peticiones a la raiz sean enviadas al fastcgi, quedando el .htaccess de esta manera (no soy ningun experto en esto, quizá se pueda mejorar)

RewriteEngine On
RewriteBase /
RewriteRule ^(media/.*)$ - [L]
RewriteCond %{REQUEST_URI} !(cgi-bin/cargadorfcgi.py)
RewriteRule ^(.*)$ cgi-bin/cargadorfcgi.py/$1 [L]


En sí esta es la idea, puede mejorarse... ¡¡Y mucho!!, pero la base acá está. No he tenido ningún problema con ello y lleva funcionando desde el 13 de septiembre del 2010 :p:D(ls -F ./cgi-bin)

Espero que sirva de algo.

Saludos Cordiales

[roman]

Joder! Mira todo lo que había detrás de una frasesita :D

Es lo bueno de este tipo de hilos; que resultan muy iluminadores. Mira que yo me hubiera ido de frente con mod_python :o Viendo el enlace que pones, aun cuando en mi caso sí podría acceder a la configuración del servidor, me entero que no es la mejor opción.

// Saludos

[D-MO]

Joder! Mira todo lo que había detrás de una fracesita :D Jejejejeje :p... A veces no hay inspiración para escribir :o

...aun cuando en mi caso sí podría acceder a la configuración del servidor...
Yo también tengo acceso a mi servidor, pero hay ocasiones en que el cliente no dispone de ello, es allí donde salen estos "truquitos".

mod_python no lo he utilizado nunca, ni siquiera en local pues desde que uso Django leí esta información en el enlace que cito.

Saludos.

[Chris]

Para una guía detallada, puedes también leer el capitulo dedicado a los lanzamientos de proyectos Django del libro de Django (http://www.djangobook.com/en/2.0/chapter12/)

Pero volviendo un poco al tema del hilo, en síntesis que opinan sería lo mejor para hoy y el futuro. Teniendo en cuenta los nuevos modelos de distribución SaaS y la nube.

[roman]

D-MO:

No sé si ya lo mencionaste. ¿Con que motor de datos has trabajado con python?

// Saludos

[D-MO]

...libro de Django
Una fuente de información muy buena, complementa la documentación de django. Hay algunas cosas desactualizadas pues está escrito para la versión 1.0 de django (ya va por la 1.3) pero si hay buena información.

...en síntesis que opinan sería lo mejor para hoy y el futuro. Teniendo en cuenta los nuevos modelos de distribución SaaS y la nube.
Por las cosideraciones a tomar según esta frase, de las opciones que dás, opino que django.

[D-MO]

D-MO:

No sé si ya lo mencionaste. ¿Con que motor de datos has trabajado con python?

// Saludos
Creo que no lo he mencionado, desarrollo lo trabajo con sqlite3 pues para que sobrecargar mi pobre máquina (que ya no dá para mas) con un servidor "activo" mientras desarrollo. Al finalizar una aplicación o querer probarla con otro motor de bd, hago lo siguiente:

Con el sistema funcionando con slqite3, descargo la información (registros en la bd) con la que he trabajado para no tener que volver a llenar la nueva bd a mano.
python manage.py dumpdata > dump_XXX.json

Luego edito el settings.py para indicar la conexión a la otra bd (MySQL, PostgreSQL). Seguido hago el proceso de instalación de mis modelos en la bd:

python manage.py syncdb

Y por último, cargo a la nueva bd la información que saqué de la otra (sqlite3):

python manage.py loaddata dump_XXX.json

Y listo, con esto tengo toda la información con otro motor de bd. :cool:

Pero respondiendo a tu pregunta, en desarrollo siempre uso sqlite3, en producción he usado MySQL (mas que todo en cuentas compartidas que no proveen soporte a PostgreSQL) y una o dos con PostgreSQL.

Acá en el trabajo tengo una aplicación funcionando con sqlite3, no tiene mucha demanda y ha funcionado muy bién.

Para la aplicación que planteo acá (http://clubdelphi.com/foros/showthread.php?t=73041) pretendo usar PostgreSQL, aunque si la llego a desarrollar, al liberarla (planeo hacerlo bajo la licencia BSD) sabemos que podrá utilizarse con cualquier motor soportado por Django.

Saludos.

[roman]

:eek: ¡Guau! ¿¡Así de transparente es el cambio!?

Este sólo mensaje tuyo debería bastar a cualquiera para probar el framework!

// Saludos

[Chris]

:eek: ¡Guau! ¿¡Así de transparente es el cambio!?

Este sólo mensaje tuyo debería bastar a cualquiera para probar el framework!


Es por eso que ya he preelegido este framework! De verdad es productivo. Es el Delphi de la web creo.

[D-MO]

:eek: ¡Guau! ¿¡Así de transparente es el cambio!?

Este sólo mensaje tuyo debería bastar a cualquiera para probar el framework!

// Saludos

Así es, siempre y cuando no toques nada de la estructura del SQL, que será así en la mayoría de los casos si te apegas a la forma de Django de hacer las cosas.

Pues espero que se animen a probarlo, a ver si es cierta la filosofía de "Probó y le gustó" :D. Yo si lo probé y me gustó :p.

Saludos.

[D-MO]

Este sólo mensaje tuyo debería bastar a cualquiera para probar el framework!...
... ¿y será suficiente para justificar la creación del subforo Python en el grupo de Otros Entornos y Lenguajes (http://clubdelphi.com/foros/forumdisplay.php?f=12)?

[roman]

¡Hombre! Para eso soy moderador!! Uy, no, eso sonó dictatorial :D

Ja, ja. Deja plantearlo a los demás moderadores. Ayudaría saber que vas a escribir una introducción al framework, je, je.

// Saludos

[D-MO]

...Ayudaría saber que vas a escribir una introducción al framework, je, je
Si eso ayuda, ¡¡¡Con gusto!!!

[AzidRain]

Aquí la clave es que mencionas que vas a empezar de ceros, entonces es más recomendable irte por la parte de PHP y compañía, pues si bien es algo nuevo para tí, todo el proyecto lo es por lo que no pierdes nada. Si se tratara de un proyecto ya en marcha o hacer cambios, entonces sí, lo mejor es quedarse con lo que trabajas más rápido.

Sin quererme plantar como experto creo que cuando iniciamos un proyecto totalmente nuevo es el mejor momento para aplicar y empezar con todas esas cosas que se nos van presentando y que tenemos la inquietud de probar. Eso sí, en algún momento dado tendrás que regresarte y retomar el diseño o alguna parte de tu desarrollo pero al final te va a dar muchos beneficios intelectuales.

En mi caso, nuestro mejor desarrollo empezó en Clipper 5.0 y ya lo hemos migrado varias veces a diferntes lenguajes de acuerdo con lo que hemos ido aprendiendo y mejorando, la clave es contar con un modelo sólido.

[rgstuamigo]

Bueno amigo Chris, aunque no tengo mucha experiencia en el ámbito web, pues mi sugerencia es que tambien existen Framework para delphi para crear aplicaciones tanto para la web como de escritorio, si revisas éste (http://www.clubdelphi.com/foros/showthread.php?t=71615) hilo veras que hay muchas alternativas, yó en lo particular he probado Raudus (http://www.raudus.com/), Morfik (http://www.morfik.com/), aunque viendo tu caso y mirando la documentacion estoy empezando a decantarme por UniGUI (http://www.unigui.com/) que segun su wed dice:"Cada aplicación uniGUI puede ser considerada tanto como un escritorio y una aplicación web, al mismo tiempo.":eek:
claro está que aún está en una version Beta y sólo funciona en versiones igual o superior a Delphi 2006, pero se vé muy prometedor...
¿Qué te parece?
Puede ver un demo online aquí (http://www.unigui.com/en/demo.html). y ver el funcionamiento de sus componentes...
Saludos...:)

[roman]

¿Qué requerimientos tienes en el servidor que contenga la aplicación web? Porque me imagino que está restringido a servidores windows ¿o me equivoco?

// Saludos

[rgstuamigo]

Bueno eso puedes verlo en la documentacion (http://www.unigui.com/en/resources/online-documentation.html) OnLine, logicamente se pueden construir Modulos para Apache y todos sabemos que apache es multiplataforma;)
Aquí (http://www.delphiaccess.com/forum/aplicaciones-de-internet-enriquecidas-%28ria%29/) un foro "amigo" dedicado a todas las aplicaciones RIA (http://es.wikipedia.org/wiki/Rich_Internet_Applications) entre los que se halla uniGUI..;)
Saludos...:)

[roman]

Apache es multiplataforma pero ISAPI no, y según leo del enlace que pones, lo que hay es un módulo ISAPI para Apache.

// Saludos

[D-MO]

Concuerdo con el mensaje de mamcx aquí (http://clubdelphi.com/foros/showpost.php?p=386975&postcount=9):
Algo que no me cuadra es tratar de hacer una aplicación web tipo escritorio.

Delphi es una herramienta muy buena, no le quito mérito, sin embargo, fué hecha y seguirá siendo para escritorio por algún tiempo mas. Al césar lo que es del césar.

Saludos.

[Chris]

Gracias rgstuamigo! Pero tengo una mala impresión de todas estás herramientas/frameworks. Para mí, no son "ni chicha ni limonada", no son ni una ni otra cosa. Casi siempre prefiero evitar este tipo de productos o herramientas.

Yo creo que mejor me voy por Django. Talvez en un futuro implemente un "servidor de aplicaciones" dentro de la misma aplicación Web, en el caso que se llegue a necesitar programar clientes ricos, como para iOS, Android o Windows utilizando Delphi.

Pienso que sería la opción que le permitiría a la aplicación adaptarse al mundo de hoy más fácilmente. Es más trabajo, claro! Pero talvez hacerlo de otra forma sea una inversión que no va a tener valor en un mediano plazo.

Eso es lo que estoy pensando :-\

[rgstuamigo]

Apache es multiplataforma pero ISAPI no, y según leo del enlace que pones, lo que hay es un módulo ISAPI para Apache.

// Saludos
Bueno no podemos exigirle demasiado a una herramienta que todavía está en una version Beta;)...mejor esperemos que salga una version estable por lo menos, por otra parte , como ya mencioné existen otras tambien... entre las cuales hay multiplataforma(segun lo que he visto) y a cada una hay que darle una buena probada para recien emitir nuestra opinion o si no nos estariamos contradiciendo a nosostros mismos cuando decimos que nos enojamos por que otros ni siquiera prueban la herramienta y aún así dan su opinion...;)
Saludos...:)

[Casimiro Notevi]

Vaya, creo que no había visto este hilo, qué interesantísimo :eek:

[Julián]

Vaya, creo que no había visto este hilo, qué interesantísimo :eek:

Cierto.
Si se decanta por Python y Django, que a juzgar por los comentarios es lo mas recomendable, no quedaría nada mal un buen tutorial/curso/howto/loquesea que ilumine a los que no se terminaron de aclarar, como yo mismo, :)

A lo mejor podríamos poner en el servidor clubdelphi lo necesario para que funcionasen esas cosas.

Jau!

[D-MO]

...no quedaría nada mal un buen tutorial/curso/howto/loquesea...
Este se lo debo a román (http://clubdelphi.com/foros/showthread.php?p=395343#post395343) desde hace mas de un año :(... pero gracais a Django no me ha faltado el trabajo y me queda muy poco tiempo... en cuanto mejore mi distribución de tiempo seguro que lo hago :D
..A lo mejor podríamos poner en el servidor clubdelphi lo necesario para que funcionasen esas cosas...
¿y acaso necesitamos algo especial?... Apache soporta fastcgi desde hace ratos, python viene con cada distribución linux, así que para empezar (que no es que sea lo mejor) ya tenemos lo que se requiere.

Saludos.

[roman]

Mmmm, pero, teniendo, como tenemos, control sobre el servidor, ¿no sería mejor instalar el módulo wsgi para apache?

// Saludos