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

Gracias Al por tus comentarios.

El modelo puede ser este:


Lo ví en esta entrada del blog de Jon Lennart Aasenden (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"

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.

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 talvez. Trabajo extra, pues sí. Pero ofrecerle una buena aplicación a tus clientes, no tiene precio... :P.

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).

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)?

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 :-/

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.

// Saludos

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.

¿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

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.


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.

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.

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

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.

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

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

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.

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

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

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

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.