[Gambas-user] Web application development

[Benoit Minisini]

On Tuesday 17 October 2006 00:18, Daniel Campos wrote:
> > 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.
>

Hopefully, your travel didn't take 80 days. :-)

> 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.
>

The last point is not a real problem in Gambas, as:
- The executable archive is mapped to the memory.
- The class are loaded from the mapped memory only at first use.

So you can put a big file in your Gambas executable, it won't take more time 
to load. (To be honest, the time to load is proportional to the number of 
files stored in the archive because of a relocation process, but it does not 
take time).

Because of that, I can make a CGI script that handles all different pages of 
website without losing performances.

So you could have image URL that are are interpreted by your project CGI 
script without problems.

Regards,

-- 
Benoit Minisini