Ich habe ein zusätzliches Includescript gebaut, um die Kompatibilität mit
SQLite3 herzustellen.
Es handelt sich dabei um 4 wrapper-Funktionen, in denen die sqlite3-Funktionen
in sqlite2 "eingepackt" werden.
Allerdings muss das olclient.php so verändert werden, dass bei Fehlen von
Module sqlite und Vorhandensein von Modul sqlite3 auch das Includescript mit
eingebaut wird.
Da ich das das openlawyer innerhalb eines Apache verwende, der auch noch
andere Web-Applikationen anbietet, konnte ich nicht die DocRoot auf das
openlawyers/www setzen. Statt dessen kabe ich in allen .gui und css Dateien
die Referenz von "/www/skin" auf "./www/skin" (führender Punkt) geändert,
womit der relative Pfad zur richtigen Stelle führt.
Das Wrapper-Skript ist recht kurz und sieht so aus:
{sql3wrapper.php}
{
<?php
function sqlite_open($location,$mode)
{
$handle = new SQLite3($location);
return $handle;
}
function sqlite_query($dbhandle,$query)
{
$array = $dbhandle;
$array = $query;
$result = $dbhandle->query($query);
return $result;
}
function sqlite_fetch_array(&$result,$type)
{
wow, super, vielen Dank für dein Engagement ! Ich werde es bei passender
Gelegenheit bei OL einbauen. Leider bin ich im Moment zeitlich anderweitig
beansprucht, so dass es etwas dauern kann. Parallel bin ich im Übrigen dabei,
OL komplett zu redesignen (in den News bereits angekündigt) und dann als OL 2
zur Verfügung zu stellen.
Da du hier der erste bekennende developer bist, weihe ich dich kurz in meine
Pläne ein ;-): Im Gegensatz zu OL1 wird es als "echte" Applikation angelegt
sein. Bisher habe ich noch über die Entwicklungsumgebung gehardert, ob in
C/C++ als nativen code oder doch lieber mit einer populären Skriptsprache. Da
OL aber weiter so plattformunabhängig wie möglich sein soll, habe ich mich
gegen den Aufwand mit C/C++ entschieden und werde es entspannt mit Python +
wxWidgets entwickeln. Es wird sowohl als serverlose Version mit SQLite und
(ggf. - für die Mehrplatzbenutzer - verteilten) Dateisystemen laufen als auch
als mit MySQL als Backend, wobei ich die Dateien nicht in der Datenbank
unterbringe sondern via SFTP in die Cloud verschiebe :-) .. auf jeden Fall
wird es abwärtskompatibel werden hinsichtlich der Datenstrukturen und
Verzeichnisstruktur um minimalen Umstellungsaufwand zu verursachen ..
Falls Du dazu Anmerkungen, Empfehlungen oder Alternativen hast, freue ich mich
auf Anregungen ..
Grüße
LastCoder
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Erstmal muss ich mich entschuldigen, weil mir in dem zitierten Text ein
typischer copy-paste-Fehler unterlaufen ist.
Die Funktion sqlite_fetch_array() ist für den OL völlig irrelevant, und das
Durchhecheln der columns ist in die sqlite_array_query() versehentlich
hineingekommen.
Das erzeugt zwar keinen Fehler, ist aber völlig unnötig und verbraucht Zeit.
Die richtige Funktion sieht so aus:
Die SQLite3-Kompatibilität ist notwendig, weil in der jüngsten PHP-version das
alte SQLite2-Modul komplett rausgeflogen ist.
Anstelle dessen sollte vielleicht zukünftig doch gleich der PDO:: -Teil für
die Datenbanken genutzt werden. Dann hast Du aus dem Stand eine ansehnliche
Menge Datenbanken im Portfolio ...
Wenn Du willst, will ich das gern mal versuchen.
Dass Du eine "native" Anwendung aus OL machen willst, finde ich schade, weil
gerade im Zeitalter von Smartphones und Tablets die Web-basierten Anwendungen
immer mehr Bedeutung gewinnen. Die Motivation, auch eine "simple"
Lokalinstallation für Nutzer ohne entsprechende Kenntnisse zur Verfügung zu
haben, erkenne ich ja auch, aber Du verbaust Dir dadurch eine Menge
Flexibilität.
So musst Du z.B. für die Nutzung eines separaten Servers gleich zwei
Protokolle -das der Datenbank und das ssh-Protokoll etablieren, und das ist
bei Windows-Clients immer mit zusätzlicher Software verbunden. Einen Webserver
kannst Du gleich beibringen, dass er nur über SSL und damit verschlüsselt
arbeitet und bist die Übertragungs-Probleme los.
Wenn es aber denn sein soll, so hast Du mit Python und wxwidges sicherlich
eine flexible und stabile Entwicklungsplattform gewählt, die sicherlich auch
längere Zeit gepflegt und unsterstützt wird. Da ich grundsätzlich nur mit
Linux/UNIX arbeite, finde ich das natürlich prima ;-)
Die einzige Alternative mit gleicher Zielsetzung wäre sicherlich Java, aber
das ist wieder eine ganz andere Welt. Allerdings finde ich den Ansatz von
XDEV3 schon recht brauchbar.
Die Geschichte mit der "Cloud" ist sicherlich scherzhaft gemeint, oder? Ich
würde es jedenfalls nicht lustig finden, meine Schreiben auf einem
Amerikanischen Server wiederzufinden, auf den zumindest die internen Behörden
jederzeit Zugriff hätten. Also: Lass die Dokumente dort, wo auch die Datenbank
liegt, also entweder auf dem lokalen Rechner, oder auf den Server, der auch
die Datenbank beherbergt; dann wird' auch mit der Datensicherung einfacher.
So. Meine Tastatur glüht schon. ich hör' jetzt mal auf.
Viele Grüße
Burkhard
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
hm .. das hast du Recht .. derzeit stört mich weniger die Funktionalität. Nachdem es nun tatächlich Nutzer meiner Software gibt, bin ich auch motiviert, diese weiterzuentwickeln. Derzeit gibt es aber Hemmschuhe für eine Weiterentwicklung. Konkret stört mich:
die GUI ist eine "Selbstentwicklung", die anzupassen zuviel Zeit in Anspruch nimmt (als ich 2005 angefangen habe, war die Welt von AJAX und UI Frameworks noch sehr viel kleiner als heute, sonst hätte ich wohl schon damals auf so ein Framework zugegriffen)
PHP ist nicht mehr meine Wahl, ist inzwischen von Python abgelöst
WebServereinrichtung ist für viele einfach ein zu großer Krampf.
Das Ziel: Plattformunabhängig zu bleiben, abwärtskompatibel, bessere und zukunftsfähige, mehrsprachiges UI, möglichst keinen separaten - i.S. eines zusätzlichen Produktes - Server einrichten müssen, da damit die Abhängigkeiten, die Komplexität und Fehleranfälligkeit wächst.
Daher zunächst die Idee mit einer "nativen" App. Allerdings sehe ich die von dir benannten Vorteile der aktuellen Lösung.
Ich habe mir überlegt, um diese Vorteile beizubehalten und gleichzeitig die Komplexität durch Abhängigkeiten aufzulösen, das Projekt auf einen
a. Python-JSON-RPC Server mit SQLite als DB als Backend aufzulösen und
b. das UI durch ein Javascript/AJAX Framework wie qooxdoo clientseitig zu realisieren.
Damit einfällt ein Drittprodukt als Server, man bleibt durch Python und JS aber flexibel und plattformunabhängig und kann das Produkt sowohl als client-server app wie auch als standalone app ohne Unterschiede nutzen. Und der Einsatz eines Frameworks wie qooxdoo gibt die nötige moderne Flexibilität des UI, wie man es von einer "nativen" Desktop-App erwartet ..
Hast du Empfehlungen für ein Framework ? Ich klappere gerade Vor- und Nachteile von qooxdoo, ExtJS, Dojo/Dijit, jquery UI ..
Grüße
LCS
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2013-04-18
Hallo,
wie genau wird der Wrapper denn in OL eingebaut?
Vielen Dank für die Infos und beste Grüße
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hallo lastcoder!
Ich habe ein zusätzliches Includescript gebaut, um die Kompatibilität mit
SQLite3 herzustellen.
Es handelt sich dabei um 4 wrapper-Funktionen, in denen die sqlite3-Funktionen
in sqlite2 "eingepackt" werden.
Allerdings muss das olclient.php so verändert werden, dass bei Fehlen von
Module sqlite und Vorhandensein von Modul sqlite3 auch das Includescript mit
eingebaut wird.
Da ich das das openlawyer innerhalb eines Apache verwende, der auch noch
andere Web-Applikationen anbietet, konnte ich nicht die DocRoot auf das
openlawyers/www setzen. Statt dessen kabe ich in allen .gui und css Dateien
die Referenz von "/www/skin" auf "./www/skin" (führender Punkt) geändert,
womit der relative Pfad zur richtigen Stelle führt.
Das Wrapper-Skript ist recht kurz und sieht so aus:
Get Columns
$i = 0;
while ($result->columnName($i))
{
$columns = $result->columnName($i);
$i++;
}
$resx = $result->fetchArray(SQLITE3_ASSOC);
return $resx;
}
function sqlite_array_query($dbhandle,$query)
{
$array = $dbhandle;
$array = $query;
$result = $dbhandle->query($query);
$i = 0;
while ($result->columnName($i))
{
$columns = $result->columnName($i);
$i++;
}
$resx = array();
while($res = $result->fetchArray(SQLITE3_ASSOC)){
$resx = $res;
}
// $resx = $result->fetchArray(SQLITE3_ASSOC);
return $resx;
}
function sqlite_last_error($dbhandle)
{
return $dbhandle->lastErrorCode();
}
function sqlite_error_string($error)
{
return "Error: ". $error;
}
function sqlite_close($dbhandle)
{
$dbhandle->close();
$aErgebnis = $dbhandle->lastErrorMsg();
unset($dbhandle);
return $aErgebnis;
}
?>
}
Viele Grüße
obergoeker
Hi,
wow, super, vielen Dank für dein Engagement ! Ich werde es bei passender
Gelegenheit bei OL einbauen. Leider bin ich im Moment zeitlich anderweitig
beansprucht, so dass es etwas dauern kann. Parallel bin ich im Übrigen dabei,
OL komplett zu redesignen (in den News bereits angekündigt) und dann als OL 2
zur Verfügung zu stellen.
Da du hier der erste bekennende developer bist, weihe ich dich kurz in meine
Pläne ein ;-): Im Gegensatz zu OL1 wird es als "echte" Applikation angelegt
sein. Bisher habe ich noch über die Entwicklungsumgebung gehardert, ob in
C/C++ als nativen code oder doch lieber mit einer populären Skriptsprache. Da
OL aber weiter so plattformunabhängig wie möglich sein soll, habe ich mich
gegen den Aufwand mit C/C++ entschieden und werde es entspannt mit Python +
wxWidgets entwickeln. Es wird sowohl als serverlose Version mit SQLite und
(ggf. - für die Mehrplatzbenutzer - verteilten) Dateisystemen laufen als auch
als mit MySQL als Backend, wobei ich die Dateien nicht in der Datenbank
unterbringe sondern via SFTP in die Cloud verschiebe :-) .. auf jeden Fall
wird es abwärtskompatibel werden hinsichtlich der Datenstrukturen und
Verzeichnisstruktur um minimalen Umstellungsaufwand zu verursachen ..
Falls Du dazu Anmerkungen, Empfehlungen oder Alternativen hast, freue ich mich
auf Anregungen ..
Grüße
LastCoder
Hallo!
Erstmal muss ich mich entschuldigen, weil mir in dem zitierten Text ein
typischer copy-paste-Fehler unterlaufen ist.
Die Funktion sqlite_fetch_array() ist für den OL völlig irrelevant, und das
Durchhecheln der columns ist in die sqlite_array_query() versehentlich
hineingekommen.
Das erzeugt zwar keinen Fehler, ist aber völlig unnötig und verbraucht Zeit.
Die richtige Funktion sieht so aus:
$resx = array();
while($res = $result->fetchArray(SQLITE3_ASSOC)){
$resx = $res;
}
// $resx = $result->fetchArray(SQLITE3_ASSOC);
return $resx;
}
Die SQLite3-Kompatibilität ist notwendig, weil in der jüngsten PHP-version das
alte SQLite2-Modul komplett rausgeflogen ist.
Anstelle dessen sollte vielleicht zukünftig doch gleich der PDO:: -Teil für
die Datenbanken genutzt werden. Dann hast Du aus dem Stand eine ansehnliche
Menge Datenbanken im Portfolio ...
Wenn Du willst, will ich das gern mal versuchen.
Dass Du eine "native" Anwendung aus OL machen willst, finde ich schade, weil
gerade im Zeitalter von Smartphones und Tablets die Web-basierten Anwendungen
immer mehr Bedeutung gewinnen. Die Motivation, auch eine "simple"
Lokalinstallation für Nutzer ohne entsprechende Kenntnisse zur Verfügung zu
haben, erkenne ich ja auch, aber Du verbaust Dir dadurch eine Menge
Flexibilität.
So musst Du z.B. für die Nutzung eines separaten Servers gleich zwei
Protokolle -das der Datenbank und das ssh-Protokoll etablieren, und das ist
bei Windows-Clients immer mit zusätzlicher Software verbunden. Einen Webserver
kannst Du gleich beibringen, dass er nur über SSL und damit verschlüsselt
arbeitet und bist die Übertragungs-Probleme los.
Wenn es aber denn sein soll, so hast Du mit Python und wxwidges sicherlich
eine flexible und stabile Entwicklungsplattform gewählt, die sicherlich auch
längere Zeit gepflegt und unsterstützt wird. Da ich grundsätzlich nur mit
Linux/UNIX arbeite, finde ich das natürlich prima ;-)
Die einzige Alternative mit gleicher Zielsetzung wäre sicherlich Java, aber
das ist wieder eine ganz andere Welt. Allerdings finde ich den Ansatz von
XDEV3 schon recht brauchbar.
Die Geschichte mit der "Cloud" ist sicherlich scherzhaft gemeint, oder? Ich
würde es jedenfalls nicht lustig finden, meine Schreiben auf einem
Amerikanischen Server wiederzufinden, auf den zumindest die internen Behörden
jederzeit Zugriff hätten. Also: Lass die Dokumente dort, wo auch die Datenbank
liegt, also entweder auf dem lokalen Rechner, oder auf den Server, der auch
die Datenbank beherbergt; dann wird' auch mit der Datensicherung einfacher.
So. Meine Tastatur glüht schon. ich hör' jetzt mal auf.
Viele Grüße
Burkhard
Hallo Burkhard,
hm .. das hast du Recht .. derzeit stört mich weniger die Funktionalität. Nachdem es nun tatächlich Nutzer meiner Software gibt, bin ich auch motiviert, diese weiterzuentwickeln. Derzeit gibt es aber Hemmschuhe für eine Weiterentwicklung. Konkret stört mich:
Das Ziel: Plattformunabhängig zu bleiben, abwärtskompatibel, bessere und zukunftsfähige, mehrsprachiges UI, möglichst keinen separaten - i.S. eines zusätzlichen Produktes - Server einrichten müssen, da damit die Abhängigkeiten, die Komplexität und Fehleranfälligkeit wächst.
Daher zunächst die Idee mit einer "nativen" App. Allerdings sehe ich die von dir benannten Vorteile der aktuellen Lösung.
Ich habe mir überlegt, um diese Vorteile beizubehalten und gleichzeitig die Komplexität durch Abhängigkeiten aufzulösen, das Projekt auf einen
a. Python-JSON-RPC Server mit SQLite als DB als Backend aufzulösen und
b. das UI durch ein Javascript/AJAX Framework wie qooxdoo clientseitig zu realisieren.
Damit einfällt ein Drittprodukt als Server, man bleibt durch Python und JS aber flexibel und plattformunabhängig und kann das Produkt sowohl als client-server app wie auch als standalone app ohne Unterschiede nutzen. Und der Einsatz eines Frameworks wie qooxdoo gibt die nötige moderne Flexibilität des UI, wie man es von einer "nativen" Desktop-App erwartet ..
Hast du Empfehlungen für ein Framework ? Ich klappere gerade Vor- und Nachteile von qooxdoo, ExtJS, Dojo/Dijit, jquery UI ..
Grüße
LCS
Hallo,
wie genau wird der Wrapper denn in OL eingebaut?
Vielen Dank für die Infos und beste Grüße