Einfaches Client/Server-System à la SAP?



  • Symfony ist erstmal auch nur ein Framework, deine Anwendung musst du schon selber schreiben. Aber solche Frameworks sind entsprechend durchdacht und zwingen dich mehr oder weniger, deine Anwendung sauber aufzubauen.
    Das mit den Shortcuts ist jetzt kein Feature eines Frameworks. Ist doch klar, dass eine Webanwendung nicht ganz dasselbe wie eine Desktopanwendung ist. Vieles kann man aber ähnlich und vor allem ähnlich bequem machen. Shortcuts kann man mit JavaScript schon realisieren. Man kann das sicher auch konfigurierbar machen, musst dich halt selber drum kümmern. Sollte aber kein Akt sein.



  • Ist doch klar, dass eine Webanwendung nicht ganz dasselbe wie eine Desktopanwendung ist.

    Ja, klar. Welchen Part Symfony nun erfüllt konnte ich noch nicht ausmachen.
    Mich würde einmal die Desktop-Anwendung (kompilierte EXE) und deren Möglichkeiten interessieren.

    Zur Info: Die Terminal-Emulator Software an meinem Arbeitsplatz war folgende http://www.gar.no/en/products/glink-for-windows/features



  • Fletcher schrieb:

    Ja, klar. Welchen Part Symfony nun erfüllt konnte ich noch nicht ausmachen.
    Mich würde einmal die Desktop-Anwendung (kompilierte EXE) und deren Möglichkeiten interessieren.

    Symfony ist dein Backend.
    Es bietet dir aber zusammen mit einer guten JavaScript Library alles was du fuers Frontend brauchst.

    Das coole daran:
    Datenbank Modell, View, Kommunikation zwischen Client/Server, etc. ist alles bereits fix und fertig.

    Ob es jetzt Symfony oder Rails oder sonstwas ist, ist dabei egal.

    Du brauchst keine exe Datei fuer den Client - das macht der Browser schon. Der Browser ist der ideale Client fuer sowas - denn die Leute kennen ihn, er wird konstant weiterentwickelt und er nimmt dir enorm viel Arbeit ab.

    Aber du haengst dich gerade an einem Client Feature auf. Sowas ist uninteressant. Wenn deine Plattform steht - dann sind Client Features trivial hinzufuegbar.

    PS:
    Vergleiche dein System mal mit Facebook. Auf einer abstrakten Ebene natuerlich und du wirst sehr viele Gemeinsamkeiten finden.



  • Danke für die Erläuterungen.

    Du brauchst keine exe Datei fuer den Client - das macht der Browser schon.

    Tja, dann bringt mir Symfony doch wieder nichts was nach meinem Geschmack wäre.
    Die gängigen Browser sind für Webseiten konzipiert und dieses Konzept halte ich für professionelle Anwendungen im professionellen Umfeld nicht geeignet. Die Art und Weise wie man auf ebay oder amazon herumdaddeln kann ist vielleicht für den Privatnutzer ausreichend, aber müßte ich den ganzen Tag hauptberuflich auf so einer Plattform arbeiten würde ich krank werden.

    Ganz anderes Beispiel: Online-Casinos
    Wer meint, daß er dort mitspielen möchte (trotz der Tatsache daß man dort langfristig immer nur verliert), muß sich meistens eine Desktop-Software herunterladen (compilierte exe), wo z.B.: der Roulette-Tisch grafisch besonders schön dargestellt wird und man oftmals per direktem Tastenzugriff Aktionen tätigen kann. Das wäre dann ein dezitierter Browser mit sehr eingeschränkten Möglichkeiten, weil es hier nur ums Roulette-Spielen geht, aber dieses gebotene User-Handling wirst du mit einem Browser und Java niemals erreichen; sonst würden diese Desktopanwendungen gar nicht angeboten werden, wenn es mit dem Browser auch funktionieren würde.

    Nocheinmal: Bei meinem Vorhaben geht es in erster Linie um gute haptische Interaktion mit dem User. Transaktionen müssen auch im lauten, dreckigen, vibrierenden Bergwerk mit nur einer Hand (manchmal ohne Maus!) getätigt werden können.





  • Fletcher schrieb:

    Die gängigen Browser sind für Webseiten konzipiert und dieses Konzept halte ich für professionelle Anwendungen im professionellen Umfeld nicht geeignet.

    Das ist falsch.
    Der aktuelle Trend geht dazu immer mehr ins Web zu legen - weil es unheimlich praktisch ist.
    Man kann ganze Office Anwendungen als Webapp laufen lassen.

    Der Browser kann alles was notwendig ist. Du kannst sogar notfalls mit OpenGL die Grafik machen wenn dir wirklich langweilig ist.

    Nocheinmal: Bei meinem Vorhaben geht es in erster Linie um gute haptische Interaktion mit dem User. Transaktionen müssen auch im lauten, dreckigen, vibrierenden Bergwerk mit nur einer Hand (manchmal ohne Maus!) getätigt werden können.

    Und nocheinmal:
    Der Browser hat deine erste Anlaufstelle zu sein.
    Der Browser kann mehr als du denkst.

    Gerade wenn du Bergwerk sagst, spricht wieder unmengen fuer den Browser - denn ein Touchlayout dass auf allen Geraeten laeuft, ist im Web trvial.

    Das coole ist ja, dass du billigsdorfer Hardware nehmen kannst, es ist komplett egal was - denn ein Browser laeuft sicher darauf. Aber ob es jetzt Android oder ein Windows CE ist, ist komplett egal. Sogar irgendwelche Custom BSDs waeren kein Problem: es braucht nur einen Browser und den hat man ueberall.

    Aber wozu rede ich mir hier den Mund fusslig... Du scheinst alles eh besser zu wissen.



  • Nochmal (und zusätzlich zu dem was Shade of Mine gesagt hat): man kann auch im Browser über JS shortcuts definieren.



  • Ist OK, ich nehme alles zur Kenntnis.
    Soll der Thread dazu führen, daß ich mir C++ und SQL gleich gar nicht näher anschaue? Egal für welchen Zweck?

    Wegen dem Quake 2 im HTML5-Browser: "Toll", das dorthin portierte Spiel läuft auf einem aktuellen Computer gerade einmal so schnell wie es bereits auf der im Jahr 1997 verfügbaren Hardware lief. Ich habe Quake 2 damals gespielt, und habe es rein zufällig vor ein paar Monaten wieder mit einem High-Res-Mod gespielt, wo es natürlich dank heutiger Hardware auf jeden Fall mit 60 FPS lief.

    Der Browser kann mehr als du denkst.

    Das kann ich aber auch als Gegenargument verwenden - Stichwort: Sicherheitslücke. Ja, ich weiß - bei einer selbst "zusammengepfuschten" Anwendung gibt's erst recht Sicherheitslücken, nur weiß ich dort wo sie höchstens sein können aufgrund der beschränkten Möglichkeiten.

    Man kann ganze Office Anwendungen als Webapp laufen lassen.

    Du meinst sicher Office 365; ich kenne es nur vom Namen her. Ich kann mir aber nicht vorstellen daß dort VBA-Makros funktionieren.



  • Fletcher schrieb:

    Soll der Thread dazu führen, daß ich mir C++ und SQL gleich gar nicht näher anschaue? Egal für welchen Zweck?

    Mach was du willst.

    Wegen dem Quake 2 im HTML5-Browser: "Toll", das dorthin portierte Spiel läuft auf einem aktuellen Computer gerade einmal so schnell wie es bereits auf der im Jahr 1997 verfügbaren Hardware lief. Ich habe Quake 2 damals gespielt, und habe es rein zufällig vor ein paar Monaten wieder mit einem High-Res-Mod gespielt, wo es natürlich dank heutiger Hardware auf jeden Fall mit 60 FPS lief.

    Wenn du das neue super Modern Warefare MMORPG schreiben willst, dann empfehle ich dir nicht den Browser als Client.
    Quake sollte dir zeigen, dass der Browser weit mehr kann als du denkst. Aber das willst du nicht einsehen, oder?

    Der Browser kann mehr als du denkst.

    Das kann ich aber auch als Gegenargument verwenden - Stichwort: Sicherheitslücke. Ja, ich weiß - bei einer selbst "zusammengepfuschten" Anwendung gibt's erst recht Sicherheitslücken, nur weiß ich dort wo sie höchstens sein können aufgrund der beschränkten Möglichkeiten.

    Man kann ganze Office Anwendungen als Webapp laufen lassen.

    Du meinst sicher Office 365; ich kenne es nur vom Namen her. Ich kann mir aber nicht vorstellen daß dort VBA-Makros funktionieren.

    Diese 2 Absaetze sind so dumm, dass ich mich hiermit ausklinke.



  • Fletcher schrieb:

    Um native Windows-Anwendungen zu schreiben, habe ich mir einmal den Windows-SDK runtergeladen. Dort ist C++ enthalten (und nur C++); es wird schon einen Grund haben warum das so ist.

    Als kleine Anmerkung: Seit ~2007 ist das .NET-Framework Bestandteil des Windows SDKs.


Anmelden zum Antworten