[Gambas-user] Web application development

[Daniel Campos]

>
> I have started a documentation page for Daniel to explain the internal
> behaviour of gb.qt controls: http://gambasdoc.org/help/api/guicomp. (Have you
> read it Daniel?)
>

I just returned from my travels, I'm the open source Phileas Fogg :-))
I'll try during this week.

Rob, may be you got better or more concrete ideas, but I really think
the current gb.qt and gb.gtk components are designed just for a
"continuous-connection" local environment. If you plan to use just
traditional web server connections and JavaScript you will loose the
interactivity that you have in a traditional local interface. May be
the methods and properties could be cloned, but the event part could
not be used if you have not a socket always opened, and even having
it, some events like "MouseMove" could be quite expensive if they're
sent continuously to the server. There should be a way to decide which
events are managed in the client and which ones are managed in the
server, but this is not implemented in gb.qt nor gb.gtk.

Apart from this there are other problems: how do you plan to fill a
large list or a big table? the internet bandwith is short and unstable
many times, and those widgets could spend a lot of time while beeing
filled or drawn. JavaScript + Firefox or IE performance is quite bad
compared with traditional interfaces. The programmer should have any
guide telling him to not use it as in a local traditional way.

May be the design should be adapted to a network environment, instead
of writting a clone. The RAD could provide a special form design for
those widgets, I think that is the less expensive part of the project.
And the widgets could be designed to provide the feedback needed:
automatic progress bars while the data is beeing received in a table
or list, information about the synchronization status between data
shared in server and client, etc

The component should provide also a way to store information to be
shared between server and client, so both parts can read and modify it
in a transparent way for the programmer, so programming could become
as easy as in a local app, without caring about server and client
concepts when possible. In the Futura project we're using "network
shared memory" (CRUDE) in XML, but may be here something lighter could
be used for simple data.

May be SVG could be also a good idea to draw the widgets, there are
plugins for IE and Firefox supports it natively, as well as webkit,
and it provides powerful capabilities compared with the poor HTML
controls (listbox, inputbox, buttons and few more). For example, you
can not put an image inside a HTML button, and this is just the minor
problem. XBL is another interesting idea to create complex widgets,
but it is valid only for Firefox and Webkit at this moment.

And talking about images an other resources, the design of gb.qt and
gb.gtk supposes that images, pdf files and other data is stored
locally inside the executable. However, using browsers you have to
deal with the URL of the resources, an incompatible way to work. Well,
you can put an image into the server executable and send it to the
client, but then you can have a big executable that you have to load
and unload per each connection.

Daniel