Empresas
Empregos
  • Sobre nós
  • Soluções
    • Publicação de vagas
      Publique sua vaga e receba candidatos qualificados em 48h.
    • Avaliações de candidatos
      Mais de 500 testes técnicos e psicológicos, mais anti-fraude.
    • Headhunting
      Busca executiva personalizada do início ao fim.
    • Folha de Pagamento + EOR
      Dispersão de folha e EOR em mais de 15 países da LATAM.
  • Preços
  • Empregos

0

463
Visualizações
¿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 Respostas
Responde à pergunta

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 Relatório
Responde à pergunta
Encontrar trabalhos remotos

Descubra a nova forma de encontrar um emprego!

melhores empregos
Principais categorias de trabalho
Empresas
Postar vaga Preços Comercial
Jurídico
Termos e Condições Política de privacidade
© 2026 PeakU Inc. All Rights Reserved.
Andres GPT
Recomende algumas ofertas para mim
Preciso de ajuda