Integración de aplicaciones web con Drupal

Question

Queremos construir una aplicación web, que sea específica de nuestro dominio, pero que también incluya foros, blogs, etc. en esta aplicación. También se requieren algunos puntos de integración a Twitter y Facebook. También habrá una aplicación de escritorio que se conecta a nuestra aplicación web para cargar datos y descargar configuraciones e informes.

La pregunta es, ¿podemos extender Drupal para alojar los módulos regulares y nuestra aplicación web? (Habrá entidades comerciales y sus propiedades y datos diarios cargados desde la aplicación de escritorio) ¿O puede Drupal integrarse con aplicaciones externas? Como ejemplo, los usuarios y los roles deben ser iguales y consistentes en ambos. También podemos desear que los datos de la aplicación web puedan buscarse en Drupal.

Sé que esto es un poco vago, pero no puedo revelar más. Soy muy nuevo en administración de contenido y solo quería saber si alguien ha desarrollado este tipo de aplicación.

Answer 1

Intento reformular lo que escribiste, solo para que compruebes que recibí tu pregunta correctamente. Es, básicamente, tiene que crear una aplicación web que:

1. Implementa parte de la funcionalidad estándar de Drupal
2. Tiene alguna funcionalidad a medida que se debe "integrarse en" el Drupal (mismos usuarios, mismos permisos, etc .. .)
3. Poder cargar/descargar contenido (o datos) desde aplicaciones de escritorio.

Si te tengo bien, la respuesta corta es: sí, se puede hacer eso con Drupal.

Ahora para el extenso: - Drupal tiene literalmente miles de módulos, por lo que espero que obtenga la mayoría de las cosas que desea simplemente instalando la combinación correcta de módulos disponibles. - Por supuesto, cualquier funcionalidad personalizada puede implementarse fácilmente en forma de un módulo también (cosa bastante estándar en estos días). - La interacción con una aplicación de escritorio se implementa normalmente a través de los servicios web en lugar de consultar directamente la base de datos. Drupal viene de forma nativa con un servidor y cliente xmlrpc, pero puede escalar a SOAP, si lo desea, a través de un par de módulos contrib.

Algunos pensamientos adicionales:

• Si usted elige utilizar Drupal, y se inicia desde cero, entonces usted tiene que ser consciente de que usted y su equipo tendrá que dedicar un poco de tiempo y esfuerzo para entender cómo funciona Drupal . Aunque - a diferencia de Palantir - me quedé con Drupal, estoy de acuerdo con él/ella en el hecho de que Drupal obtiene complejo complejo desde el bate. Este es el compromiso que tiene que pagar para tener una plataforma que, tenga la seguridad, es muy flexible, extremadamente conectable y sólida (de lo contrario, no se habría utilizado para rediseñar the whitehouse, ni Drupal habría Obtuve por segundo año consecutivo el premio al "mejor PHP CMS", supongo.
• La buena noticia es que hay algunos libros excelentes, y ciertamente recomendaría "Pro Drupal Development" para una explicación completa y completa del sistema. Solo asegúrate de obtener la segunda edición, ya que la primera trata de los 5 seres ahora obsoletos. Dicho esto ...
• Algo muy bueno de Drupal, al menos en mi opinión, es que la mayoría de los ajustes que podrías necesitar para una funcionalidad existente se pueden implementar enganchando el código original desde un módulo personalizado también . Esta IMO es la mayor ventaja de Drupal: nunca tienes que tocar el código de otros desarrolladores para lograr tus objetivos, y esto significa, por ejemplo, que podrás mantener tus módulos centrales y de contribución actualizados sin romper ningún personalización que podría haber hecho.
• Drupal es pesado. En comparación con otros CMS, consume mucho poder de procesamiento y RAM de su servidor, y, a menos que vaya a tener un sitio muy pequeño, recomiendo implementarlo junto con nginx, en lugar de Apache.
• Drupal escala bien, gracias a un buen mecanismo de almacenamiento en caché y mecanismos de "estrangulamiento". Por extraño que parezca, Drupal se adapta muy bien a sitios web de gran tráfico, por lo que los grandes aumentos en el tráfico no implican necesariamente grandes aumentos en el uso de recursos.
• La experiencia del usuario desde el primer momento en un sitio de Drupal es bastante pobre. Se está realizando un gran trabajo al respecto en este momento (here y here (video)), pero las mejoras no estarán disponibles hasta que se lance D7 [pronto, pero luego tendrá que esperar a que se transfieran los módulos], por lo que aconsejable dedicar algo de tiempo para crear un tema administrativo, si los administradores de su sitio web no serán de tipo técnico.

Al final del día, mi consejo es: si su sitio va a ir grande/complejo/con la lógica de negocio complicado y muchas funcionalidades, a continuación, Drupal es probablemente un buen candidato.Si su sitio es contrario uno de pequeña escala con funcionalidad estándar más algunos bits personalizados, tal vez Wordpress/Joomla podría satisfacer sus necesidades mejor [no porque sean 'menos poderosos' sino porque las fortalezas de Drupal no se usarían en este caso, mientras que Wordpress/La arquitectura más simple de Joomla probablemente representaría una ventaja en este escenario]

Otras opciones serían marcos como CakePHP o Django, por ejemplo, pero eso - IMO - es un enfoque totalmente diferente del asunto, diría yo.

Answer 2

Como Drupal es de código abierto, puedes hacer prácticamente lo que quieras con él. Sin embargo, un par de puntos:

Cambiar la estructura de usuario/rol de Drupal sería tedioso e innecesario. Necesitará que su aplicación de escritorio se autentique desde la base de datos MySQL de Drupal.

Drupal tiene cientos de complementos para casi todo, por lo que Drupal podría sin duda ejecutar todo el lado "web" de las cosas incluyendo las estadísticas de visitantes, etc. Solo necesitaría, una vez más, conectar su aplicación de escritorio a las tablas MySQL correctas y muestre los datos como desee.

¡No olvide comprobar otros sistemas de gestión de contenido como Joomla! (y muchos otros). Cada uno tiene sus ventajas y desventajas. www.opensourcecms.com le permite probar fácilmente los CMS y lo he usado extensamente en el pasado.

Solo asegúrese de asignar primero todos los componentes. Cada hora de planificación anticipada ahorra muchas horas de dolores de cabeza más tarde.

Answer 3

Trabajé durante más de un año usando drupal extensamente, pero terminé abandonando. Drupal y otros sistemas CMS, tienen límites y reglas muy rígidos. Usaría Drupal para proyectos en los que tenga requisitos simples y pocas o ninguna reglas comerciales. Drupal se complica casi de inmediato cuando desea hacer cosas complejas (especialmente prestar atención al sistema de menús, formularios y al sistema de traducción si necesita ser multilingüe).

Si su sistema será realmente grande, con todas las cosas que mencionó, entonces preferiría usar un framework PHP para implementar su lógica de negocios, e integrar los productos externos a su medida (un foro, un blog, un twitter cliente, etc ...).

Pero el consejo es: no confíes en nadie :) Descárgalo y juega con él durante una semana. ¡Podrá tomar una decisión y estar más seguro de su elección!

Answer 4

Respuesta corta: Drupal es muy adecuado para construir algo así, especialmente si está dispuesto a integrar su aplicación/lógica en Drupal como un conjunto de módulos personalizados. Por otro lado, integrar Drupal en una aplicación externa también se puede hacer, pero te dará más fricción, ya que la arquitectura de Drupal está orientada a ser un framework por derecho propio.

---

Respuesta larga: tengo una opinión más o menos opuesta/experiencia en comparación con Palantirs. He estado trabajando casi exclusivamente con Drupal desde hace un año, en el contexto de dos proyectos "emprendedores" bastante complejos (después de varios años de uso 'en el lateral' para cosas más pequeñas). Aunque estoy de acuerdo en que impone algunas reglas rígidas (¡pero no límites!), Considero que esto es una ventaja, ya que esas reglas brindan una guía clara y brindan formas probadas de cómo hacer las cosas. Las tres partes Palantir menciona son buenos ejemplos de esto: sistema de

• Menú - Proporciona un mecanismo de reenvío bien estructurado y eficaz que es fácil de extender con su propio material, mientras que da gran flexibilidad para ajustar/manipular caminos/por defecto existente . (Tenga en cuenta que el 'sistema de menú' en Drupal denota todo el tema de la administración de su espacio de URL, no solo el subconjunto de menús 'visibles' que generalmente se asocia con el término)
• API de formularios: un enfoque declarativo de formularios web, con un flujo de trabajo de procesamiento bien diseñado y una gran cantidad de características de seguridad integradas que de otra manera tendrías que cuidar de ti mismo. También altamente extensible, con opciones directas para ajustar/extender formularios ya existentes bajo demanda, agregar nuevas reglas de validación a cualquier campo o formas enteras, formularios de pasos múltiples, ajustes de formulario basados ​​en JavaScript, etc.
• Sistema de traducción - Esto es bastante complejo, simplemente porque la internacionalización es muy difícil de hacer. Pero está integrado, una vez más dando una orientación clara sobre cómo hacer las cosas para trabajar de una manera genérica (aunque hay problemas con algunos módulos contribuidos que no lo usan/respaldan como deberían).

Podría dar más ejemplos de partes donde apreciar las 'reglas', pero esta entrada está consiguiendo mucho ya, y todavía tengo que cubrir algunas desventajas;)

para resumir lo positivo parte - si tuviera las especificaciones aproximadas que publicó, diría 'no hay problema' e iré con Drupal, confiando en que sería una base sólida para las partes personalizadas, a la vez que proporcionaría todos los 'estándares' como foros, blogs, integración de twitter/facebook y muchos, muchos otros en forma de soluciones ya existentes (a pesar de que podrían necesitar alguna adaptación/ajuste).

---

Desventajas: Como siempre, hay defectos, y algunos de ellos son sustanciales, dependiendo de los requerimientos/circunstancias.

• Curva de aprendizaje - Drupal es bastante complejo, y 'grokking' sus conceptos lleva tiempo."Jugar con él durante una semana", como sugiere Palantir, sin duda le dará una sensación general/amplia impresión, pero de ninguna manera es suficiente para permitir un juicio serio de sus pros y sus contras, ya que solo aparecerán mientras se codifica in/for it. Entonces, si ya está familiarizado con un marco de desarrollo web establecido, esto podría ser un problema. Si tiene que aprender uno de todos modos, esto debería ser un problema menor.
• Restricciones a la base de datos - A partir de Drupal 6, el soporte de base de datos es MySQL o PostgreSQL solamente, usando una 'capa de abstracción' específica de Drupal (que obviamente no es una;)
  Drupal 7 se moverá a PDO, que debería (finalmente) termina este estado cuestionable.
• Migraciones de prueba/etapa/producción: la flexibilidad de las partes de Drupals se debe a que muchas cosas se pueden configurar en el back-end administrativo, lo que implica que muchas configuraciones de configuración importantes se almacenan en la base de datos. Esto hace que la migración de datos y/o configuración entre varios casos muy difíciles/tedioso, una vez que sales de los (primeros) etapas de desarrollo donde se puede salir a auténtica basura/restaurar las operaciones (véase, por ejemplo this question & answers)

Estos son las principales para mí, pero probablemente encontrarás más :)