Delphi-PRAXiS

Delphi-PRAXiS (https://www.delphipraxis.net/forum.php)
-   Programmieren allgemein (https://www.delphipraxis.net/40-programmieren-allgemein/)
-   -   Responsives Design (https://www.delphipraxis.net/214485-responsives-design.html)

NoName1 18. Jan 2024 15:14

Responsives Design
 
Guten Tag Delphianer,
ich überlege ob ich miene Vereinssoftware http://logensoftware.de in ein Responsives Design umwaldeln soll.

Einiges zu der Software:
a) Die Software ist Mehrbenutzerfähig und liegt auf einem Server
b) Jeder Verein hat seine eigene Datenbank
c) Als Datenbank wird Interbase benutzt
d) Als Fremd-Komponenten werden TMS-FNC und WPTools von WPCuped eingesetzt.


Es stellen sich mir aber einige Fragen:
a) Als Komponenten möchte ich TMS-Web Komponenten einsetzen?
b) Macht es überhaupt Sinn, eine so umfangreiche Anwendung als "Responsive-Anwendung" neu zu programmieren?
c) Kann Interbase als Datenbank weiterbenutzt werden?
d) Wird ein Provider benötigt?

Mehr Fragen habe ich im Moment, auf Grund meiner Unwissenheit, nicht.

Hat evtl. jemand Wissen um diese Angelegenheit und kann Aussagen treffen?

Vielen Dank für Eure Hilfen.

Rollo62 18. Jan 2024 16:22

AW: Responsives Design
 
TMS WebCore ist sicherlich interessant, wenn man von Delphi kommt.
Es ist aber eine komplette Neuentwicklung, und responsiv ist das auch mit WebCore nicht automatisch.

Wozu muss das unbedingt responsiv sein, wer will das mit iPhone bedienen?
Das würde das Konzept komplett umstülpen.
Ich nehme mal an, das ist eine Exe-Datei, dann ist vielleicht ist ja auch so etwas wie UniGui interessant, um das 1:1 in den WebBrowser zu bekommen?

Phoenix 18. Jan 2024 16:28

AW: Responsives Design
 
Lieber NoName,

ja, das ergibt definitiv Sinn.
Damit kann die Anwendung dann nicht nur am PC, sondern von jedem Gerät aus bedient werden.

Die Fragen, die ich mir vor einer solchem Umstellung allerdings heute zuerst stellen würde sind die folgenden:
- Bin ich mir zu 100% sicher, dass jede Loge auch in der Zukunft (5-10+ Jahre) einen eigenen Rechner besitzt, auf dem die Software betrieben wird?
- Will sich der Verein wirklich um den Betrieb des Rechners, Software-Updates und Backups etc. kümmern (müssen)?
Oder wäre es dem Verein und den Verantwortlichen dort nicht vielleicht lieber, dass sich jemand professionell darum kümmert und das sowohl betreibt als auch für die Datensicherheit sorgt?

Ich denke schon seit einiger Zeit darüber nach, eine vernünftige, Web-basierte, allgemeine Vereinsverwaltung für allgemeine e.V's., primär Sportvereine, zu bauen.
Mitgliederverwaltung, Beitragseinzug, Mitglieder-Chat (damit der Verein kein Whatsapp nuzten muss), (Arbeits-)Kalender-Verwaltung für Vereinsveranstaltungen mit iCal Support (so kann jedes Mitglied seine Termine sofort in seinen Kalender reinziehen), Dokumentenbereich (Satzung, Ordnungen, Zeichnungen etc.) usw.

Das ganze dann schön DSGVO-Konform in Deutschland gehostet als Software-as-a-Service anbieten (kostenlose Basisversion, Beitragseinzug, weitere Features können dann für ein paar Cent / Mitglied / Zeitraum dazugebucht werden).

Das Frontend kann dann natürlich eine vom Server gerenderte Webseite sein.

Oder eben auch Apps (Android / iOS, ggf. auch Web-basiert). Nur hier stellt sich dann die große Frage: Sollte so eine App dann auch - zumindest Teilweise - noch funktionieren wenn man offline ist (z.B. im Zug unterwegs etc.). Wenn ja, dann funktioniert das nicht mehr, wenn die Webseiten ausschließlich vom Server erzeugt werden. Dann braucht man sog. Single-Page-Apps (SPAs), und die werden dann mit JavaScript oder Typescript gebaut.

Das Backend (die API) und die Datenhaltung sind dabei dann relativ technologieoffen.
Das kann man freilich mit Delphi und Interbase machen. Das lässt sich dann wohl aber eher schwieriger günstig betreiben (für MariaDB/MySQL, SQL Server, PostgreSQL gibt es günstige Cloud-Lösungen auch in DE), für Interbase/Firebird muss man dann schon eine ebene tiefer mit eigenen Containern (Docker) gehen und die selber orchestrieren, insbesondere wenn es irgendwann auch mal um Ausfallsicherheit (und ggf. Lastverteilung) gehen soll.

Gehen wir aber mal tatsächlich davon aus, die Loge würde seinen Webserver auf einem Rechner betreiben, und mehrere Benutzer der Loge könnten dann darauf zugreifen.
Wenn die Beamten von zu Hause darauf zugreifen sollen können müsste die Loge die Software dann auf einem gemieteten (virtuellen) Server laufen lassen (echte hardware bzw. gemietete VMs sind recht teuer), oder eine andere Zugriffsart ermöglichen. Dazu könntet ihr als Anbieter z.B. einen RelayServer im Internet bereitstellen, und jede Loge installiert lokal neben ihrem Server-Dienst einen Connector, der einen Tunnel zu Eurem RelayServer öffnet. Dann kann man von aussen durch diesen Tunnel auf den Rechner (z.B. in den Logenräumen) zugreifen, wenn dieser läuft. So einen Relay bieten wir als Open-Source Lösung an: https://github.com/thinktecture/relayserver

State-of-the-Art ist allerdings wirklich eher die DB <--> Backend (API) <--> SPA (Frontend) Architektur.

Mit brdl. Grüßen,

Phoenix

himitsu 18. Jan 2024 16:42

AW: Responsives Design
 
Wenn es nur darum geht (erstmal) eine VCL/FMX-Anwendung etwas responsiver zu bekommen.

Na erstmal das alt Bekannte ala Align, Margin und Anchor, sowie manuell via OnResize, OnAlignPosition usw.

Beim FMX kann man selbst verschiedene "Ansichten" erstellen, also "manuell" für verschiedene Geräte/Displayauflösungen/Seitenformat die Komponenten im Designer umherschieben, ein-/ausblenden, Schriftgrößen anpassen usw.
Das sind dann vererbte Forms, wo über die eigentliche Design-Form noch eine weitere Form-Vererbung draufgelegt wird, in welcher man Property anpassen kann.

Und dann gibt es Layout-Komponenten, welche dir helfen mehrere Komponenten nach gewissen Regeln automatisch anzuordnen. (Größe, Position und/oder Sichtbarkeit)
im FMX in der Komponentenpalette nach "Layout" suchen
und in der VCL nach "Panel"


Alle Zeitangaben in WEZ +1. Es ist jetzt 05:50 Uhr.

Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz