MDE / Windows CE / WebFrameWork: Delphi Anwendung im Web / extpascal

[DSCHUCH]

Hy Leute,

ich suche gerade nach eine Möglichkeit eine einfache Logik auf undefinierte MDE geräte wie zB MDE-Geräte Bsp zu implementieren (im speziellen Auftragszeiterfassung).

Dabei haben wir diverse möglichkeiten diskutiert, von html5&DataSnap über Habari Webcomponenten, JQuery etc. Letzendlich müssen wir über das Formular nur einen Eintrag in eine Datenbank ermöglichen, mittels direkter verbindung, DataSnap oder what ever, hier sind alle Möglichkeiten offen.

Gerade bin ich aber nochmal über dieses Thread gestolpert: http://stackoverflow.com/questions/3...is-recommended , was natürlich sehr interessant ausschaut.

Mit diesen Komponenten kann man ja offensichtlich sein Delphi Prog direkt ins Web übertragen. Die Demos schauen sehr interessant aus:
http://www.unigui.com/demo
http://code.google.com/p/kitto/ => http://kitto.ethea.it/

Hat das bereits mal jemand produktiv eingesetzt? Ich habe noch nicht weiter geschaut/gelesen, aber vieleicht weiß es ja jemand: welche Vorraussetzung muß der Client/Browser mitbringen, damit das funktioniert?

Daniel.

[GHorn]

Hallo,

dieses Thema (Webanwendung) ist auch für mich gerade aktuell. Geplant ist eine kleine bis mittlere Anwendung mit Datenbankzugriff.

Die Kitto- und extpascal-Seiten sehen "verdächtig" :shock: ähnlich aus. Hat jemand Informationen zur Lizensierung bzw. deren Kosten. Die Rede ist bei beiden von den ext-js Komponenten. Diese sind kostenpflichtig. So richtig schlau bin ich nicht daraus geworden.

unigui scheint seit 2010 im Betastadium zu verharren.

Gruß
Gerald

[Lemmy]

Hi,

mit den genannten habe ich noch nichts am Hut gehabt, mir steht aber evlt. eine IntraWeb-Anwendung ins Haus die ich pflegen darf. Und auf den ersten Blick kann ich zu den UniGui Demos keinen Unterschied erkennen (keinen funktionalen) und Code sieht auch ziemlich ähnlich aus...

Oder gibts Gründe Intraweb nicht zu nehmen?

Grüße

[GHorn]

@Lemmi:
Das von mir genannte Programm habe ich bereits mit IntraWeb begonnen und es ist relativ weit fortgeschritten. Lediglich die DB-Anbindung fehlt noch (mache das privat so nebenbei). Mit IntraWeb Bordmitteln von D2009 sieht es etwas altbacken aus. Wie ein klassisches Windowsprogramm eben und nicht so internetspacig..

[Lemmy]

ja, der Style ist da sicher nicht der Bringer, wobei ich mich damit (noch) nicht befasst habe, die Technik steht aktuell noch im Vordergrund :-)

[Olli73]

Zitat:

Zitat von GHorn (Beitrag 1200539)

Die Kitto- und extpascal-Seiten sehen "verdächtig" :shock: ähnlich aus.

UniGui, Raudus, Kitty, ... nutzen alle den Weg "XYZ -> extPascal -> extJS". Daher sehen sie auch ähnlich aus.

Zitat:

Zitat von GHorn (Beitrag 1200539)

Hat jemand Informationen zur Lizensierung bzw. deren Kosten. Die Rede ist bei beiden von den ext-js Komponenten. Diese sind kostenpflichtig. So richtig schlau bin ich nicht daraus geworden.

Für kommerzielle Anwendungen braucht man in jedem Fall eine extJS-Lizenz (329 $ ?). UniGui soll insgesamt unter 1000 $ bleiben, genaue Preise sind noch nicht bekannt; die Beta kann aber so eingesetzt werden (wenn extJS-Lizenz vorhanden).

Zitat:

Zitat von GHorn (Beitrag 1200539)

unigui scheint seit 2010 im Betastadium zu verharren.

Stimmt. Wird aber aktiv weiterentwickelt, hat schon eine relativ große Community, Fehler werden i.d.R. schnell beseitigt und es wird von einigen bereits produktiv eingesetzt; nur die Roadmap für das erste release ist halt noch nicht komplett abgearbeitet, da die Umstellung auf extJS 4 (extPascal nutzt normalerweise 3.x) wohl etwas schwieriger war. (Edit sagt: ExtJS 4 ist aber jetzt wohl ein Vorteil gegenüber der Konkurrenz!?)

Ich nutze UniGui und bin sehr zufrieden damit, finde es auch wahnsinnig schnell im Vergleich zu manch anderen WebApps.

[GHorn]

Zitat:

Für kommerzielle Anwendungen braucht man in jedem Fall eine extJS-Lizenz (329 $ ?). UniGui soll insgesamt unter 1000 $ bleiben, genaue Preise sind noch nicht bekannt; die Beta kann aber so eingesetzt werden (wenn extJS-Lizenz vorhanden).

Das heißt also, dass man für <1000$ das Komplettpaket incl. extJS und allen anderen erforderlichen Komponenten bekommt? Das wäre sicher attraktiv.
Gibt es davon auch eine Testversion? Einen Bestell-Button oder ähnliches habe ich auf deren INet-Seite nicht gefunden (oder übersehen).

Gruß
Gerald

[mjustin]

Zitat:

Zitat von Olli73 (Beitrag 1200596)

Ich nutze UniGui und bin sehr zufrieden damit, finde es auch wahnsinnig schnell im Vergleich zu manch anderen WebApps.

Wie sieht es bei UniGui mit größerer Last aus (zum Beispiel wenn es mehrere hundert aktive Benutzer gibt), wurde das mal mit einer Simulation angetestet? Oder ist es ausdrücklich für kleinere bis mittlere Anforderungen ausgelegt?

[Olli73]

Zitat:

Zitat von GHorn (Beitrag 1200610)

Das heißt also, dass man für <1000$ das Komplettpaket incl. extJS und allen anderen erforderlichen Komponenten bekommt? Das wäre sicher attraktiv.

Ziel ist/war in jedem Fall insgesamt unter 1000$ zu bleiben. Dabei kann es sein, dass die Lizenz für ExtJs bei UniGui dabei sein wird oder getrennt gekauft werden muss.

Zitat:

Zitat von GHorn (Beitrag 1200610)

Gibt es davon auch eine Testversion? Einen Bestell-Button oder ähnliches habe ich auf deren INet-Seite nicht gefunden (oder übersehen).

Eine Testversion von UniGui gibt es im Forum. Der Link dorthin wurde entfernt, um den Zulauf für die Beta einzugrenzen. Lässt sich aber sicher finden ;)

[Olli73]

Zitat:

Zitat von mjustin (Beitrag 1200611)

Wie sieht es bei UniGui mit größerer Last aus (zum Beispiel wenn es mehrere hundert aktive Benutzer gibt), wurde das mal mit einer Simulation angetestet? Oder ist es ausdrücklich für kleinere bis mittlere Anforderungen ausgelegt?

Dazu habe ich (noch) keine praktischen Erfahrungen. Theoretisch sieht es so aus, dass jeder Benutzer (jede Session) einen eigenen Thread hat, sich Sessions also nicht gegenseitig blockieren, was schon mal gut ist. Das "Besondere" ist aber, dass es eben nicht "stateless" ist, wie z.B. PHP, und deshalb dauerhaft Speicher pro aktiver Session belegt. Da kommt es dann auf die Programmierung an, so habe ich z.B. schon einen durchschnittlichen Verbrauch pro Session von ca. 4 MB auf ca. 300 KB reduzieren können...

[Furtbichler]

Ich habe eine Billiganwendung VT-100 geschrieben und auf dem Symbol (MDE) eine Terminalemulater installiert. Sehr einfach, sehr billig. Läuft. Also eigentlich hatte ich das VT-100 Teil schon vorher und keine Lust, etwas auf dem MDE umzusetzen (keine Ahnung gehabt, damals).

Danach habe ich eine kleine ASP.NET Anwendung für das Teil geschrieben und auf dem Symbol den Browser gestartet. Genausogut, allerdings musste ich eine mini C#-Anwendung schreiben, die aus nichts anderem als dem Browser bestand, weil.. ich glaube, damit sich die Verbindung immer wieder neu aufgebaut wird, wenn es mal mit der VErbindung nicht klappte und der Browser sonst ne Meldung ausgespuckt hätte.

Und das war zu einem Zeitpunkt, als ich auch noch exklusiv und nur Delphi-Anwendungen gemacht habe.

Eine dritter Versuch bestand aus einem selbstgeschriebenen TCP-Server in Delphi, einem blöden Übertragungsprotokoll und ein paar Screens/Formularen in C# für WinCE. Das Protokoll bestand eigentlich nur darin, die Screens zu aktivieren und zu parametrieren und dann die Eingaben der Screens wieder zurückzuschicken. So konnte ich einen einfachen Dialog dynamisch zusammenstellen.

Das hatte mich jeweils maximal ne Woche gekostet.

Was ich damit sagen will: Nehmt einfach das naheliegende, traut euch an C# ran. Alles ist einfacher, als umständlich Pascal auf so einem Teil zum Laufen zu kriegen. Denke ich.

[dunningkruger]

Zitat:

Zitat von Furtbichler (Beitrag 1200644)

Ich habe eine Billiganwendung VT-100 geschrieben und auf dem Symbol (MDE) eine Terminalemulater installiert. Sehr einfach, sehr billig. Läuft. Also eigentlich hatte ich das VT-100 Teil schon vorher und keine Lust, etwas auf dem MDE umzusetzen (keine Ahnung gehabt, damals).

Danach habe ich eine kleine ASP.NET Anwendung für das Teil geschrieben und auf dem Symbol den Browser gestartet. Genausogut, allerdings musste ich eine mini C#-Anwendung schreiben, die aus nichts anderem als dem Browser bestand, weil.. ich glaube, damit sich die Verbindung immer wieder neu aufgebaut wird, wenn es mal mit der VErbindung nicht klappte und der Browser sonst ne Meldung ausgespuckt hätte.

Und das war zu einem Zeitpunkt, als ich auch noch exklusiv und nur Delphi-Anwendungen gemacht habe.

Eine dritter Versuch bestand aus einem selbstgeschriebenen TCP-Server in Delphi, einem blöden Übertragungsprotokoll und ein paar Screens/Formularen in C# für WinCE. Das Protokoll bestand eigentlich nur darin, die Screens zu aktivieren und zu parametrieren und dann die Eingaben der Screens wieder zurückzuschicken. So konnte ich einen einfachen Dialog dynamisch zusammenstellen.

Das hatte mich jeweils maximal ne Woche gekostet.

Was ich damit sagen will: Nehmt einfach das naheliegende, traut euch an C# ran. Alles ist einfacher, als umständlich Pascal auf so einem Teil zum Laufen zu kriegen. Denke ich.

Lobpreiset dem Herrn Furtbichler, denn seine Gnade überschüttet uns mit Informationen über des Herren SagIchNichtWeilIchTollBin.

Vielen Dank mit Fu0kuss/Käsesockenlutschen!

:twisted: :pale:

[DSCHUCH]

ich sag mal - no comment... ^^
ich habe mir jetzt nochmal 2 stunden intraweb angeschaut und bissl rumgetestet, für einfach click bum websites, so wie wir es eigentlich brauchen (der anwender soll nur 2 knöpfe haben - der rest ergibt sich aus dem ablaufplan und sonstiger logik) scheint intraweb ausreichend zu sein, funktioniert auch ganz gut : einfache tabellen, edit, loginform.

schönes bsp-video gibt es hier auch:
http://www.youtube.com/watch?v=Tg_J3huoazE

elegant finde ich gerade

* Weiterverwendung deer Buisinesslogik, alles nichtvisuelle kann einfach eingebunden werden.
* Auslieferung einer einfachen Exe, welche selbst den Webserver integriert, damit muß eigentlich garnichts im netzwerk gemacht werden, ausser die firewall einrichten.

[DSCHUCH]

und hier habe ich gerade noch ein video gefunden, was man machen muß damit das ganze nicht ausschaut, wie ein "müllhaufen". hier wird das jquery layout für mobile mit vcl for the web kombiniert.
http://www.youtube.com/watch?v=75DnldrcJNU

[Furtbichler]

Zitat:

Zitat von dunningkruger (Beitrag 1200646)

Lobpreiset dem Herrn Furtbichler, denn seine Gnade überschüttet uns mit Informationen über des Herren SagIchNichtWeilIchTollBin.

Vielen Dank mit Fu0kuss/Käsesockenlutschen!

:twisted: :pale:

Suchst Du Anschluß? Oder bist Du nur neidisch?

Was ich damit ausdrücken wollte, das es viele Möglichkeiten gibt und das die Möglichkeiten, die ich aufgezählt habe, funktionieren. Wenn ich protzen wollen würde, dann bestimmt nicht mit diesen teilweise doch sehr hemdsärmeligen Lösungen von mir.

Ist die Hardware geeignet, HTML5/JQuery Apps auszuführen?

[DSCHUCH]

Zitat:

Zitat von Furtbichler (Beitrag 1200690)

Ist die Hardware geeignet, HTML5/JQuery Apps auszuführen?

das müssen wir testen. ob man das nun mit jquery umsetzt, sei jetzt einmal dahingestellt, es war aber ein bsp-video wie das sonst vom design her müllisch aussehende VCL For the Web modern ausschaut.

letztendlich können wir unseren Kunden die Hardware vorschreiben (bzw. die Anforderungen), insb. da die Software mit diesen Methoden nur ein bruchteil kostet. Welche MDE da jetzt geeignet sind werden wir testen müssen.

Hast Du schonmal MDE Entwicklung betrieben? Durch die millionen Geräte Varianten kommt für uns nur eine Lösung in Frage, welche absolut plattformunabhängig ist. Das ist von uns immer eine Speziallösung, die vielleicht 20 mal pro Jahr installiert wird. Beim nächsten Setup gibt es evtl bereits wieder neue Geräte oder der Ablauf beim Kunden ist anders, so dass sowieso alles angepasst werden muß. idR haben unsere Kunden zwar große Netzwerke, aber wiederrum keinen der sowas gern Administriert, bzw wir sind es nicht, daher ist webserver aufsetzen auch wieder so ein Ding (es geht was im Firmennetzwerk nicht => das liegt an der neuen Software, die haben etwas auf dem Server installiert.... blabla, kennt sicher jeder). Alles Gründe die für die VCL Lösung sprechen.



by side....
In der Vergangenheit konnten wir uns schon mit IT-Abteilungen rumärgern, die behauptet haben das unsere SQL Datenbanken Festplatten kaputt gemacht haben. (es gab ein RAID-Systemabsturz (Hardware) nachdem wir unsere Datenbanken installiert hatten, vermutlich ein deffekt der durch die hohe Belastung des Installationsvorgangs dann durchgeschlagen hat, kühlung, what ever)

[Furtbichler]

Zitat:

Zitat von DSCHUCH (Beitrag 1200758)

Hast Du schonmal MDE Entwicklung betrieben? Durch die millionen Geräte Varianten kommt für uns nur eine Lösung in Frage, welche absolut plattformunabhängig ist.

Die beiden Ansätze 'VT-100' (weil 0 Anpassung) und 'Browser-App' (=ASP.NET) sind ziemlich plattformunabhängig, also: Ja.

Der 3.Ansatz (proprietär) ist bezüglich Win CE (Compact Framework) allgemeingültig, aber eben nicht vollkommen plattformunabhängig.

Falls Du mit 'plattformunabhängig' iOS/Android/Windows meinst => vergiss es bzw. plane, wie bei normaler Webentwicklung endlose Spezialfallbehandlungen ein.

Mein IOS-Guru meint, das er zwar schon akzeptable HTML5-Anwendung für iPad gesehen hat, aber die ruckelten immer noch ein wenig, ergo würde er immer noch native iPad-Apps entwickeln. In 2-3 Jahren gehts vielleicht auch mal mit Delphi, aber bis dahin => Objective C.

Im Industriesektor hat sich imho Window eh )noch) durchgesetzt. Hier würde ich mir zudem einen Anbieter aussuchen (Symbol ist eine gute Wahl) und die Sonderlocken dieses Anbieters auch ausnutzen. Beispielsweise ist es nicht trivial, den Scanner in einer Web-App normal zu benutzen. Hier hat Symbol eine Speziallösung.

Und wenn Du seriös bleiben willst, dann unterstütze nicht jedes x-beliebige Gerät, denn das bedeutet, das Du den Kunden mit seinen gerätespezifischen Problemen alleine lässt. Und das ist einfach nicht gut.

[mjustin]

[QUOTE=DSCHUCH;1200758]

Zitat:

Zitat von Furtbichler (Beitrag 1200690)

Hast Du schonmal MDE Entwicklung betrieben? Durch die millionen Geräte Varianten kommt für uns nur eine Lösung in Frage, welche absolut plattformunabhängig ist.

Plattformunabhängigkeit ist aber mitunter auch ein Problem, wenn es um die Ansteuerung von gerätespezifischen Schnittstellen geht.

Eine auf Telnet-basierende Client-Anwendung auf dem MDE kann man zwar zum Beispiel einen Barcodescan auslösen, dessen Ergebnis in einem Eingabefeld eingetragen und zum Server gesendet wird.

Aber wenn das Gerät darüber hinaus weitere Hardware hat, ist schon "Ende Gelände" mit der Plattformunabhängigkeit, wenn man sie nicht aus der Telnetsitzung ansprechen kann.

Beispiel: es gibt MDEs mit eingebauter Kamera. Diese kann über zum Beispiel eine API (Windows Mobile) angesprochen werden, doch dazu muss Software zum Beispiel in C# geschrieben werden die lokal läuft. Weder aus dem Telnetclient noch über eine Weboberfläche kann man dann "plattformunabhängig" arbeiten. Benutzer müssen dann tatsächlich zwei Anwendungen auf dem MDE gleichzeitig verwenden, was natürlich eine grauenvolle Lösung ist (Aus Telnetsitzung in C# App wechseln, damit Foto machen und an Server senden, zurück in Telnet Sitzung...).

[Furtbichler]

Ich habe stets den Weg des kleinsten Widerstands bzw. geringsten Auffands gewählt. 2D-Barcodes gehen mit dieser Telnet-Frickelei z.B. nicht mehr.

Wie ich bereits ausführte, habe ich nur gezeigt, das viele Wege nach Rom führen. Darunter waren auch Feldwege.

[QuickAndDirty]

Morfik wäre das spacige internettige was gesucht wird?