Web GUI programmieren

Wieviel ahnung hast du von welchen programiersprachen?

operator schrieb:
> Was ich von der GUI erwarte:
> Buttons, checkboxen, radiobuttons, graph (x,y Plot), bars, progress bar

Gut, in html gibts für jedes einen tag, abgesehen vom graph, das geht 
entweder mit einem bild (muss nicht statisch sein), oder mit js und 
canvas. Tonnen von libraries und frameworks wollen einem die Arbeit dort 
abnehmem...

operator schrieb:
> Gibt es dazu ein fertiges softwarepaket, womit ich GUI und
> datenbankanbinung programmieren kann?

Es gibt libraries, die dir die Funktionen zur verfügung stellen, 
zusammenklicklösungen sind für dynamische Seiten selten, (cms zeug find 
ich nicht sehr dynamich oder praktisch).

operator schrieb:
> Dazu habe ich auch schon pyjs.org, oder Django gefunden, weiss aber nich
> ob das ist was ich suche.
> Bin für jede hilfe dankbar.

Du hast die Qual der Wahl!
Die Datenbankanbindung, etc. muss serverseitig programmiert werden. Das 
geht in fast jeder Programmiersprache. Ich liebe nodejs mit dem http 
modul, unter hobbyprogramierern ist php beliebt, und Proffesionelle 
Webanwendungen sind serverseitig oft in java geschrieben. Pyton und co 
sind auch brauchbar.

Clientseitig wird html, js und css verwendet, von flash und java applets 
rate ich ab, js kann durch eine in diese übersetzbare Sprache 
ausgetauscht werden, das umfasst alle sprachen die nach llvm übrrsetzt 
werden können (stichwort emscripten), ist den mehraufwand aber nicht 
wert.

Es gibt verschiedenste frameworks für mvc und css, momentan sind 
angularjs, ember und handlebars für mvc und templateing sehr beliebt, 
ich hab da auch ein eigenes projekt (http://mvsync.ch), wohingegen 
bootstrap (css framework) gerne fürs design verwendet wird.

Von jquery rate ich ab, das führt schnell zu chaos.

Viele triviale Seiten werden mit cms systemen erstellt, wordpress ist da 
sehr verbreitet.

Schau dier die sachen einmal genau an. Wie viel du selbst machst, woraus 
du dass System zusammen setzt entscheidet über Aufwand und Kontrolle 
über das Endprodukt.

Du weist bereits, was du willst. Wenn du weist, womit du es am 
besten/einfachsten lösen kannst, können wir empfehlungen geben wie man 
es umsetzen könnte.

operator schrieb:
> aber auch die Möglichkeit haben per PC oder Smartphone darauf
> zuzugreifen.

Mit dem browser geht dass immer, wens ne app sein soll gibt's apache 
cordova und phonegap.

Jay schrieb:
> Das kann bedeuten, dass du deine Webseite zweimal programmieren musst

Dass machen alle immer falsch: Gerätespezifische Seiten statt sich der 
Browsergrösse anpassende Inhaltsanordnung. Mann muss doch nur darauf 
achten dass das Layout immer schön, und die Inhalte gross und 
übersichtlich sind, das ist doch nicht so schweer...

Der Controller ist der Server, der auf eine Anfrage vom client, dem 
Browser wartet. Der Controller liefert also eine Webseite. Mit den 
ueblichen elementen, buttons, images, tabellen, irgendwas.
Wenn man einen Button drueckt get eine neue Anfrage an den Controller, 
fuer eine neue Seite, oder einen neuen Datensatz.
Und daneben muss der Controller das tun, wofuer er eigentlich da ist .. 
einen Prozess kontrollieren.

Fuer einen kleinen Ueberblick, verbrat ein paar Monate an HTML, CSS, 
PHP, Javascript, und MySQL.

HTML ist einen statische Seite.
CSS strukturiert die HTML Seite
PHP wird auf dem Server ausgefuehrt, der Browser sieht nichts davon
Javascript wird auf dem Broser ausgefuehrt
MySQL ist eine Standard Datenbank auf dem Server

Ausgehend von einem embedded linux board (rpi) war folgendes mein 
pragmatischer Lösungsansatz, ohne Einen für meine Anwendung zu mächtigen 
apache server und dennoch "alle" Möglichkeiten wie z.B. eingebettete 
Videos via HTML5, PHP, JS nutzen zu können.

RPI
- C-Anwendung welche IOs / Schnittstellen bedient
- Erweiterung der C-Anwendung mit der Lib microhttpd

Server
- Website-Daten / Hosting der Website auf Server XY ( nicht am RPI! )

Client
- beliebiger Browser

Ablauf:
1. Client ruft nun WebSite auf
2. WebSite führt daraufhin ein JS oder PHP aus
3. JS geht nach JSONP ( Json with Padding ) vor und führt daraufhin ein 
"ausgelagertes Script" aus.
4. Dieses Script wird von der C-Anwendung am RPI zur Verfügung gestellt 
und an die WebSite übergeben.
5. Script wird ausgeführt und enthält Daten der IOs etc.

Vorteil: automatische Test, klar definierte Schnittstelle etc., schnelle 
Umsetzung
Nachteil: Sicherheit

Eine Voraussetzung war im übrigen ein "kleines" mit buildroot erstelltes 
rootfs!

operator schrieb:
> Jetzt Nicht schrieb:
>> Fuer einen kleinen Ueberblick, verbrat ein paar Monate an HTML, CSS,
>> PHP, Javascript, und MySQL.
>
> Genau das wollte ich eigentlich verhindern

Die Erfahrung zeigt allerdings, dass es ungemein hilfreich ist, wenn man 
sich in HTML zumindest ein bischen auskennt und auch nicht davor 
zurückschreckt, auch mal eine HTML Seite direkt im Editor zu coden.

Das was du dort an Grundlagen lernst, brauchst du praktisch immer wieder 
und sei es nur, um dir am Browser im dortigen HTML anzusehen, warum der 
Output wieder mal nicht so aussieht, wie du es erwartest.

> und dachte dafür könnte man
> diese Frameworks oder toolkits gebrauchen. Oder sind die eben nicht, um
> das abzulösen?

Sind sie.
Aber so wie sich das viele vorstellen, "da nehm ich ein Toolkit, drück 
auf 3 Knöpfchen und dann funktioniert das", so ist das in den seltensten 
Fällen.

Einiges kann man bereits ohne Programmierkentnisse vorbereiten. Es ist 
immer sinvoll Entwürfe von allen GUIs anzufertigen, und OOA Diagramme 
der anfallenden Daten zu erstellen.

Ja, es gibt Toolkits. Ja, sie sollen das Leben vereinfachen.

Und irgendwann machen sie was Anderes wie vorgesehen, oder die 
Performance bricht dramatisch ein. Weil man das Konzept dahinter nicht 
verstanden hat.

Man nimmt irgendwelche Demos zu diesem Toolkit aus dem Internet und 
versucht sie irgendwi anzupassen. Das geht vielleicht oder nicht, oder 
nicht mehr.

Und dann ist man soweit die Basics doch anzuschauen. Richtig brauchbar 
wird man erst wenn man das schon durch hat.
Das gewuenschte Projekt hat Potential, ist sowieso brauchbar. Also ist 
der eine oder der andere Weg gut. Kommt schliesslich aufs selbe raus.