[Gambas-user] Web application development

[Rob]

On Monday 16 October 2006 18:18, Daniel Campos wrote:
> 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.

There will be things that gb.whatever has that gb.qt and gb.gtk 
don't have, and vice versa.  MouseMove in particular is 
something that cannot be implemented at all if there's a network 
round-trip between the event firing and the program responding.  
But I think there will be other gb.form implementations someday 
that have the same issues.... can anyone imagine 
gb.form.curses? ;)

> Apart from this there are other problems: how do you plan to
> fill a large list or a big table? the internet bandwith is

This was perhaps the worst problem I had to deal with in my 
current Ajax-based project.  My solution was to replace list 
boxes with auto-suggest text boxes whose onkeyup events 
triggered a search that would fill the list box.  If I were to 
implement that as a more literal replacement for a Gambas list 
box, I would probably populate the list box with Listbox.Count 
blank items, and only populate the items when the user scrolled 
the list to view them.  If that wouldn't work, I might end up 
having to do some kind of canvas-based thing.

There are lots of other glaring issues too.  The PictureBox 
control in Gambas has a lot more features than the img tag in 
(X)HTML.  We'll have a lot less control over the app window than 
we do in Qt or Gtk.  If the app has more than one window, each 
one may open its own connection to the back end app, even if 
we're simulating a dialog like a color picker or InputBox.  Some 
classes, like Desktop and Embedder, will be meaningless in a web 
environment, while others like Font and Window will be vastly 
reduced in functionality.  Most layout controls (VSplit, HBox, 
etc.) will be so code-intensive as to negate their value.  And I 
don't even want to think about things like UserControl yet.

Apart from that, though, Gambas developers looking to migrate 
their apps to the web will need to adapt their programming 
styles to the limitations of sending everything over a network.  
One of my goals will be to make it easier for them to do so than 
it presently is.  The app I've been reimplementing on the web 
was an Access 2.0 application originally, and I don't want 
anyone else to ever have to jump through the hoops I did.

> 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

Hopefully someone who understands the IDE better than I do will 
someday attempt something like that.  To me (even though I have 
hacked it and added to it in the past) the IDE has a lot of 
magic in it.

> 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

I have to admit I never even considered the progress bar approach 
before.  It makes a lot of sense.

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

Yeah, I think I'll have to use XHTML for the form design that 
gets sent to the browser, but otherwise I'd like to avoid 
sending XML over the wires.  It's just too big.  Again, though, 
I don't mean for the developer to have direct access to the 
Javascript generated by the component, though maybe I'll end up 
having to include a way to inject custom code.

> May be SVG could be also a good idea to draw the widgets,
> there are plugins for IE and Firefox supports it natively, as

The SVG plugin for IE will be discontinued as of the end of next 
year and MS hasn't implemented SVG themselves, so I see SVG as a 
dead end unless IE's market share goes below 50%.  If we were 
going to go the vector graphics route, I think it might actually 
make more sense to use swftools.

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

It could be that we could have a dual target, XBL and XAML (for 
IE7) but I personally can't see myself writing anything in XAML 
unless Microsoft were giving me money.

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

Yes, that's a limitation too.  But again, I think that falls into 
the category of "things the developer must learn", and we could 
give him tips along the way.  (As far as PDF's go, I can't see 
myself embedding one in a Gambas app, even on the desktop.  
Generate them in Gambas, sure, but not store a static one in my 
executable.)

Rob