Discussion:
Web application development
(too old to reply)
Benoit Minisini
2006-10-15 19:52:17 UTC
Permalink
I'm currently developping a component for making web applications with CGI. I
need it for a project for my job.

This component has almost the same interface as ASP, except that you don't
have the equivalent of ASP pages (i.e. you must print your HTML code on the
standard output).

But you have:
- The Request class for reading the request, sent by both GET and POST method.
- The Response class for sending the answer. It manages headers and cookies.
- The Session class for an automatic session management. The only restriction
is that session variables can only be basic types, Array or Collection.
- An HTML function for encoding text in HTML.

The code is in the svn at the moment.

If you have comments, ideas, needs on how should work such a component, tell
now!

Regards,
--
Benoit Minisini
Rob
2006-10-15 22:40:16 UTC
Permalink
Post by Benoit Minisini
If you have comments, ideas, needs on how should work such a
component, tell now!
As soon as I'm done with the project I've been working on all
year, I intend to write a "gb.ajax" component that will let you
take forms designed in the IDE and deploy them as web apps,
generating the necessary XHTML and Javascript and faking the
event loop through XMLHttpRequest and some kind of state
preservation on the server side. I'm sure there will be
complications as I develop it, but after spending the last year
and a half developing a gigantic Ajax app using nothing but
perl's CGI module, Gambas forms parsed out into HTML, and
handwritten Javascript, I think I'm ready ;)

I know the aim of my component will be very different than yours
(I don't intend to let the developer output HTML or Javascript
code manually at all), but I'm curious as to whether you think
it would make more sense as its own top level component or if it
should hang off of gb.asp, or whatever you'll be calling your
new component. It seems to me that they're bound to have SOME
functionality in common, though it's unclear how much.

Rob
Benoit Minisini
2006-10-16 19:27:16 UTC
Permalink
Post by Rob
Post by Benoit Minisini
If you have comments, ideas, needs on how should work such a
component, tell now!
As soon as I'm done with the project I've been working on all
year, I intend to write a "gb.ajax" component that will let you
take forms designed in the IDE and deploy them as web apps,
generating the necessary XHTML and Javascript and faking the
event loop through XMLHttpRequest and some kind of state
preservation on the server side. I'm sure there will be
complications as I develop it, but after spending the last year
and a half developing a gigantic Ajax app using nothing but
perl's CGI module, Gambas forms parsed out into HTML, and
handwritten Javascript, I think I'm ready ;)
I know the aim of my component will be very different than yours
(I don't intend to let the developer output HTML or Javascript
code manually at all), but I'm curious as to whether you think
it would make more sense as its own top level component or if it
should hang off of gb.asp, or whatever you'll be calling your
new component. It seems to me that they're bound to have SOME
functionality in common, though it's unclear how much.
Rob
I'm not sure that it is a good idea to try to reuse directly GUI forms for
making WEB forms. GUI controls are complicated, and usually do things
differently from WEB controls.

I suggest making WEB controls only based on what is possible with HTML and
JavaScript, without trying to behave exactly like GUI controls.

A WebForm would be a container for other WebContainers and WebControls. They
will generate an HTML page that can be sent to the browser. WebControls could
raise events to be catched in the server code, for example to get data like
the TableView Data event, or events that comes from XmlHttp requests from the
client (don't know at the moment).

The current gb.web component simplify the writing of CGI script by providing
classes for request management, response generation, session management...
See the svn repository for that.

I think you could based your gb.ajax component on gb.web, because having Ajax
WebControls seems to be orthogonal to the management of HTTP requests and
Session management.

Of course CGI may not be the right technology for that. But we can imagine a
FastCGI component, that has all the simplicity of CGI without the need to
launch a process for each request - even if launching a process on Linux is
far lighter than on other OS. :-)

At the moment, session management is based on file saved by the CGI script
into /tmp/gambas.$UID/session directory, and reloaded at each request.

As Ajax applications seems to have to maintain a greater amount of data
between request, maybe it is not the fastest technology. We could imagine a
session server that store the data permanently, and give it on demand to the
process that handle requests.

Maybe a Ajax Gambas application could be an HTTP server on its own. It would
be cool. I don't know if Apache (or other web servers) can automatically send
an HTTP request to another port, where the Gambas server would listen.

What do you think about all that?
--
Benoit Minisini
Daniel Campos
2006-10-16 20:21:08 UTC
Permalink
Exactly Benoit:

I think the future of web apps is not raising a process each time the
server receives a request, but having a single process running while
the connection is open, while the client is running the
"application/web page", and there should be always a socket connected
between the server and the client.

In that sense people interested in "gb.ajax" (I hope somebody finds a
better name), should check the Comet programming technology:
http://en.wikipedia.org/wiki/Comet_%28programming%29 , that surely
will provide big ideas for that component.

A person here was able to run parts of the Squeak environment
(Smalltalk) directly in a browser. Comet techniques also allows to
draw directly on a client web canvas (Firefox and Safari/Webkit have
one, and there's an emulation for IE), and even work sending graphical
events from the client to the server and sending a server-client reply
using Javascript injection.

Daniel
Post by Benoit Minisini
Post by Rob
Post by Benoit Minisini
If you have comments, ideas, needs on how should work such a
component, tell now!
As soon as I'm done with the project I've been working on all
year, I intend to write a "gb.ajax" component that will let you
take forms designed in the IDE and deploy them as web apps,
generating the necessary XHTML and Javascript and faking the
event loop through XMLHttpRequest and some kind of state
preservation on the server side. I'm sure there will be
complications as I develop it, but after spending the last year
and a half developing a gigantic Ajax app using nothing but
perl's CGI module, Gambas forms parsed out into HTML, and
handwritten Javascript, I think I'm ready ;)
I know the aim of my component will be very different than yours
(I don't intend to let the developer output HTML or Javascript
code manually at all), but I'm curious as to whether you think
it would make more sense as its own top level component or if it
should hang off of gb.asp, or whatever you'll be calling your
new component. It seems to me that they're bound to have SOME
functionality in common, though it's unclear how much.
Rob
I'm not sure that it is a good idea to try to reuse directly GUI forms for
making WEB forms. GUI controls are complicated, and usually do things
differently from WEB controls.
I suggest making WEB controls only based on what is possible with HTML and
JavaScript, without trying to behave exactly like GUI controls.
A WebForm would be a container for other WebContainers and WebControls. They
will generate an HTML page that can be sent to the browser. WebControls could
raise events to be catched in the server code, for example to get data like
the TableView Data event, or events that comes from XmlHttp requests from the
client (don't know at the moment).
The current gb.web component simplify the writing of CGI script by providing
classes for request management, response generation, session management...
See the svn repository for that.
I think you could based your gb.ajax component on gb.web, because having Ajax
WebControls seems to be orthogonal to the management of HTTP requests and
Session management.
Of course CGI may not be the right technology for that. But we can imagine a
FastCGI component, that has all the simplicity of CGI without the need to
launch a process for each request - even if launching a process on Linux is
far lighter than on other OS. :-)
At the moment, session management is based on file saved by the CGI script
into /tmp/gambas.$UID/session directory, and reloaded at each request.
As Ajax applications seems to have to maintain a greater amount of data
between request, maybe it is not the fastest technology. We could imagine a
session server that store the data permanently, and give it on demand to the
process that handle requests.
Maybe a Ajax Gambas application could be an HTTP server on its own. It would
be cool. I don't know if Apache (or other web servers) can automatically send
an HTTP request to another port, where the Gambas server would listen.
What do you think about all that?
--
Benoit Minisini
-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Gambas-user mailing list
https://lists.sourceforge.net/lists/listinfo/gambas-user
Rob
2006-10-16 21:04:39 UTC
Permalink
Post by Daniel Campos
In that sense people interested in "gb.ajax" (I hope somebody
finds a better name), should check the Comet programming
http://en.wikipedia.org/wiki/Comet_%28programming%29 , that
surely will provide big ideas for that component.
I had actually expected to make use of the Comet technique, but I
don't think it's safe to assume browsers will always behave
nicely (i.e. not break the connection) and I certainly don't
want to put any requirements on the server except for having
Gambas installed as a CGI interpreter (i.e. no special
middleware or proxy.) So state still needs to be maintained
between requests, and cleaned out periodically.

But at its simplest, Comet can be implemented as "open a
connection, when the connection returns something, handle it,
and when the connection closes, immediately reopen it." You
have a message queue on the browser side that transmits requests
over that one persistent connection and receives drawing and
timer events from the server side. I would also want to have
some kind of ping or heartbeat functionality, because if there's
one thing I've learned in the last year and a half of being up
to my elbows in Ajax, it's that TCP connections are not quite as
reliable in the real world as they are in the spec.

I agree that "gb.ajax" or "gb.web.ajax" would suck as a name, but
you can't deny its buzzword compliance ;) If someone does
suggest another name, I hope that it isn't just "gb.comet"
or "gb.SomeOtherToolkit" or "gb.SomeNewMeaninglessName". I'd
sooner call it "gb.form.web" (or "gb.web.form"), if that won't
raise people's expectations too high.
Post by Daniel Campos
A person here was able to run parts of the Squeak environment
(Smalltalk) directly in a browser. Comet techniques also
allows to draw directly on a client web canvas (Firefox and
Safari/Webkit have one, and there's an emulation for IE), and
even work sending graphical events from the client to the
server and sending a server-client reply using Javascript
injection.
I certainly intend to support the Firefox canvas in some way,
though I don't know whether my graphics-fu and/or the Firefox
canvas itself is good enough to implement most of what Gambas'
DrawingArea does.

In answer to Benoit's earlier post, I see your point about having
different controls for the web vs. gb.qt/gb.gtk, but the whole
point of my "gb.ajax" concept is to allow novice web programmers
to design their forms in the Gambas IDE and deploy them to the
web just by moving the checkmark from "gb.qt" to "gb.ajax" in
project properties. It will make for some pretty crappy forms
being deployed, but then, look at the hideous things people have
done with Scriptaculous. I don't think anyone would say they'd
rather that it hadn't been written.

It's a lofty goal, but why have goals that aren't?

Rob
Benoit Minisini
2006-10-16 21:24:46 UTC
Permalink
Post by Rob
Post by Daniel Campos
In that sense people interested in "gb.ajax" (I hope somebody
finds a better name), should check the Comet programming
http://en.wikipedia.org/wiki/Comet_%28programming%29 , that
surely will provide big ideas for that component.
I had actually expected to make use of the Comet technique, but I
don't think it's safe to assume browsers will always behave
nicely (i.e. not break the connection) and I certainly don't
want to put any requirements on the server except for having
Gambas installed as a CGI interpreter (i.e. no special
middleware or proxy.) So state still needs to be maintained
between requests, and cleaned out periodically.
But at its simplest, Comet can be implemented as "open a
connection, when the connection returns something, handle it,
and when the connection closes, immediately reopen it." You
have a message queue on the browser side that transmits requests
over that one persistent connection and receives drawing and
timer events from the server side. I would also want to have
some kind of ping or heartbeat functionality, because if there's
one thing I've learned in the last year and a half of being up
to my elbows in Ajax, it's that TCP connections are not quite as
reliable in the real world as they are in the spec.
I agree that "gb.ajax" or "gb.web.ajax" would suck as a name, but
you can't deny its buzzword compliance ;) If someone does
suggest another name, I hope that it isn't just "gb.comet"
or "gb.SomeOtherToolkit" or "gb.SomeNewMeaninglessName". I'd
sooner call it "gb.form.web" (or "gb.web.form"), if that won't
raise people's expectations too high.
Post by Daniel Campos
A person here was able to run parts of the Squeak environment
(Smalltalk) directly in a browser. Comet techniques also
allows to draw directly on a client web canvas (Firefox and
Safari/Webkit have one, and there's an emulation for IE), and
even work sending graphical events from the client to the
server and sending a server-client reply using Javascript
injection.
I certainly intend to support the Firefox canvas in some way,
though I don't know whether my graphics-fu and/or the Firefox
canvas itself is good enough to implement most of what Gambas'
DrawingArea does.
In answer to Benoit's earlier post, I see your point about having
different controls for the web vs. gb.qt/gb.gtk, but the whole
point of my "gb.ajax" concept is to allow novice web programmers
to design their forms in the Gambas IDE and deploy them to the
web just by moving the checkmark from "gb.qt" to "gb.ajax" in
project properties. It will make for some pretty crappy forms
being deployed, but then, look at the hideous things people have
done with Scriptaculous. I don't think anyone would say they'd
rather that it hadn't been written.
It's a lofty goal, but why have goals that aren't?
Rob
Just tell us where you can go in emulating gb.qt and gb.gth controls in
gb.web.form.

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 think you may find information there for your needs.

Maybe we can imagine two components: gb.web.form and gb.web.form.ajax. The
first component will simply includes Web controls that do not need Ajax (i.e.
some HTML forms and Javascript only).

Regards,
--
Benoit Minisini
Daniel Campos
2006-10-16 22:18:01 UTC
Permalink
Post by Benoit Minisini
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
Rob
2006-10-16 23:22:22 UTC
Permalink
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
Benoit Minisini
2006-10-17 06:10:58 UTC
Permalink
Post by Rob
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...)
Post by Rob
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.
Post by Rob
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
Benoit Minisini
2006-10-17 06:06:27 UTC
Permalink
Post by Daniel Campos
Post by Benoit Minisini
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. :-)
Post by Daniel Campos
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.
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
nando
2006-10-16 08:20:29 UTC
Permalink
Very interesting.
I just completed a large app with PHP - logging in, sessions, mysql, fpdf, gdlib.
I prefer Gambas. Having the ability to have GET POST vars readily
available would be cool. Having sessions managed by a component would
be cool too. An example for gdlib replacement would be nice.
Rob's idea of HTTPrequest for ajax is nice too.
All very, very cool things for Gambas.
-Fernando




---------- Original Message -----------
From: Benoit Minisini <***@users.sourceforge.net>
To: gambas-***@lists.sourceforge.net
Sent: Sun, 15 Oct 2006 21:52:17 +0200
Subject: [Gambas-user] Web application development
Post by Benoit Minisini
I'm currently developping a component for making web applications with CGI. I
need it for a project for my job.
This component has almost the same interface as ASP, except that you don't
have the equivalent of ASP pages (i.e. you must print your HTML code on the
standard output).
- The Request class for reading the request, sent by both GET and POST method.
- The Response class for sending the answer. It manages headers and cookies.
- The Session class for an automatic session management. The only restriction
is that session variables can only be basic types, Array or Collection.
- An HTML function for encoding text in HTML.
The code is in the svn at the moment.
If you have comments, ideas, needs on how should work such a component, tell
now!
Regards,
--
Benoit Minisini
-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Gambas-user mailing list
https://lists.sourceforge.net/lists/listinfo/gambas-user
------- End of Original Message -------
Continue reading on narkive:
Loading...