2010-04-07 9 views
6

El debate es que necesito un PHP Framework/Drupal con la flexibilidad de agregar funciones personalizadas a una aplicación potencialmente grande (web y con una API).Debo usar Drupal o Kohana-type framework para una "aplicación" web

Sin embargo, con un marco, como Kohana, me veo abordando y reinventando la rueda con cosas simples como gestión de cuentas y cosas cms. La administración de cuentas y la recopilación rápida de datos, como la creación rápida de formularios, son tediosas en Kohana, pero parecen increíbles y simples en Drupal. Por otro lado, en base a mi limitada experiencia en Drupal, dudo que crear "funciones" rápidas y personalizadas y permitir a los usuarios crear "grupos" y administrar sus propios roles dentro de esos grupos sea algo que Drupal puede lograr fácilmente.

Para simplificar, Drupal es capaz de aplicaciones web verdaderas; donde la aplicación es un servicio y proporciona resultados personalizados para cada usuario? ¿Puede proporcionar una interfaz parecida a un tablero para que los usuarios cambien sus configuraciones o preferencias? ¿Puede agregar datos de usuarios particulares para proporcionar mejores resultados/información a otros?

Si es así, por favor que me señale algún conocimiento :-)

Respuesta

5

Debo admitir de inmediato que soy un gran fan de Drupal y nunca he usado Kohana, por lo que esta publicación será unilateral.

En la empresa para la que trabajo, utilizan Drupal o Zend Framework para prácticamente todos los proyectos (Drupal es en su mayoría).A muchas personas orientadas a ZF no les gusta Drupal ya que su estructura está tan lejos de las cosas ZF orientadas a objetos, y Drupal es "solo un CMS". Según veo, Drupal es más un Framework que "solo" un CMS, y la mejor parte es que es increíblemente flexible: todo es posible.

Y sí, de hecho, hay un módulo para todo. Para ser más específicos:

Por otra parte, en base a mi limitada experiencia con Drupal, dudo construir rápidamente "funciones" personalizadas y permitir a los usuarios crear "grupos" y administrar sus propios roles dentro de esos grupos es algo que Drupal puede lograr fácilmente.

Solo puedo adivinar lo que quiere decir con las funciones personalizadas rápidas, pero también es fácil expandir Drupal con sus propios módulos. La mayoría de las características están disponibles como módulos (gratuitos, aportados por la comunidad) y se pueden crear fácilmente muchas funciones de aspecto avanzado, por ejemplo, con los módulos "vistas" y "cck". http://drupal.org/project/cck http://drupal.org/project/views

Creación de grupos: "organic_groups" (http://drupal.org/project/og)
"og_user_roles" (http://drupal.org/project/og_user_roles)

Estos módulos juntos son lo que necesita para crear grupos que tienen roles de grupo spefic (y los roles que tienen específica derechos). Probablemente haya otras maneras de usar "og_user_roles", pero lo estoy anunciando porque hice algunos parches hace unos años. El problema suele ser demasiadas opciones.

Si desea ampliar las opciones específicas de grupo, puede codificar su propio módulo, pero lo más probable es que no lo necesite porque ya tiene un módulo. Por ejemplo, hay por lo menos 120 módulos que integran alguna manera con el "organic_groups" -module: http://drupal.org/taxonomy/term/90?page=19

Para simplificar, es capaz de Drupal verdaderas aplicaciones Web; donde la aplicación es un> servicio y proporciona resultados personalizados para cada usuario? ¿Puede proporcionar una interfaz tipo tablero de instrumentos para que los usuarios cambien sus configuraciones o preferencias? ¿Puede agregar datos de usuarios particulares para proporcionar mejores resultados/información a otros?

En resumen, sí. Hay muchas maneras de lograr algo que describiste. Pero probablemente involucrarían al menos el excelente módulo de "vistas". Considero que las vistas son una especie de capa SQL de abstracción y UI para cualquier persona. Y hay más de 300 módulos que de alguna manera se integran con Vistas ... (http://drupal.org/taxonomy/term/89?page=55)

Esto suena a que Drupal se trata de los módulos ... y sé que a algunos de mis colegas incluso les disgusta eso, porque nunca se llega a código divertido porque ya está hecho. Al menos puedes mirar el código del módulo y aprender de eso. O reírse de eso, también hay muchos módulos mal programados.

Cuando llegue a los módulos de codificación, es probable que necesite mucho tiempo para acostumbrarse a la API de Drupal, la API de formularios, los ganchos del módulo, el sistema de anulación del tema y las infinitas opciones de los módulos contrib. Pero vale la pena el problema.

Encuentro este sitio muy útil para encontrar un módulo para alguna necesidad específica. El sitio muestra la misma información de módulo que Drupal.org, sino también comentarios de los usuarios/calificaciones, para encontrar la mejor opción: http://drupalmodules.com/

Si no está claro, mi respuesta sería ir con Drupal :)

PS: D7 debe ser muy pronto. Algunos podrían esperarlo en lugar de comenzar con D6. Durante D5 las personas esperarían mucho antes de actualizar a D6 debido a la falta de módulos. Creo que para D7 los módulos más importantes estarán disponibles para D7 muy rápido. Algunas investigaciones en el momento (04.12.2010):

Alrededor de 190 módulos prometen tener una versión de Drupal 7 el día D7 se libera: http://drupal.org/project/modules?solrsort=sort_title%20asc&text=d7cx&display=table

Cerca de 130 módulos ya están disponibles para D7 (la mayoría están incluidos en el enlace anterior): http://drupal.org/project/modules?filters=drupal_core:103&solrsort=sort_title%20asc&text=d7cx&display=table

EDIT: Como novato que sólo estoy autorizado para publicar un enlace, así, elimina http: // a partir de los enlaces Drupal.org

+0

Tengo que admitir que el enlace sobre "grupos orgánicos" es convincente. Pero también me pregunto si hay un impacto severo con el módulo Drupal que se está desactualizando cuando las actualizaciones de núcleo de Drupal dejan las correcciones "personalizadas" incompatibles con las actualizaciones. – Andres

+0

La aplicación de parches puede causar problemas, sí, y la mayoría de los proyectos de Drupal con muchas funciones suelen necesitar un parche o dos. Sin embargo, lo más probable es que nunca tenga que parchar los módulos principales (que vienen con la instalación D6.x). Mientras usaba la versión anterior de Drupal 5, a veces incluso tuve que parchear el núcleo (un gran no-no) para resolver algunos problemas. Pero D6 es más evolucionado y extensible, por lo que no he tenido que hackear ningún módulo central después de D5, en más de una docena de proyectos D6. Las actualizaciones menores de la versión principal, como 6.15 -> 6.16 son sencillas: solo son correcciones de errores/seguridad y los módulos aún funcionan. Sin embargo ... [límite de texto] – Ilmari

+0

... Sin embargo, las versiones principales como 5-> 6 no son compatibles: todos los módulos necesitan una versión de actualización y, a veces, no hay ninguno (o tiene que cambiar a una alternativa). Los módulos parcheados deberán volver a ser parcheados. La actualización solía ser un fastidio, por ejemplo, una actualización de D4 a D5 me llevó meses de planificación (un sitio popular que estaba en vivo, y yo era Drupal-noob en ese entonces ... excusas). Pero eso fue porque tenía muchos módulos y parches personalizados. Y Drupal no era tan popular en aquel entonces (menos módulos). La actualización D5-> D6 es muy fácil en comparación con eso, y D6-> D7 debería ser incluso más fácil. [límite de texto] – Ilmari

1

No hay cosa imposible de lograr. La pregunta es si quieres trabajar con el código de otra persona y tratar de averiguar cómo cavar dentro y extenderlo para que se ajuste a tus necesidades o si quieres usar un marco ligero como Kohana o quizás CodeIgniter (mi favorito) y conducir su propio automóvil, aunque es posible que necesite "inventar" algunas de las ruedas.

Investigue qué plugins hay en su marco de referencia, ya que hay muchos frameworks que ofrecen muy buenas soluciones que pueden proporcionarle estas ruedas.

En mi opinión personal, el tiempo que pasarás estudiando Drupal equivaldrá al tiempo necesario para que crees tu funcionalidad básica de CMS, pero los nervios que usarás tratando con cosas fuera de tu control como el código Drupal cambiar las escalas a favor de Framework.

+0

Pero una vez que haya aprendido cómo escribir/modificar módulos y trabajar con Core Drupal, podrá hacer cosas similares mucho más rápidamente en el futuro. En mi humilde opinión para alguien que planea hacer este tipo de cosas como algo más que una sola vez, gana Drupal. – intuited

+0

@intuited No estoy de acuerdo, ya que una vez que aprendes cómo hacer las cosas en un Framework y tienes tus clases base, tienes una base para ir e ir lo que quieras. Si alguien necesita flexibilidad, debe tener la mayor cantidad de código posible en su aplicación, de lo contrario, es una especie de pesadilla. –

+0

Depende de lo que harás ... si está en el estadio de Drupal (y muchas cosas lo hacen), terminará siendo más rápido en Drupal, especialmente una vez que superas la curva de aprendizaje inicial de cómo extender Drupal más allá de sus capacidades básicas. Drupal básicamente * es * un marco, pero de nivel superior y más específico que la mayoría. – intuited

1

Lo divertido de Drupal es lo que la comunidad llama en broma regla # 35: hay un módulo para ello. A menos que quiera hacer algo realmente complicado, a menudo encontrará que la funcionalidad ya se ha implementado y solo necesita configurarlo.

+1

Incluso hay un módulo drupal que agrega a cada nodo una imagen de alguien instalando ese módulo en su ropa interior. – intuited

0

Como desarrollador web novato, puedo decirle que necesita analizar los casos de uso para su aplicación web muy estrictamente. Si puede cubrir al menos el 75% de los casos de uso que prevé, ese es un buen comienzo.

Una vez hecho esto, necesita saber si Drupal/Joomla/CMS (x) le dará todo eso y con otro posible aumento de característica desconocido del 5-10%. Si es así, quizás sea mejor que entres con Drupal, etc.

De lo contrario, creo que CodeIgniter o Symfony son excelentes frameworks PHP para saltar. Ambos ofrecen sólidos tutoriales, videos y demás, y una comunidad útil. Kohana, en el que estoy trabajando, creo que deberías adentrarte si realmente entiendes PHP y sus defectos, y te darás cuenta de que la velocidad será un factor crítico. Esas son las dos grandes fortalezas que KO3 trae a la mesa y realmente debería necesitarlas para usarlas.

Espero que esto ayude.

5

trabajé tanto con Drupal y Kohana.

En mi opinión, realmente depende de lo que quieras hacer. Si va a hacer una aplicación web que necesita crecer mucho y debe ser flexible para su crecimiento, le recomiendo usar Kohana. Kohana está hecho para mantener su base de código limpia y compatible en SECO (No repetir). Si bien es probable que no tenga tantos módulos como Drupal, tiene algunos módulos Auth y ACL.

Si quiere terminar rápido y no le importa hacer su aplicación a otros módulos, Drupal hará su trabajo rápidamente. Pero tenga en cuenta que cuando vaya a extenderlo, probablemente se encuentre con problemas que provienen de módulos que no conoce. También requiere un poco de flexibilidad de usted.

En última instancia, es su elección. Pero recomiendo usar un marco MVC si vas a escribirlo desde cero.

+1

¡Gracias! ¿Has trabajado con KO3? Estoy en una encrucijada entre KO2 y KO3. ¿Alguna idea sobre CodeIgniter 2.0? – Andres

+0

"Pero tenga en cuenta que cuando vaya a extenderse, lo más probable es que tenga problemas que provienen de módulos que no conoce". Estoy totalmente de acuerdo. Sin embargo, puede disminuir los problemas con los módulos simplemente aprendiendo a través de sus fuentes. Además, elija los mejores módulos, generalmente hay muchas alternativas. Normalmente voy con lo que suena más robusto y tiene la mayoría de los usuarios. Al final, conocer las diversas API: s de los principales módulos, y cómo se integran juntas, necesita una investigación. Si vas con Drupal, debes consultar a alguien con algunos años de experiencia para evitar que lo aprendas de la peor manera. – Ilmari

+0

@Andres: Solo trabajé con Kohana 2.x. Kohana 2.x aplica el patrón MVC. Este patrón debería ser lo suficientemente bueno para la mayoría de los proyectos. También otro profesional de 2.x de que hay mejor documentación disponible. Kohana 3.x aplica el patrón HMVC, que puede hacer que su aplicación sea mucho más modular y fácil de administrar. También realmente apoyo el método DRY (google). Eche un vistazo aquí para hacer su elección: http://kerkness.ca/wiki/doku.php?id=what_version_of_kohana_should_i_use – RJD22

1

Soy nuevo en Drupal (7.12) & Kohana (3.2.0) ... Mi experiencia hasta el momento es que la documentación de Kohana CHUPA (o al menos, lo que he visto de ella). Y si su sitio web y/o foro está escrito en Kohana, también apesta (slooooow, con campos superpuestos, etc.). Mientras que con Drupal, ha sido limpio y, hasta ahora, muy eficiente (lo mejor que puedo decir hasta ahora).

Supongo que me pregunto si los comentarios hasta ahora se centraron en Drupal 6.x y no han tenido en cuenta las innovaciones más recientes en Drupal. ¿Alguna idea/comentario? Gracias.

Cuestiones relacionadas