Kexi/Plugins/Web Forms: Difference between revisions

From KDE Community Wiki
< Kexi‎ | Plugins
m (Jstaniek moved page Kexi/Web Forms to Kexi/Plugins/Web Forms: hierarchy)
No edit summary
 
(2 intermediate revisions by the same user not shown)
Line 1: Line 1:
Volunteers needed!
== Web Forms ==
== Web Forms ==
=== Synopsis ===
=== Synopsis ===
Web Forms are 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.
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.
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.
Line 7: Line 9:
=== Use cases ===
=== Use cases ===
{{Note|Status: TODO}}
{{Note|Status: TODO}}
Unmaintained and not used code. '''Maintainer needed.'''
----
----


Line 42: Line 47:
=== Competitors ===
=== Competitors ===
* Zoho creator
* Zoho creator
** [http://creator.zoho.com/ Website]
** [http://creator.zoho.com/ Website], [https://api.creator.zoho.com API]
** [http://static.zohostatic.com/creator/v6/collateral/gettingstarted/index.html Presentation]
** [http://static.zohostatic.com/creator/v6/collateral/gettingstarted/index.html Presentation]
* Dabbledb
* Dabbledb
Line 52: Line 57:
* Give a look at SimpleCommandLineApp as suggested by Jaroslaw
* Give a look at SimpleCommandLineApp as suggested by Jaroslaw
* Latest working revision with old http backend
* Latest working revision with old http backend
<pre>
* Path: webforms (disabled for Kexi 2.x, and removed in Sep 2014 in Kexi 2.9).
Path: webforms
* Author: Lorenzo Villani <[email protected]>
URL: svn://anonsvn.kde.org/home/kde/trunk/koffice/kexi/webforms
* Year of development: 2008
Repository Root: svn://anonsvn.kde.org/home/kde
Repository UUID: 283d02a7-25f6-0310-bc7c-ecb5cbfe19da
Revision: 828892
Node Kind: directory
Last Changed Author: villani
Last Changed Rev: 827690
Last Changed Date: 2008-07-03 18:04:32 +0200 (Thu, 03 Jul 2008)
</pre>

Latest revision as of 10:59, 25 September 2014

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