Business
Jobs
  • About Us
  • Solutions
    • Job Postings
      Post your job and receive qualified candidates in 48h.
    • Candidate Assessments
      500+ technical and psychological tests, plus anti-fraud.
    • Headhunting
      Tailor-made executive search from start to finish.
    • Payroll + EOR
      Payroll dispersal and EOR across 15+ LATAM countries.
  • Pricing
  • Jobs

0

458
Views
¿Hay alguna forma de guardar y recuperar texto de un cuadro de datos editable en un archivo específico? (Todo del lado del cliente)

Estoy haciendo informes estadísticos para los clientes y elegí la solución HTML como plantilla de informe.

Tengo este problema en el que quiero que un usuario pueda editar un cuadro de texto de un documento html y guardarlo (tan pronto como abandone el área o al hacer clic en el botón Guardar) para anotar cosas como gráficos, por ejemplo.

El contenido debe imprimirse cada vez que abre el archivo .html. Además, hay potencialmente varias páginas html dentro del informe (un cuadro editable por subpágina html es suficiente)

Además, una gran restricción aquí es que este archivo html está abierto localmente y debe compartirse entre los usuarios (por ahora tengo que seguir con esta solución del lado del cliente, pero planeo hacerlo del lado del servidor).

Como ya habrá entendido, no puedo usar la solución localStorage ya que depende del sistema/usuario y los datos no se guardarán si las personas comparten el informe.

Prefiero ir con una solución en la que sea posible guardarlo en un archivo $UID .txt, por ejemplo (un $UID para cada subpágina que la gente quiera anotar) y recuperarlo siempre que el estado del contenido editable se guarda en el mismo lugar en la arquitectura de carpetas del informe, todas las demás personas lo abrirán tal cual cuando obtengan este informe editado.

Gracias por tu tiempo !

UNA.

EDITAR

Debería haber estipulado algunas cosas:

1- El informe se compone de cientos de archivos html independientes. Son componentes básicos de html y javascript que son traducidos por un navegador web clásico sin la necesidad de una conexión a Internet o un servidor localhost.

2- Estructura de carpetas:

 root_folder | |---- index.html (main page to access all sub pages) |---- graphics |---- graphic1.html |---- graphic2.html

3- Las personas deben compartir el informe por su cuenta y no hay una base de datos de usuarios. La única restricción es que después de realizar una modificación en un cuadro de contenido editable, el texto debe escribirse en algún lugar de la estructura de carpetas (ver 2) y recuperarse automáticamente la próxima vez que algún usuario (ya sea el editor original o el siguiente en otra computadora). siempre que el primer editor haya compartido todo el directorio con su propia edición) abrirá (o actualizará) el archivo html.

Sé que hay mejores soluciones, pero realmente tengo que seguir con una solución independiente por ahora, ¡esperando que haya una solución para este problema!

Gracias de nuevo por tu tiempo.

about 4 years ago · Juan Pablo Isaza
1 answers
Answer question

0

Si no hay un componente del lado del servidor y no desea utilizar el almacenamiento local (en la zona de pruebas) del navegador (ya sea LocalStorage, IndexedDb o de otro modo), entonces le queda FileReader para leer datos y crear direcciones URL de Blob para descargar datos.

La experiencia de usuario sería algo así:

  1. El usuario abre su archivo .html (local)
  2. Se les solicita que abran la base de datos (pueden ser archivos de texto) con un <input type="file"> .
  3. Utiliza la API de FileReader para cargar este archivo. Nota: no puede usar fetch o XMLHttpRequest para hacer esto automáticamente.
  4. Cuando el usuario haya terminado de ingresar su contenido, guárdelo en un objeto Blob y luego cree un enlace de data: con createObjectURL . Podría poner esa URL generada en un enlace <a href="..." download>Save</a> .

Como dependería de sus usuarios asegurarse de seleccionar los archivos de base de datos adecuados y guardarlos con el nombre de archivo correcto, esto no es lo ideal. Recomendaría encarecidamente una solución (auto)hospedada. Eso también podría lidiar mucho mejor con múltiples usuarios simultáneos.

Un componente del lado del servidor no tiene que ser complejo: si comienza en un idioma con el que se siente cómodo y usa una base de datos SQLite, llegará muy lejos en una configuración menos compleja que la que está describiendo.

about 4 years ago · Juan Pablo Isaza Report
Answer question
Find remote jobs

Discover the new way to find a job!

Top jobs
Top job categories
Business
Post vacancy Pricing Sales
Legal
Terms and conditions Privacy policy
© 2026 PeakU Inc. All Rights Reserved.
Andres GPT
Show me some job opportunities
There's an error!