FiveTech Support Forums

Russimicro,

Creo que lo entiendes mal, quizas sea yo... El backend == harbour. Harbour == server. Server puede estar en la china. No se porque grabas y recuperas json en el server...

C.

Russimicro, It looks to me as if there are actually two different approaches being discussed here, and they solve different problems.

On the one hand, there is a simple offline-first / sync prototype, where the client keeps local state (for example in localStorage) and later pushes that state to the server. In this model, a JSON file on the server is not meant to be a full database, but rather a temporary synchronization store or transport buffer. Taken one step further, this approach can evolve naturally: the server accepts and persists change sets, and a separate worker or backend process later validates, merges, and applies them to a real data store. As a demonstration of offline sync and data flow, this makes sense and is conceptually consistent.

We are actually using this approach in production in our waiter ordering system. Orders are first stored locally on the device and only later sent to the server. Historically, this was done by sending simple TXT files to what we call a print server. All business logic — routing, validation, ordering, and printing — is hosted inside that print server process. This design originated back in the PocketPC era, where direct DBF access was not available on the devices, and it has proven to be extremely robust in real-world operation. The important point is that the client is allowed to work independently, while the server-side worker remains the authoritative place where decisions are made.

On the other hand, there is the classic server-authoritative application model, where the server is the single source of truth. In that case, storing JSON files on the server as a data store is not the intended design — the database layer or a managed in-memory state would be the appropriate place. This model optimizes for simplicity and directness and is well suited for traditional request/response applications.

Both approaches are valid, but they optimize for different goals.

Best regards, Otto

Buen dia..

Codigo generado por COPILOT...

La idea general... es que el .prg de lógica... procese la consulta (hix : dbf / sql).. y el resultado lo deje en el servidor en archivo json o lo envía al cliente..(todo según necesidad).. el cliente lo recibe directamente o lo busca cuando lo requiera (según necesidad)... y lo almacena localmente (localStore o sessionStore) para procesos de lógica que se ejecutan del lado del cliente con JS o del lado del servidor con HIX, o como base para restaurar paginas ante la navegación entre páginas.. la idea es ver el manejo asincrónico y ver que hay multiples formas de hacerlo ( JS, TS, .exe, servidor de aplicaciones, restApi, Websocket....).. y todos son validos... al final también se busca mantener en memoria del cliente o navegador los datos JSON y no tener que volver al servidor... Aqui surge otro tema ( procesamiento del lado del cliente y/o del lado del servidor)...

Caso particular : Para el envio de documentos electronicos a la DIAN... en mi app local con fivewin... tengo dos opciones : 1 directamente desde mi código usando un activeX (chilkat) y 2. Desde un app externo ( (x)-harbour ) con la misma logica de la opcion 1, que recibe json de entrada y genera salidas json.. (lo usan colegas desde sus app)... Si decido implementar en HIX, la opcion 2, seria la adecuada... un .exe como servidor de aplicaciones.... y aquí tiene sentido... porque el app .prg con hix... graba un json en el servidor ... y el servidor, puede o no enviar respuesta al cliente... o el cliente puede leer respuesta (todo según reglas del negocio)

JSON can be cached on the client, processed asynchronously, and reused across navigation — but the question is always where authority and responsibility live. Once that is clear, multiple technical approaches can coexist without conflict.

Russimicro,

No pienso contestar respuestas de IA. Lo que quieres tu es hacerlo... TODO y para eso se ha de aprender muchas tecnicas. Yo me decidiria por una y empezaria a experimentar. Por ejemplo un boton en pantalla y que el servidor te devuelva en un json la hora, e ir consolidando escenarios.

Hix te ofrece la posibilidad de hacerlo, como cualquier otro servidor....

C.

Russimicro, I think it would really help to briefly describe the use case you have in mind — where and how you plan to use this solution. Is the goal to extend existing FiveWin applications toward the web, or is this meant as something new from the start? With that context, it becomes much easier to evaluate the approach. Best regards, Otto

Estoy en proceso de ver cómo puedo pasar de app local con fivewin , usando hix como servidor ...

para el caso puntual estoy viendo si puedo seguir con mi logica, sin cambiar mucho..

Hasta el momento no he usado nada de IA.. el codigo que reporte es solo a manera de ilustración... que coincida con temas o criterios que uso en la web 100% , y que podrian ajustarse a un desarrollo con harbour como script es otra cosa.. de hecho no he solicitado soporde de HIX, solo estoy evaluando funciones de fivewin (DLL ) para poder usar con harbour.

Nota : No es una aplicacion nueva... ya para nuevas APP decide irme 100% web con framework empresariales... sin lenguajes de script del lado del servidor ( ANGULAR (servidor web propio )+ yakarta EE / nose JS (servidores de aplicaciones) ) ... 100% rest api y websocket

russimicro, I understand. Choosing a development environment is a genuinely difficult decision — and it always has been.

What has always been a real strength of Harbour and FiveWin is how close they are to the Windows API. With #pragma BEGINDUMP and C integration, you effectively have access to the full platform when you need it. That flexibility has carried many systems for decades.

If you decide to continue on the web side — especially assuming a beginner perspective — I would personally be cautious with the heavier frameworks mentioned earlier. One practical suggestion would be to ask the AI directly about long-term viability and how well a given framework is supported by AI tooling today.

What we observe on our side is that the “youth” is no longer starting with large frameworks first. Many newcomers start with AI assistance and learn incrementally, often without committing early to complex framework ecosystems. In that context, some frameworks feel increasingly detached from how people actually learn and experiment today, which in turn limits research and real-world development.

For that reason, I believe staying close to web standards is a very solid choice: HTML, CSS, and plain JavaScript, combined with clear APIs. These fundamentals age well, are universally understood, and are extremely well supported by AI tools.

In the end, there is no single right answer — but simplicity, transparency, and proximity to standards tend to keep options open longer.

Best regards, Otto

P.S. At the moment, I am also working on cleaning up my web version by removing Bootstrap and jQuery entirely. The previously used design templates have to go as well. Most importantly, everything must work reliably on the iPhone.

The room-planning UI is particularly demanding: it has to support mouse, keyboard, and touch equally well — on reception desktops, office PCs, tablets at home, smartphones on the go, and even in the car. In practice, this means desktop, tablet, and mobile usage patterns all at once, without special cases or separate code paths.

This is another reason why I currently prefer staying close to web standards and keeping the UI layer as lightweight and transparent as possible. If it works cleanly on an iPhone under real conditions, it usually works everywhere else too.

Maintenance and debugging are essential. If you develop for the web without owning an iPhone, I would strongly recommend getting one. There are simply too many behavioral differences compared to Android to ignore.

Touch handling, scrolling, focus behavior, viewport sizing, virtual keyboards, and gesture interactions behave differently enough that real testing on iOS is unavoidable. Emulators and simulators help, but they are not a substitute for the real device.

In practice, many issues only show up on iPhone — and only under real usage conditions. If it works reliably there, long-term maintenance becomes much more predictable.

Otto ... buena tarde

Gracias por su comentario, tendré en cuenta sus recomendaciones

Saludos