Kexi/Plugins/Web Forms

From KDE Community Wiki
< Kexi‎ | Plugins
Revision as of 10:59, 25 September 2014 by Jstaniek (talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

Volunteers needed!

Web Forms

Synopsis

Web Forms is a technology which can be found even in other leading applications (such as Microsoft Access) but it's encumbered by the use of proprietary or non-standard technologies thus avoiding any usage outside the original platform.

Kexi Web Forms implementation will be kept as simple as possible and adhere to W3C standards in a way that any user with a WWW browser (even text-based ones such as link, lynx, w3m) will be able to manipulate records with ease, even if they don't have Kexi installed.

Use cases

Note

Status: TODO


Unmaintained and not used code. Maintainer needed.


Implementation details

HTTP Server component

The actual implementation uses pion-net-library, for older implementation see 'Notes' below, for more informations about pion-net see the 'Links' section below.

Configuration files

I'd like to avoid configuration files as much as possible. Kexi Web Forms Daemon should avoid any on-the-fly configuration file generation. Maybe some configuration data can just be integrated inside the .kexi file (need to discuss about this with Jaroslaw).

Data access

Data access is done through KexiDB2 library

Forms conversion

Doing a GUI -> Web form conversion can be quite difficult, that's why, at the very beginning development stages I'll focus on generating Web forms on the fly by querying the database through KexiDB2 library. Using configuration data (stored in configuration or .kexi file) the user will be able to choose which fields to hide.

Why not use lighttpd instead?

First of all, I wanted to use, for my first implementation, a web server designed to be embeddable inside an application, that's why I chose SHTTPD. SHTTPD has a clean, simple API and some interesting add-ons (like HTTPS, CGI, SSI support) while remaining, in fact, quite simple. Lighttpd, instead, is mainly designed to be a standalone web server. With this initial release I wanted to avoid code-generation and have a tight integration with web server' core. I didn't want to write a server module and instead provide a small executable with shttpd statically linked in it. Of course during next months some apache and lighttpd modules would certainly pop-out as soon as I stabilize the core of the web forms exporter.

Links

Network libraries

Useful/interesting stuff

AJAX Toolkits

Competitors

Notes