FiveTech Support Forums

Hello friends,

Do you think it would be possible to fork and restructure xBrowse?

The plan: a clear separation of data access and presentation to improve maintainability and scalability.

My approach:

Data Access Layer: Separate modules for different databases (DBF, SQL, APIs) to create a unified interface.

xBrowse Display: Data shown only from in-memory arrays, independent of the data source.

Web Integration: Preparing for web applications with JSON data format and API support.

The goal: to make xBrowse simpler, more scalable, and future-proof – for both desktop and web developers.

Best regards,

Otto

The question will be : Is the FiveWin team interested in this kind of vision ?

Are the FW users interested ?

If I see the respons on this forum of many more visions you have about combinations in php/web/FW/Json .... we are almost lost there )))))

For myself, I like FW as it is, especialy Xbrowse. We can do almost all we want and have a robust app. I'm not for cloud/online software, since it is just a matter of time that you will be hacked.

If I would go commercial (i'm not selling any software now) I would go FW as it is. The kind of customers to seek are small business to medium and those can be convinsed to use inhouse server and app.

Also : I'm 2 year away from pension ))))

Hello Mark,

nothing would change for you as an application developer. Everything would remain the same for you here. Only the source code of xBrowse would change.

For example, if you look at the source code, everything is in one file. I think it should be structured more simply. At the moment, there are over 16,000 lines of code in a single sequence. For instance, I think the methods should be placed in separate classes:

METHOD SetDolphin( oMysql, lAddCols, lAutoOrder, aFldNames )

METHOD SetMySql( oMysql, lAddCols, lAutoOrder, aFldNames ) // TMySql object

METHOD SetColFromMySQL( cnCol, cHeader ) // used internally from MySQL

METHOD SetPostGre( oQry, lAddCols, lAutoOrder, aFldNames )

METHOD SetPostGreCol( nCol, oQry )

We are exactly at the point you mentioned. Are the FW users interested? I think the xBrowse source code is currently so complex that only very few can contribute to it. Even though many of us have ideas for improvements.

However, this suggestion has nothing to do with the web. You're mixing things up here.

Best regards,

Otto

Otto wrote:Hello Mark,

nothing would change for you as an application developer. Everything would remain the same for you here. Only the source code of xBrowse would change.

For example, if you look at the source code, everything is in one file. I think it should be structured more simply. At the moment, there are over 16,000 lines of code in a single sequence. For instance, I think the methods should be placed in separate classes:

METHOD SetDolphin( oMysql, lAddCols, lAutoOrder, aFldNames )
METHOD SetMySql( oMysql, lAddCols, lAutoOrder, aFldNames ) // TMySql object
METHOD SetColFromMySQL( cnCol, cHeader ) // used internally from MySQL
METHOD SetPostGre( oQry, lAddCols, lAutoOrder, aFldNames )
METHOD SetPostGreCol( nCol, oQry )

We are exactly at the point you mentioned. Are the FW users interested? I think the xBrowse source code is currently so complex that only very few can contribute to it. Even though many of us have ideas for improvements.

However, this suggestion has nothing to do with the web. You're mixing things up here.

Best regards,
Otto

We should go back many years, xbrowse did not exist and there were the classes Wbrowse (listbox by ceccarelli) and later Sbrowse (by Mercado), the real Xbrowse was used but it was part of an OZLIB package sold separately with other classes included.

Then after the split between the two partners of fivetech, Linares decided to include xbrowse in the fw.

I remember that xbrowse was smoother and was exclusively for the dbf format.

Later Mr. Nageswarao Gunupudi adapted some new functions for Sql, Dolphin and MySql, maybe they should have made child object classes and not put everything in the xbrowse class.


Currently the source lines of the xbrowse class are 19341 and I realize that they are a bit too many, I saw that compiling a simple program with the addition of the xbrowse.prg file the compiler takes a little longer but it is still satisfactory

perhaps as I already said we could think of subclasses and merge the functions into other files but then I think it is too dispersive both for us and for those who are or will be working on it in the future

Maybe for an xbrowse for the web you could already think about making a subclass but I will not delve into this topic because I do not deal with the web as I have already repeated to you many times if I have to write a program for the web I use other programming languages ​​that I have been using for many years now and doing it with fivewin remains very difficult for me, the policy has changed before you could write a source and space it in many operating systems, with the advent of fwh of the web the structure of the source code changes radically I was hoping for an equal source and to link only a library but unfortunately it is not like that and I do not have time to waste time in a new language that I do not know where it will take me.

Hello friends,

Based on the previous feedback, there seems to be little support for restructuring the xBrowse class.
The community has reservations about a fundamental overhaul and considers the existing structure to be sufficient and robust for their use cases.

Since the prospect of a comprehensive revision of xBrowse is not met with broad approval in the forum, I will take the approach of developing form me a web solution from scratch, leveraging current web technologies.

Here is the plan:

HTML Table Layout: A simple, Bootstrap-based layout for styling and responsive design.
JavaScript for Interactivity:
Sorting and filtering directly in the browser using native JavaScript and DOM manipulation.
Pagination for improved user experience and more efficient display.
Dynamic Data Loading: Data will be loaded using fetch() in JSON format, which allows flexibility and independence from the data source.

Avoiding Additional Libraries: Aside from Bootstrap, I rely on pure JavaScript to keep dependencies low and retain full control over the code.

With this approach, the code remains lean, easily maintainable, and can be seamlessly integrated into web applications.

Best regards,
Otto

Dear Otto and friends,

Mr. Rao has invested hours and hours, or better we should say, days and days to improve TXBrowse.

I can only say "hat off" to Mr. Rao for sharing all that hard work with us.

We may need years simply to catch the existing functionality that he has introduced in such great piece of code.