Ahora que me he familiarizado bastante con web2py, me gustaría darle una oportunidad a Django.Django para desarrolladores de web2py
¿Cuáles son las principales diferencias?
¿Cuál sería la forma más eficiente de empezar a tomar en cuenta el conocimiento de web2py? (Se debe ayudar a tener algún conocimiento framework de aplicaciones Python, no?)
EDITAR
Además, si usted ha utilizado tanto, puede ofrecer una opinión sobre cuál prefiere y por qué?
web2py está muy inspirado en Django y si conoce uno, es fácil aprender el otro. Agregamos algunas funciones que no encontramos en Django, como migraciones de bases de datos (modificar tablas automáticamente), tickets de errores, un IDE basado en web, una capa de abstracción de base de datos que funciona en Google App Engine, un mecanismo de control de acceso basado en roles con inicio de sesión conectable módulos.
Una de las diferencias fundamentales de diseño es que las aplicaciones de Django se implementan como módulos y, por lo tanto, es necesario reiniciar el servidor cuando se editan. En lugar de web2py, los Modelos/Vistas/Controladores no son módulos, son ejecutados (no importados) por los marcos y, por lo tanto, no es necesario reiniciar el servidor cuando cambian.
Otra diferencia es que Django usa un ORM, web2py usa un DAL. El DAL es ligeramente más bajo que el Django ORM y esto lo hace más cercano a la sintaxis SQL (por ejemplo, permite uniones izquierdas, agregados arbitrarios, selecciones anidadas y combinaciones de los mismos) mientras permanece portátil (admitimos 10 bases de datos diferentes). El DAL también facilita la meta-programación dinámica de modelos (como crear modelos en tiempo de ejecución basados en especificaciones almacenadas en un archivo como un archivo XML o CSV).
Django ha existido por más tiempo para que pueda encontrar más personas capacitadas con él y más aplicaciones implementadas.
No necesita reiniciar su servidor Django cuando cambie su código (http://www.djangoproject.com/weblog/2005/jul/20/autoreload/). Parece que esto ha sido así desde mediados de 2005. – MikeWyatt
No, si usa el servidor Django pero, si no me equivoco, debe reiniciar Apache si ejecuta Django con Apache + mod_wsgi o mod_python. En web2py no necesita reiniciar el servidor web, incluso si no usa el incorporado. – mdipierro
No necesita reiniciar Apache, puede volver a cargar mod_wsgi o fcgi. – rapadura
Definitivamente ayuda tener conocimiento de algún framework de Python.
forma más eficaz para empezar sería, para comparar los diferentes sectores de los dos, es decir, Modelo, Vista, Controlador, Url Despacho, plantillas, formularios, etc.
Here es una gran comparación de unos marcos . Estoy seguro de que ayudará.
El enlace ya no funciona. ¿Podría encontrar el recurso al que se refería y actualizar el enlace? Que sería genial. Gracias. – Tadeck
Fui programador de Django antes de establecerme en web2py. Me encontré más eficiente con web2py, posiblemente debido a los valores predeterminados razonables (importaciones implícitas, vistas predeterminadas, etc.) y el gran soporte en el forum.
Hice una pequeña aplicación web interna completamente en Django, y luego completamente en web2py. Es la única forma de comprender realmente las diferencias y su impacto en la experiencia del desarrollador.
Prefiero web2py porque hay más comodidades incorporadas en el entorno que las ofrecidas por Django, pero web2py es mucho más nuevo que Django, y la retrospectiva siempre hace que sea más fácil mejorar las implementaciones nuevas. Debido a que web2py garantiza la compatibilidad con versiones anteriores, es completamente plausible que alguna herramienta nueva haga obsoleto web2py en unos años a partir de ahora. Esa es la forma normal de las cosas.
De todos modos, son muy cercanos entre sí, mucho más que cualquier otro marco web en comparación con cualquiera de los dos.Desde el punto de vista de un marco web basado en Java, por ejemplo, pueden parecer casi idénticos entre sí.
Buen punto, +1. Pero las diferencias reales son claramente visibles cuando intenta hacer algo más avanzado, más personalizado en ambos marcos. Creo que entonces puede ver que Django es superior a Web2Py, ya que tiene claro lo que sucede en su aplicación, también todas las características de Web2Py son, o podrían implementarse fácilmente en Django. Existen algunas diferencias, como la falta de IDE basado en la web en Django (quizás haya un módulo para ello), pero al menos Django es interpretado correctamente por varios IDEs, y es altamente personalizable y estable. – Tadeck
@Tadeck: con respecto a mi experiencia con web2py, envié sitios con éxito, tenía muy claro lo que estaba sucediendo en mis aplicaciones, no tenía que volver a implementar características, usaba web2py en un IDE muy bien (PyDev Eclipse), contribuía el código hasta el tronco , la estabilidad perfecta experimentada (¡web2py garantiza la compatibilidad con versiones anteriores!), contribuyó al libro web2py y, en general, disfrutó la interacción con una comunidad amigable. Estoy seguro de que todo esto es posible con Django también. Sólo digo'. –
Django = edad Web2py = new
Cualquier cosa que hace Django, web2py hace mejor. Esto se debe a web2py se hizo mucho después de Django y ha aprendido de los errores de Django, a pesar de que hace que todos los nuevos errores;)
principal diferencia, y lo que me mantiene en web2py:
Django tiene documentación increíble ... web2py es tan intuitivo que no necesita tanto ... ¡SIN EMBARGO! He encontrado que la documentación de Django es aplicable a web2py, en su mayor parte. Si pasas un día leyendo el libro de Django (capítulos 1-7), obtendrás la idea de cómo es eso cierto. Entonces, en cierto modo, decir que Django está mejor documentado es estúpido. Además, tenga en cuenta que cualquier marco que rodee hablar sobre los volúmenes de documentación para él es algo bueno ... preocúpese ... la documentación es buena, no necesita ninguna para comenzar = mejor. La documentación existente de Web2py supera con creces las necesidades del 90% de los usuarios. El 10% restante tiene que ir a echar un vistazo al código de la biblioteca de marcos (no tanto como Django, y no tan atemorizante). Además, si llega al punto en que pasa más del 30% del tiempo revisando el código de la biblioteca, es hora de alejarse de los marcos y avanzar hacia las colecciones de bibliotecas (como las torres de alta tensión). En ese momento, significa que no está haciendo nada para lo cual los marcos web fueron diseñados para manejar ...
SQLForm en Django es TextModel. Una vez que crea un formulario usando TextModel (= SQLForm). ¡Buena suerte tratando de cambiar el CSS de un solo campo de entrada! En web2py simplemente haces form.element(), no existe tal cosa en Django. Tienes que pasar por "widget()", pero para ir al widget, primero tienes que pasar por el tipo de campo de entrada, etc ...
Además, la migración manual de la base ... ¿cambiar el esquema? Lo siento ... tiene que descargar e instalar una aplicación de migración por separado (Sur), o tiene que hacerlo manualmente en su consola de DB.
Por último, no está fuera de la caja de soporte para múltiples DBs ... creo aros ...
En otras palabras ... con Django ... espero que les guste saltar y aros.
Si usted quiere tomar realmente un salto hacia adelante desde web2py, tratar Pilones ... en serio ...
grande inconveniente de web2py es su edad y base de código más pequeño ... esto no es razonable, sin embargo, teniendo en cuenta Django es como el primer framework web de Python para implementar ideas RAD de estilo RAILS y tiene el doble de edad que web2py. Web2py todavía está en su etapa inicial de adopción ... Django está en la parte más allá de la masa crítica que viene a declinar ... web2py debería alcanzar masa crítica en cualquier momento en los próximos 2 años, predigo.
CONCLUSIÓN pasar un día, leer el libro de Django (CH 1-7), y leer el libro Pilones (Parte 1), y luego pensar en por qué está utilizando un marco para empezar. Para mí fue para hacer todo lo más rápido posible, y sin buscar documentación el 30% del tiempo.
Web2py cumple con las necesidades anteriores para mí.
Creo que primero debería asegurarse de conocer Python.Web2py no funciona ya que el código Python común funcionaría: el espacio de nombres global es un desastre, muchas cosas se importan implícitamente, es difícil llamar al código interno de web2py como _pythonic_ y a veces se pega a la pared (por ejemplo, si defines la base de datos 'db' en 'db.py', como lo sugiere el tutorial, la variable global' db' será accesible en 'models.py' y por ej.' people.py', pero no en 'contacts.py'). Solo aprenda a volver a diseñar su código correctamente, no de la forma en que funciona web2py, sino de la forma en que funciona el código de Django. – Tadeck