PureBoard

Verfasst: **27.04.2019 14:08**

Achso

Ich dachte "jetzt bitte noch xx hinzufügen", ja das habe ich falsch verstanden.

TroaX hat geschrieben:Jetzt wird für mich PB langsam wieder richtig interessant

Das freut mich.

Bezüglich des Webservers: Ich kann es mir später auch mal anschauen.

Verfasst: **27.04.2019 14:19**

TroaX hat geschrieben:Endlich komme ich zum Ende mit Electron ... Ich hasse Electron und das ganze Node-Rumgespiele. Ich habe deswegen mittlerweile 6 oder 7 Nodeinstanzen drauf. Jetzt wird für mich PB langsam wieder richtig interessant

+1

@Ray: Sehr schön! Vielen Dank dafür!

Was mir aufgefallen ist:

Wenn ich eine JS-Funktion aufrufe, die wiederum einen Alert anzeigt, dann friert das Programm ein.

Code: Alles auswählen

<script>

  function test1() { // funktioniert
    document.body.style.backgroundColor = "#ff0000";
  }

  function test2() { // Programm friert ein
    alert("test2");
  }

</script>

Code: Alles auswählen

ExecuteWebGadgetExJavaScript(#WebGadgetEx, "test1();", @Output$, @ErrorOutput$) ; funktioniert
ExecuteWebGadgetExJavaScript(#WebGadgetEx, "test2();", @Output$, @ErrorOutput$) ; Programm friert ein

Und einen Feature Request hätte ich gleich auch noch: GetWebGadgetExAttribute(..., #PB_Web_Busy)

(Damit man weiß, wann die Seite komplett geladen wurde.)

Und das mit dem (eingebauten) WebServer wäre natürlich das Sahnehäubchen (obwohl es nicht kompliziert wäre, es selber zu implementieren).

Grüße ... Peter

Verfasst: **27.04.2019 14:36**

Kiffi hat geschrieben:Was mir aufgefallen ist:

Wenn ich eine JS-Funktion aufrufe, die wiederum einen Alert anzeigt, dann friert das Programm ein.

Stimmt. Es liegt an EvaluateScriptAsync(). Wenn man stattdessen mit ExecuteJavaScriptAsync() (ohne Auswertung des Rückgabewertes) ausführt, dann klappt es.
Ich werde das so anpassen, dass man 0 an den Parameter "Output" übergeben kann, dann wird stattdessen die andere Methode ausgeführt, die bei modalen Dialogen besser funktioniert.

Kiffi hat geschrieben:Und einen Feature Request hätte ich gleich auch noch: GetWebGadgetExAttribute(..., #PB_Web_Busy)

Werde ich hinzufügen.

Verfasst: **27.04.2019 15:58**

PB.Ex WebGadget 1.0.5.0 wurde veröffentlicht.

Changelog:

Hinzugefügt: GetWebGadgetExAttribute(): Mit #PB_Web_Busy kann überprüft werden, ob die Seite noch lädt.
Bugfix: ExecuteWebGadgetExJavaScript()

Verfasst: **27.04.2019 19:50**

Kiffi hat geschrieben:Und das mit dem (eingebauten) WebServer wäre natürlich das Sahnehäubchen (obwohl es nicht kompliziert wäre, es selber zu implementieren).

Das kommt immer darauf an, wie weit man es treiben möchte. Um einen umfangreichen Dienst zu basteln, ist das schon ein starkes Stück. Alle wichtigen Methoden, das Verhalten, die Statuscodes samt Checks. Das ist schon ne Hausnummer

Verfasst: **27.04.2019 20:00**

TroaX hat geschrieben:Das kommt immer darauf an, wie weit man es treiben möchte.

ein kleiner WebServer, für statische Seiten würde (mir) vollkommen ausreichen.

Grüße ... Peter

Verfasst: **27.04.2019 20:14**

@Kiffi
Wie sieht es mit dem mitgelieferten Atomic Web Server von PB aus? Reicht der nicht aus oder gibt es damit Nachteile?
Und was für Seiten sollen aufrufbar sein? HTML, PHP, ASP oder/und ASP.NET?

Verfasst: **27.04.2019 21:14**

Kiffi hat geschrieben:
TroaX hat geschrieben:Das kommt immer darauf an, wie weit man es treiben möchte.
ein kleiner WebServer, für statische Seiten würde (mir) vollkommen ausreichen.

Naja er sollte schon auch als Schnittstelle zwischen Frontend und Backend dienen z.B. das bei Absenden eines Formulars die Daten auch an eine Purebasic-Prozedur gehen. Dadurch lassen sich Javascript-Bibliotheken verwenden, die fest in Richtung Ajax/asynchrone HTTP-Request konzipiert wurden. Für reines Ausliefern reicht der Atomic. Aber um wirklich umfangreich alles nutzen zu können, sollte man hinter eine URL auch eine Purebasic-Prozedur packen können

Websockets funktionieren mit der Network-Lib problemlos. Und das man per Javascript eine Purebasic-Prozedur aufrufen kann, ist genial. Aber um auch Ajax oder auf die schnelle klassische Formulare zu verwenden, wäre der integrierte Server spitzenklasse. Da würde wirklich alles möglich sein.

EDIT: Ich habe ja mal einen Ansatz mit der CGI/FastCGI Funktionalität gebastelt. Vielleicht erinnert sich wer noch dran: https://github.com/reVerBxTc/PBExpress
Damit konnte man einer URL eine Purebasic-Prozedur zuweisen und darin z.B. Formulare verarbeiten.

Verfasst: **27.04.2019 22:23**

Wir haben doch bereits: PB -> JS und JS -> PB.

Mehr brauchen wir doch gar nicht. Kein ASP(X), PHP, CGI und Gedönse.

Und damit das JS uneingeschränkt funktioniert, wirds über einen einfachen WebServer (meinetwegen dem Atomic) ausgeliefert. Fertig ist die Laube!

Grüße ... Peter

Verfasst: **28.04.2019 10:07**

Ich glaube du verstehst nicht so ganz, worum es geht.

Es gibt Javascript-Bibliotheken, die z.B. asynchron Daten an den Webserver senden. Die machen sie in der Regel mit asynchronen HTTP-Requests. Der Atomic-Webserver ist dafür nur extrem rudimentär. Er prüft nur die URL und liefert die angeforderte Ressource aus. Er ignoriert völlig den Request-Body. Allerdings senden genau in diesem die Ajax-Requests ihre Daten mit.

Ein Beispiel: Ich möchte TinyMCE als Rich-Text Editor verwenden. Dieser besitzt eine integrierte Autosave-Funtion. Die sendet in regelmäßigen Abständen den Text an den Server, wo er zwischengespeichert wird. Um den Inhalt mit dem Cef an PB zu senden, müsste ich nun diese Autosave-Funktion umschreiben, den JS-Code neu packen und komprimieren. Mit einem Embedded-Server hingegen muss ich nur die Autosave-Funktion auf eine URL konfigurieren und in PB die Daten in einer Prozedur verarbeiten. Genau dadurch ist ja Electron so groß geworden. Es stehen einem alle erdenklichen Interfaces zur Kommunikation zwischen Frontend und Backend zur Verfügung.

Die Kommunikation über den Node-Webserver ist der Grundbaustein von Electron. Das hat weder mit PHP, ASP noch CGI zu tun. PBExpress ist nur ein Beispiel dafür, wie ich es umgesetzt habe, Anfragen auf eine bestimmte URL zu einer bestimmten Prozedur zu leiten und innerhalb dieser mit den übergebenen Daten weiterzuarbeiten. Es geht nicht darum, externe Sprachen einzubinden. Das kann ich selbst ohne Probleme mit RunProgram. PHP hat einen integrierten Webserver. Beim start der Anwendung mit starten ... Fertig. Node brauch nur ein paar Zeilen Code. Bei Programmstart einfach mitstarten. Das gleiche bei Python oder Go.

Es geht mir darum, das Purebasic im Backend in der Lage ist, klassische HTTP-Anfragen zu verarbeiten und nicht nur Dateien an das Cef ausliefern zu können. So könnten sich Anwendungen theoretisch auch komplett ohne Javascript umsetzen lassen. Man könnte nahezu alle Javascript-Bibliotheken verwenden, ohne sie groß umschreiben und packen zu müssen.

Ich werde mir mal den Atomic ansehen und schauen, ob ich ihn entsprechend aufgebohrt bekomme. Ich halte das schon für extrem wichtig. Saß da schon einmal dran. Aber da einfach das moderne Webcontrol gefehlt hat, war mir der Sinn nicht mehr klar. Jetzt aber macht es wieder Sinn

PureBoard

PB.Ex WebGadget (Windows) (WebKit)

Re: PB.Ex WebGadget (Windows) (WebKit)

Re: PB.Ex WebGadget (Windows) (WebKit)

Re: PB.Ex WebGadget (Windows) (WebKit)

Re: PB.Ex WebGadget (Windows) (WebKit)

Re: PB.Ex WebGadget (Windows) (WebKit)

Re: PB.Ex WebGadget (Windows) (WebKit)

Re: PB.Ex WebGadget (Windows) (WebKit)

Re: PB.Ex WebGadget (Windows) (WebKit)

Re: PB.Ex WebGadget (Windows) (WebKit)

Re: PB.Ex WebGadget (Windows) (WebKit)