On Mon, 8 Jun 2009, Joost van der Sluis wrote:
Op maandag 08-06-2009 om 14:05 uur [tijdzone +0200], schreef Michael Van
Canneyt:
On Sun, 7 Jun 2009, Joost van der Sluis wrote:
Attached is the source with an example. Install the package and compile
the example. (Change the parameters so it fits to your database) Place
the resulting executable on a web-server and configure it so it's
recognized as an cgi-application. You also have to download jQuery and
jGrid and place those files in the same directory as the cgi-appliation.
It's pretty simple but easy to extend. I hope there will grow something
out of it.
It seems very promising. If I understand it correctly, this is a way
to include javascript client-side components in a a webpage.
Yes, that's the idea.
The TjQueryGrid just produces enough HTML/javascript so the browser knows
where to point to, has some methods to create the data, and the rest is
done by the javascript code from the javascript jQuery component?
Yes. There are also some callback-functions. For example, the
jQuery-client side framework connects to
http://menora.cnoc.nl/extern/jquery/fpcjquery.psp?action=data&compname=jquerygrid1
to retrieve the data. (try it, you'll see the xml-data. json could also be added)
This request is also handled. In case some grid is edited, the same happens. You
can assign a method to TjQueryGrid.OnCellEdit and this method is called when some
data changes.
I suspect that for production code, you would still need to add some
session info to the whole ?
Well, yes. But you could use the FCL-web sessions. But in that case the
programmer has to realize that, for example the OnCellEdit event will be
executed in a complete new run of the program. (not on fcgi/apache
module, but yuo get the idea)
Yes, this is what I meant.
I'm still thinking about adding an option to the apache-modules and fcgi
to let the TWebModule stay in memory, as some kind of session with a
timeout. That would add a lot of other possibilities.... (more
servlet-like)
I've thought about it, and a design as Remobjects uses would be good:
You'd need a global TWebmoduleFactory which is in charge of creating
the instances or picking them from an in-memory pool. Depending on the
application you can create descendents:
- TOnShotWebmoduleFactory (create& destroy a module per request)
- TPooledWebModuleFactory (have a pool of twebmodule instances and route the
request to one of them)
- TSessionWebmoduleFactory (same module throughout the session)
It would require a minor change to the TWebApplication object: it no longer
creates the webmodule directly, but asks the factory to create one.
Depending on which factory is used in the application, one of the above
systems is then used to return an instance.
Impressive, and another step on the road to something Intraweb-like.
What would be your proposed next steps ?
Ehm.... Show it to one of our customers and hope they bite. ;)
First I would add some more widgets. Therefor I need to add some
interfaces. Then I think I want to take a look at the persistent
web-modules...
See above :)
What helps when you have a project you want to work on. So you discover
what features you miss. Do you have an idea for something usefull?
Rework the contributed units section of the FPC website ? :-)
Michael.
--
_______________________________________________
Lazarus mailing list
[email protected]
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
