Flex: DeepCopy de FileReference

Question

en mi proyecto, dejo que los usuarios elijan imágenes utilizando la clase FileReference. Luego cargo estas imágenes en sus propiedades .data, usando la función load(). Después de esto, realizo algunas manipulaciones locales y las envío al servidor.

Lo que me gustaría hacer es poder iterar nuevamente sobre las FileReferences elegidas, cargarlas en propiedades .data, realizar una manipulación diferente y enviarlas al servidor una vez más. Sé que debería poder hacer esto desde el evento invocado por el usuario, eso no es un problema aquí.

El problema es que una vez que se carga la FileReference por primera vez, no puedo descargarla de ninguna manera y no puedo guardar los datos de todas las imágenes en la memoria porque son enormes.

Así que supongo que hay una sola cosa que puedo hacer, que es realizar un DeepCopy en FileReference ... Luego podría cargar la primera versión, descartarla y usar la copia para la segunda 'ejecución'.

Intenté utilizar ObjectUtil.copy, pero cuando accedo, p. .name propiedad de la copia, falla con:

Error #2037: Functions called in incorrect sequence, or earlier call was unsuccessful. 

en nombre flash.net::FileReference/get()

el fragmento relevante:

registerClassAlias("FileReference",FileReference); 
masterFileList.addItem(FileReference(ObjectUtil.copy(fr_load.fileList[i]))); 
trace(masterFileList[i].name) 

no es cierto que Cuáles son algunas propiedades protegidas de la clase FileReference que impiden que se copie? Si es así, ¿puedo eludir esto de alguna manera? ¿O hay alguna otra solución para mi problema general?

¡Agradezco cualquier pista/idea!

Answer 1

no puede usar un ObjectUtil.copy. Este método está diseñado para copiar solo objetos de datos (clases de VO).

debe crear una nueva FileReference y copiar las propiedades, una por una. Cree una función para hacer esto ...

Answer 2

¿Lo copiaría en un archivo temporal y luego se cargaría el archivo temporal? Por ejemplo

 var fileRef:FileReference = new FileReference(); 
     fileRef.browse(); 

     ...................... 

     var tmpFile:File = File.createTempFile(); 
     try { 
      var tmpFileStream:FileStream = new FileStream(); 
      tmpFileStream.open(tmpFile, FileMode.WRITE); 
      trace("Opened file: " + tmpFile.nativePath); 
      tmpFileStream.writeBytes(fileRef.data); 
      trace("copied file"); 
     } catch (error:Error) { 
      trace("Unable to open file " + tmpFile.nativePath + "\n"); 
      throw error; 
     } 

Answer 3

Estoy pensando que la operación está completamente prohibida, por buenas razones. Si puede duplicar una nueva FileReference a través del código ActionScript, también podrá fabricar un objeto FileReference a través del código ActionScript. Por supuesto, sería un agujero de seguridad bastante malo si pudieras forzar la carga de un archivo arbitrario.

Mantener una copia de los datos en la memoria realmente no es tan malo como una solución. Después de todo, es temporal. La computadora cliente típica debería poder administrar unos cientos de MB extra de datos sin ningún problema. Sin duda es una mejor opción que hacer que su navegador haga dos cargas por separado, que es lo que su intento de solución terminaría haciendo.

Una solución potencial completamente diferente a este problema es evitar la manipulación de imágenes por parte de Flex. Flex podría publicar el archivo cargado directamente en el servidor, y el servidor podría hacer la manipulación de la imagen. Por supuesto, si la manipulación se lleva a cabo a través de las interacciones del usuario, entonces eso no funcionaría en absoluto.

Answer 4

Estaba tratando de hacer casi exactamente lo que estaba haciendo, y casi me rindo después de leer algunas de las respuestas, pero creo que encontré la manera de hacerlo.Descubrí que si tiene un objeto FileReference, si llama al load() varias veces, funcionará, pero el problema principal es que mantiene los bytes de alta resolución en la memoria después de la primera carga. Como mencionó, para las personas que no conocen el procesamiento de imágenes, este es un gran no-no.

La forma de evitar esto es que después de su primer load(), necesita llamar al método cancel() en FileReference. Desde mi prueba hasta ahora, parece que va a borrar los bytes en FileReference, y load() seguirá funcionando si lo llamas por segunda vez más tarde. Hasta ahora, solo lo he probado en mi sistema, pero funciona bien allí. Solo una advertencia, este no es un comportamiento explícitamente definido en la API, por lo que definitivamente está sujeto a cambios, pero puede ayudarlo a llegar a donde necesita ir mientras tanto.

Espero que ayude.