Ahora que playframework tiene una nueva versión 2 que es completamente diferente de la versión 1; ¿Qué pasará con este último? ¿Deberían todos los proyectos escritos en el juego 1 migrar a la versión 2 absolutamente? Me pregunto si uno podría confiar en que el juego 1 no se volverá obsoleto ni apoyado en el futuro cercano o mediano.¿la versión 1 de playframework quedará obsoleta?
Respuesta
Una de las afirmaciones clave que ha recibido del equipo de desarrollo principal es que ellos mismos tienen muchas aplicaciones escritas en Play 1.x, y por lo tanto, seguirán admitiendo Play 1.x. El juego ha existido desde hace bastante tiempo, e incluso antes de que fuera público, Zenexity lo utilizaba como el marco para construir las aplicaciones web de sus clientes.
No buscan volver atrás y rediseñar las aplicaciones web de Play 1.x, y de muchas maneras, el soporte y la comunidad alrededor de 1.x son más fuertes que 2. Si está buscando comenzar a usar más funciones en tiempo real, entonces tal vez debería pasar a Play 2, pero si está contento con lo que ofrece Play 1 ... ¿por qué moverse? Nicolas Leroux y algunos de los otros desarrolladores principales se han comprometido a mantener el proyecto Play 1, y desde que se lanzó Play 2, se ha lanzado 1.2.5 y 1.3 está en camino.
Dicho esto, si decide migrar, le recomendaría encarecidamente utilizar el motor de plantillas Groovy para 2.x, ya que puede facilitar el proceso de migración.
Personalmente, prefiero 1.x a 2.x, pero eso es pura cuestión de gusto. He invertido mucho tiempo en 1.x, y lo sé bien, y las características 2.x no son suficientes para alejarme de la facilidad y belleza de Play 1.
en un futuro próximo, podría ser mejor seguir con el juego 1. + - dado que hay una serie de módulos que funcionan con 1. + - puede tomar más tiempo para que 2. + se estabilice y con soporte de módulos aún mayor (por lo tanto, migrar tu juego 1. + project a 2. + en este momento podría no ser lo mejor que puedes hacer). Usar play 2. + después de algunas versiones menores podría tener más sentido.
gracias. esto es tranquilizador;) – othman
No, no hay necesidad de reescribir el código existente, al menos para las aplicaciones estables existentes. El objetivo principal para cada aplicación debe ser para ser independiente de la versión inicial del software blando que se creó con. Play 1.x
estará bajo el mantenimiento del equipo por algún tiempo, pero como se dijo muchas veces, no se agregarán nuevas características, ya que la dirección principal actual de desarrollo es 2.x +
Por supuesto, si su aplicación está en la inicial fase de desarrollo y/o usted supone que muchos cambios en el futuro, tal vez 'saltar' a la versión más nueva será una mejor idea en este momento. Más tarde necesitarás migrar muchas más cosas.
Por otro lado, definitivamente recomendaría comenzar un nuevo proyecto con la versión 2.x, permanecer en el nivel 1.x hará que se despierte algún día con la aplicación basada en una versión no compatible.
Acerca de la disponibilidad de módulos: tenga en cuenta que los módulos son creados por la comunidad. No condicionaré mi elección a la disponibilidad de módulos entre las versiones 1 y 2 de Play, ya que solo se trata de fragmentos de código, y muchos de ellos pueden escribirse nuevamente en poco tiempo. Finalmente, como Play es el marco de desarrollo, los módulos son simplemente buenos accesos directos, no el absolutely required base
para cualquier aplicación nueva.
ok. Habrá necesidad de mantener el código después de un tiempo de todos modos. y en esta fase migrar a 2.x tendrá más sentido. Gracias – othman
- 1. Tratando con la versión obsoleta de android.text.ClipboardManager
- 2. alternativa a la versión obsoleta javax.servlet.http.HttpUtils.parseQueryString?
- 3. ¿Cómo validar la carga de imágenes en PlayFramework 1?
- 4. Cómo actualizar Boost cuando Yum tiene la versión obsoleta
- 5. cómo aumentar la Asamblea Versión Número 1 por 1
- 6. la paginación en playframework
- 7. La clase XmlValidatingReader está obsoleta
- 8. XSLT versión 1 Codificación URL
- 9. Playframework run y Global.onStart
- 10. Uso de memoria del Playframework
- 11. '' System.Configuration.ConfigurationSettings.AppSettings es obsoleta
- 12. CloudBees + PlayFramework + Eclipse
- 13. ¿Cómo anular la advertencia obsoleta en Xcode?
- 14. ¿La etiqueta <noscript> está obsoleta?
- 15. Moq cómo reemplazar la expresión obsoleta
- 16. AJAX con Struts 1.x Versión
- 17. Playframework y Django
- 18. Playframework 2 SQLite
- 19. es playframework verdaderamente asincrónico?
- 20. Wicket o Playframework?
- 21. django o playframework
- 22. playframework: i18n + Scala
- 23. ¿Qué plataforma en la nube admite playframework?
- 24. sesión de objeto en playframework
- 25. Descripción del libro obsoleta de la declaración Try-Except-Finally
- 26. Playframework IllegalStateException después de la validación de formulario
- 27. Envío de correos electrónicos en Playframework 2.0
- 28. constexpr y advertencia de conversión obsoleta
- 29. Marcar como clase obsoleta de tercero
- 30. Carga de archivos múltiples en playframework
gracias por la buena respuesta. – othman
Revertimos del juego 2.x al 1.2.5 porque 2.x era demasiado lento ahora mismo. nos encanta la naturaleza de desarrollo en tiempo real del juego. –
+1 Me gusta el juego v1, y pasé mucho tiempo aprendiendo el juego 2 ... y tengo mucho problema. Me gusta Scala, pero no puedo decir que me gusta play2 (porque es bajo, todavía tiene problemas con los ide superiores). Quizás en 1 año verifique nuevamente v2. – ses