2009-06-17 6 views

Respuesta

3

No he tenido ninguna aplicación CFMX 6.1 para cambiar, pero Railo es definitivamente mi motor CFML de elección.

En lo que respecta a la compatibilidad, es muy poco probable que se produzcan problemas significativos al migrar desde CFMX 6.1, y puede probarlo fácilmente con la versión Express, ¡no es necesario realizar ninguna instalación!

Railo puede ser más estricto sobre ciertos aspectos de CFML, por lo que podría obtener algunos errores si explota errores/debilidades con CF, pero nada realmente de qué preocuparse.

Y, si te quedas atascado en algo, el Railo mailing list está activo con un montón de personas amigables que pueden ayudarte a volver a empezar.

3

Hace aproximadamente un año que hicimos el cambio y si solo nos referimos al lado del código, entonces el cambio de cf6 a cf8 no debería requerir ningún cambio siempre que la configuración sea la misma. Un cambio es la forma en que CF maneja las colecciones de verity, por lo que si utiliza cfsearch, entonces podría ser algo que considere. Hay una serie de mejoras de cf6 que debe considerar implementar. Los pocos que hemos encontrado especialmente útiles son cfdocument, cfimage, cfpdf y cffeed. Aquí hay un buen enlace con otros puntos clave ... http://www.adobe.com/products/coldfusion/upgrade/

+0

suena bien, sólo nuestra dev alto utilizado directamente cfml, nada oscuro – mrt181

+0

Recomendaría, como Jayson señaló, que configurar una versión de desarrollador local de cf8 y probar cosas podría ser muy útil. – Jason

1

No conozco ninguna etiqueta o funciones despreciadas de CF6.1 a CF8. CF8 se ha optimizado para el rendimiento, por lo que lo más probable es que vea una mejora en su aplicación en función de lo que se utilizó.

Actualicé satisfactoriamente una aplicación de gran tamaño de CF4.5 a CF8 sin problemas. Si la aplicación consiste en un uso bastante directo de las etiquetas y funciones de ColdFusion, no debería tener muchos problemas.

Sin embargo, dado que la versión del desarrollador es de uso gratuito, realmente debe configurar un entorno de prueba y determinar la respuesta a esta pregunta usted mismo al probar su aplicación. Todos los orígenes de datos, etiquetas personalizadas, etc. tendrán que migrarse y probarse. Si alguna aplicación de CF6.1 usó alguna de las API de nivel inferior disponibles en algunos aspectos, es posible que deba probarla a fondo para asegurarse de que la implementación subyacente de ColdFusion no haya cambiado y corregir lo que sea necesario.

En cuanto a Railo3.1, puede haber algunas etiquetas o funciones aún no implementadas. Nuevamente deberá configurar un entorno de prueba y determinarlo usted mismo. En algún lugar del sitio de Railo debería haber una lista de compatibilidades entre las versiones de diferencia de CF y Railo.

+0

No hay mucho de CFMX6.1 que Railo 3.1 no haya implementado. Puede agarrar la edición Express y probarla. –

4

Hemos encontrado que cuando nos pasaron a CF 8:

vuelve Carraige son despojados de mensajes de correo electrónico de texto sin formato. Descubrimos que teníamos que ser explícitos sobre los caracteres de alimentación de línea creando una var como <cfset CRLF = "#Chr(13)##Chr(10)#"> e insertándola en el correo electrónico de texto sin formato donde necesitábamos el avance de línea. Finalmente fuimos a los correos electrónicos HTML.

Los archivos jar de terceros causaron problemas debido al orden de carga de los archivos jar. Ciertos archivos jar deben aparecer primero en el classpath de Java como se define en cfroot/runtime/bin/jvm.config. Esta fue una solución desordenada y hemos suspendido el uso de ese contenedor.

También asegúrese de parchear inmediatamente en 8.0.1. Tuvimos una pesadilla de rendimiento debido al problema this.

¡La mejor de las suertes!

3

Si está actualizando de CFMX 6.1 a Railo 3.1, casi no debería haber problemas. Hay algunas cosas que no son compatibles (como las etiquetas CFREPORT o C++ CFX). Además de eso, debería ser muy fácil migrar el código CFMX 6.1 existente a Railo. Por defecto Railo está configurado para ser lo más compatible posible con CFMX.

Hay algunas otras cosas que usted puede mirar hacia fuera para:

  • Si crea una estructura como esta en la FQ: < cfset un [ "image.x"]> usted será capaz de llamar a esa variable usando el "." notación, aunque es engañosa. Así que en la FQ que podría hacer < cfoutput> # # a.image.x </cfoutput> mientras que en Railo que tendría que escribir: < cfoutput> #a [ ""] image.x # </cfoutput>
  • funciones dentro la creación de variables en el ámbito local que tengan el nombre de ámbitos funcionará en CFMX pero no en Railo. Entonces esto: < cfset var url = "whatever"> funcionará en CF pero no en Railo.
  • En Railo no puede usar el alcance de la aplicación o el ámbito de sesión antes de inicializarlo con cfapplication. Bueno, en CF tampoco podrías, pero allí CF creará una variable local en el ámbito de variables llamada "aplicación" o "sesión". Esto a veces conduce a la confusión.

Además de estas cosas, debería funcionar sin problemas. Si tiene algún problema, por supuesto, sólo en contacto con nuestro grupo Railo Google o directamente con nosotros en www.getrailo.com

Gert Franz


Railo Profesional Open Source

Cuestiones relacionadas