[Gambas-user] Web application development

[Benoit Minisini]

On Tuesday 17 October 2006 01:22, Rob wrote:
> 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.
>

This is planned. At the moment a component can declare that it handles a new 
kind of form. And the compiler can even compile them.

It is just that: 

- The IDE must handle different kind of forms in the project tree.

- It must understand some global form kind properties (for example, a WebForm 
should use a white background...)

- The control toolbox must adapt to the edited form kind. There are controls 
specific to a specific form kind, and controls that can be displayed in any 
form kind (Timer, Socket...)

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

No, see my previous answer to Daniel.

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

Regards,

-- 
Benoit Minisini