Funcionalidades obsoletas o eliminadas en la gama v15

(Desde 4D v14 R4)

El lenguaje XSLT transforma los datos XML a cualquier formato (XML, HTML, o cualquier otro tipo). Los principales navegadores web, así como también el software 4D han implementado la especificación XSLT 1.0.

Actualmente, la tendencia XSLT está en declive porque los desarrolladores consideran que es difícil de usar y de depurar.  Siguiendo esta tendencia, así como también los comentarios de los desarrolladores, hemos decidido que la funcionalidad de transformación XSL no será desarrollada para versiones 4D de 64 bits.

Nota: para visualizar las tendencias de búsqueda XSLT en Google: http://www.google.com/trends/explore#q=xslt      

Sin embargo, para soportar a nuestros clientes que siguen utilizando XSLT en 4D, elegimos confiar en la librería XSL PHP, que ofrece una completa API que le permite realizar todas las operaciones necesarias para sus transformaciones XSL. Esta librería es una herramienta eficaz que puede sustituir fácilmente los comandos _o_XSLT APPLY TRANSFORMATION, _o_XSLT SET PARAMETER y _o_XSLT GET ERROR  después de su eliminación. 4D ha producido un documento específico para ayudarle a utilizar PHP XSL como un reemplazo para los comandos XSLT de 4D:  Descarga XSLT con el documento técnico PHP (PDF).

También le sugerimos que considere el uso de etiquetas 4D cuando se trata de la generación dinámica de páginas HTML, ya que en la mayoría de los casos es más fácil si maneja código HTML como texto sin formato (ver también el comando PROCESS 4D TAGS).

Por compatibilidad, las transformaciones XSL se siguen soportando en 4D, pero su uso no se recomienda. El soporte del procesamiento XSLT se eliminará en futuras versiones de 4D.

Nota 4D Server 64 bits OS X: XSLT no está disponible con 4D Server 64 bits para OS X. Por lo tanto, al llamar uno de estos comandos desde esta aplicación generará un error 33 "Comando o función no implementado".

El formato PICT no se soportará en los próximos grandes lanzamientos de 4D y ya no debe utilizarlo en 4D v14 y posteriores. La función AP Is Picture Deprecated, ofrecida a través de 4D Pack a partir de la versión 13.2, tiene la intención de ayudarle a migrar sus aplicaciones.

Nota: el formato "PICT" Mac ya ha sido desaprobado por Apple desde varias versiones anteriores de Mac OS (consulte la descripción del formato PICT en Wikipedia).

El formato 'PICT' es un formato muy antiguo Mac. Antes de la versión 11, 4D almacenaba todas las imágenes en este formato, incluso en Windows. El formato PICT es obsoleto desde que QuickDraw se declaró obsoleto en 2005.

Hay algo importante de entender sobre PICT. Puede almacenar ("encapsular") 2 tipos principales de información:

• el dibujos en sí (ya sea mapa de bits o vectorial), o
• un formato más moderno (JPEG, por ejemplo) almacenado en un PICT utilizando QuickTime. (Por lo general, el desarrollador estaba llamando _o_QT COMPRESS PICTURE con la constante QT Photo compressor).

Esto significa que incluso antes cuando todas las imágenes almacenadas en los archivos de datos eran PICT, esos PICT podían, de hecho, contener los archivos JPEG (u otros formatos). Es importante que nuestros clientes dejen de usar PICT, no sólo porque está obsoleto, sino también porque 4D necesita Altura (+ QuickTime si se utilizó _o_QT COMPRESS PICTURE) para leer PICT en Windows. Esto no es eficiente, y requiere que QuickTime este instalado.

Al migrar datos de versiones anteriores a la v11, los desarrolladores deben aplicar el comando CONVERT PICTURE para cada campo imagen de los datos. Al convertir los datos de las versiones más recientes, se recomienda utilizar la función para encontrar imágenes que necesitan ser convertidas.

El soporte para los codecs de imágenes relacionados con QuickTime ya es obsoleto.

Por defecto, el uso de QuickTime está deshabilitado desde 4D v14. Sin embargo, por razones de compatibilidad, se puede habilitar su uso utilizando la nueva opción QuickTime support con los comandos SET DATABASE PARAMETER, Get database parameter (excepto en versiones 64 bits de 4D, donde QuickTime no se soporta). 

Durante varios años, el manejo de imágenes bajo la versión Windows de QuickTime no ha evolucionado (sólo la parte de vídeo está evolucionando). Tenemos la intención de eliminar el soporte para estas APIs específicas en la próxima versión.

4D para Windows de forma nativa soporta todos los principales formatos (JPEG, PNG, GIF, TIFF, etc.), y también soporta WIC (Windows Imaging Component). Si, en sus datos, usted tiene algunas imágenes guardadas en Windows en un formato específico conocido sólo por QuickTime, puede convertirlos (CONVERT PICTURE).

También le recordamos que el soporte para los formatos de imagen de QuickTime se ha eliminado de la versión de 64 bits de 4D Server para Windows como de 4D v12.

En las versiones anteriores de 4D, el servidor web recopiaba automáticamente el valor de las variables enviadas a través de un formulario web o una URL en las variables 4D cuando tenían el mismo nombre.

Por razones de optimización y control, este principio no se mantiene a partir de 4D v14: el valor de las variables Web ya no se asigna automáticamente a las variables 4D. Para recuperar las variables enviadas utilizando un POST o un GET, debe utilizar el comando WEB GET VARIABLES exclusivamente.  Para recuperar las imágenes enviadas, debe utilizar los comandos WEB GET BODY PART/WEB Get body part count.

Nota: la asignación dinámica también está desactivada por defecto en las bases de datos 4D creadas a partir de la versión 13.4.

Sin embargo, por compatibilidad, este mecanismo se mantiene por defecto en las bases de datos creadas con una versión de 4D anterior a la 13.4. En este caso, se puede desactivar el uso de la opción de compatibilidad de asignación de variable automática en la página Compatibilidad de las Propiedades de la base.

Dado que este mecanismo es obsoleto, se recomienda desmarcar esta opción en sus bases de datos convertidas (y adaptar su código si es necesario) con el fin de facilitar futuras evoluciones.

El uso de números de identificación QuickDraw para designar fuentes es obsoleto y no debe ser utilizarse más. Los comandos _o_Font number y _o_Font name se conservan en 4D v15 y superiores por compatibilidad, pero se eliminarán en versiones posteriores. El comando OBJECT SET FONT ahora sólo acepta nombres de fuentes.

La barra de herramientas automática que estaba disponible al cambiar al modo Aplicación se ha eliminado y la opción "Barra de herramientas de visualización" desaparece de la página Interfaz de las Propiedades de la base.

A partir de 4D v14 R5, la creación de barras de herramientas personalizadas es facilitada por la nueva constante Toolbar form window, utilizada con el comando Open form window. También puede utilizar los comandos SHOW TOOL BAR, HIDE TOOL BAR y Tool bar height en este contexto.

El botón de la barra de herramientas de Mac OS ha quedado en desuso por Apple desde OS X 10.6. Las constantes utilizadas para soportar esta funcionalidad tienen el prefijo "_O_" y ya no tienen ningún efecto:

• _O_Has toolbar button Mac en los temas "Open Form Window" y "Open Window".
• _O_On Mac Toolbar Button en el tema "Form Events".

Altura Mac2Win se utilizó para llevar 4D a Windows. Es un conjunto de APIs que ayudaron a llevar código Mac OS (pre OS X) a Windows, mediante la traducción de las APIs: filesystem, QuickDraw, Resources, PICT, etc. Fue muy útil y ayudó mucho (los desarrolladores Mac plug-in, por ejemplo, podían mover sus plug-ins a Windows más fácilmente), pero traduce APIs Mac OS antiguas ("obsoleto") y no utiliza la API de Windows nativo moderno: 4D debe eliminar Mac2Win de su código lo más posible. Esto es un trabajo largo y duro y en cada versión de 4D, algunas dependencias se eliminan (y sustituyen por APIs modernas).

En este momento, 4D todavía depende en parte, sobre todo para poder manejar la compatibilidad de antiguas bases de datos: Recursos, PICT, parte de la gestión de los eventos de usuario, soporte para los plug-ins de terceros que están integrados utilizando Altura, etc.

Mediante la eliminación de recursos en el archivo .RSR para separar los archivos en la carpeta "Recursos" y mediante la conversión (CONVERT PICTURE) a no-PICT, el desarrollador 4D estará listo una vez 4D ha eliminado Altura. Pero las primeras personas preocupadas por este gran paso son los desarrolladores del plug-in. Ellos deben dejar de usar Altura tan pronto como sea posible, lo que significa que tienen que reescribir algunas partes de su código fuente Windows. (Ya les habíamos advertido desde hace varios años.

En varias versiones principales, 4D ha advertido a los desarrolladores en contra del uso de las subtablas. Desde 4D v11, es imposible crear un campo del tipo subtabla. Los subregistros tienen algunas limitaciones conocidas. Por ejemplo, siempre se cargan en memoria; no se manejan por los comandos SEND RECORD o DUPLICATE RECORD.

No tenemos planes de eliminar el soporte para las subtablas en un futuro próximo, pero es realmente el momento de que los desarrolladores conviertan sus subtablas a tablas N-> regulares porque tenemos la intención de eliminarlas en una futura versión principal de 4D. Los desarrolladores que utilizan subtablas por razones de rendimiento (algunas situaciones específicas en las que la carga de los registros relacionados de era lenta) pueden estar tranquilos, especialmente con v12: utilizar las relaciones N <-> 1 clásicas es muy rápido.

Básicamente, hay dos formas principales para eliminar subtablas (nota: lo siguiente no es una tecnología completa de punta; sólo una visión general rápida):

• Antes de la conversión de una estructura pre-v11: en 2004, crear la tabla N apropiada y el campo ID en la tabla 1 (si no está ya allí). Luego, cambie el código en todas las partes es necesario (ver más adelante).
• Después de la conversión: en esta situación, 4D ha reemplazado la subtabla con una tabla N usando una relación especial, que permite que el lenguaje para trabajar con la subselección y los subregistros. El desarrollador 4D necesita eliminar esta relación especial, sustituirla por una relación normal y cambiar el código por todas partes si es necesario (ver más adelante).

Lo que queremos decir con "cambiar el código por todas partes si es necesario" es, básicamente:

• Crear los nuevos formularios, actualizar los formularios incluidos
• En los métodos (proyecto, formulario, objeto, etc.):
  • Remplace todos los comandos del tema "Subregistros" con el comando Selection o Record correspondiente (por ejemplo, reemplazar CREATE SUBRECORD con CREATE RECORD, llenando los campos ID)
  • Explícitamente cargar los registros N cuando sea necesario

Note: a partir de 4D v14 R3, puede asignar valores a los campos "id_added_by_converter" especiales que se agregan automáticamente por 4D cuando convierte una base de datos que contiene subtablas. Esto le permite mantener el enlace "relación subtabla", y agregar o modificar registros relacionados, sin necesidad de usar comandos en desuso tales como _o_CREATE SUBRECORD. Una vez que haya actualizado sus métodos, estas relaciones especiales pueden ser sustituidas por otros estándares con ningún cambio en su código.

El soporte al modo ASCII (sinónimo de "modo no Unicode") conduce a un bajo rendimiento en la manipulación de texto, ya que se debe convertir desde y hacia Mac-roman cada vez que se utiliza en la estructura legacy-converted. Planeamos eliminar el modo ASCII en futuras versiones principales.

Note que el soporte para el modo ASCII ya se retiró para estructuras compiladas que se ejecuten bajo 4D Server 64 bits para Windows. 

Los desarrolladores 4D deben, para estructuras convertidas, activar el modo Unicode. La documento PDF Conversión a 4D v14 da pistas sobre este tema.

También note que el soporte el modo ASCII no está disponible en la versión 4D Server 64 bits para OS X.

Esta es otra antigua tecnología Mac OS, en desuso desde Mac OS X 10.4 (Tiger, 2005). Los recursos se utilizan para almacenar datos estructurados, como texto y cadenas (localización), así como también iconos, etc. Básicamente, podemos decir que no son los recursos los que están en desuso, es su soporte en disco, conocido como el resource fork. El resource fork es parte del sistema de archivos de Mac OS y desde el inicio de Mac OS X, Apple ha tratado de eliminar este soporte, ya que no es compatible con otros sistemas de archivos (Unix, Windows), y es la fuente de una gran cantidad de problemas cuando los archivos se transfieren a través de la red.

En Windows, este mecanismo se emula y y los recursos Mac residen en un archivo .RSR.

Pero aún así, incluso si aún hay APIs para manejar los recursos (y Mac OS maneja de forma transparente los recursos almacenados en un data fork), ya no se recomienda utilizar este viejo mecanismo por varias razones:

• Los textos y las cadenas son Mac-roman. No se puede almacenar Unicode en recursos de tipo TEXT o STR #
• Los recursos PICT almacenan PICTs: no es moderno, obsoleto, sin transparencia, etc. (Consulte el tema "PICT" arriba.)
• El conteo de los recursos y el tamaño de los recursos son limitados (unos 2.700 recursos o 16 MB)

Hemos eliminado soporte para comandos de escritura/creación de recursos

La gran mayoría de las aplicaciones 4D que utilizan recursos están, de hecho, utilizando recursos "Strings List", 'STR#'. 4D ofrece las herramientas para cambiar fácilmente del STR # a XLIFF:

• El componente 4D Pop puede crear automáticamente los archivos XLIFF mediante la lectura y transferir el contenido de la STR #.
• Todas las rutinas y las expresiones que hacen referencia a trabajo STR# sin cambio con XLIFF. Por ejemplo, si la etiqueta de un botón o un menú era ":15000,3" (que significa "conseguir el tercer elemento de STR# ID 15000"), 4D cargará el XLIFF apropiado (si existe).

Para otros tipos de recursos:

• Poner los recursos en archivos separados dentro de la carpeta Resources (crear subdirectorios si es necesario):
  • Guardar recursos 'TEXT' en archivos XLIFF o .txt
  • Guardar recursos 'PICT' como archivos .jpg/.png/etc. separado
  • Guardar recursos 'PICT' + MASK’ como archivos png
  • Utilizar (en Mac) icns en lugar de ICON o iconos de colores
  • Guardar todos los recursos privados como sea apropiado para usted (normalmente: guardar como un archivo binario con una extensión específica)
• Utilice la carpeta "Recursos" para almacenar sus recursos. Utilice Get 4D folder (carpeta de recursos actuales) para obtener dinámicamente la ruta padre para sus recursos.

Hay dos tipos de plug-ins: los que utilizan el nuevo plug-in API y los que siguen utilizando el viejo (con QuickDraw). Para los plug-ins que utilizan la vieja caja de herramientas (con QuickDraw): para mantener la compatibilidad, el dibujo/renderización ya no se realiza directamente en un puerto QuickDraw, como en las versiones anteriores, pero en su lugar a través de un área GWorld QuickDraw offscreen dedicada al plugin.

En consecuencia, hay que respetar algunas reglas, como los plug-ins no deben modificar el puerto actual definido por el contenedor (objeto formulario).

Para los plug-ins que utilizan la nueva caja de herramientas: sólo se utiliza esta nueva caja de herramientas y no QuickDraw: (ver http://sources.4d.com/trac/4d_4dpluginapi/wiki/native_drawing)

Los comandos obsoletos son aquellos cuyo uso es altamente desaconsejable y que no se mantendrán en futuras versiones del programa.

Para mayor claridad en 4D v15, cada comando obsoleto tiene un prefijo "_o_", si este no era ya el caso.

Como los comandos obsoletos ya no están disponibles en las listas 4D (ver la sección Obsolete commands now hidden), no podrá seleccionarlos. Sólo serán renombrados en el código existente.

La siguiente tabla muestra los comandos obsoletos renombrados en 4D v15 y por lo tanto retirados de las listas 4D: