Delphi langsam ersetzen

[Daniel]

Zitat:

Zitat von Hansa (Beitrag 1326135)

Mir stellt sich da die Frage, welchen Vorteil sich der Fragesteller denn erhofft ?

Du kannst nicht mit jedem Projekt auf der "grünen Wiese" neu anfangen und dann mal eben rund zwei Jahre hinter verschlossenen Türen an der neuen Version schrauben. Den Wunsch nach einem gleitenden Übergang kann ich gut verstehen. Und oft genug haben wir nicht nur eine Insel-Lösung vor uns, sondern ein Projekt, welches Teil einer Infrastruktur ist und damit doppelt und dreifach behutsam angefast werden muss, um den Beitrieb gewährleisten zu können.

Deine Häme ("ha ha") ist nicht hilfreich. Eigentlich ist sie sehr unglücklich gewählt. Sehr.

[p80286]

Zitat:

Zitat von Dejan Vu (Beitrag 1326073)

Ich finde es unglücklich, in einem professionellen Umfeld aus Gründen des Monopolboykotts auf ein kleineres Produkt einzusetzen.
Ich fände es logisch, in einem professionellen Umfeld das Produkt einzusetzen, das für die Aufgabe am Besten geeignet ist. Und Delphi ist ja nun nicht gerade ungeeignet.

Der TE hat Gründe die ihn dazu verleiten sich von Delphi zu verabschieden. lassen wir es dabei.

Zitat:

Zitat von Dejan Vu (Beitrag 1326073)

Ja, es ist schade, das Microsoft andere Anbieter verdrängt. Aber ein gutes Produkt verdrängt nun einmal weniger gute.

Du solltest doch wissen, daß der Spruch aus der Märchensammlung der VWL stammt.

Gruß
K-H

[Bernhard Geyer]

Zitat:

Zitat von Hansa (Beitrag 1326135)

"Delphi langsam ersetzen" was sagt uns denn das ? Da will einer Delphi ersetzen, aber langsam. Toll. Langsam bedeutet dann wohl ungefähr : wasch mich aber mach mich nicht nass. :P Mir stellt sich da die Frage, welchen Vorteil sich der Fragesteller denn erhofft ? Haha, ich habe das komplett anders gemacht. Delphi bzw. Pascal richig gelernt und dann 1986 erstes Programm verkauft. Dürfte so 1984 gewesen sein, dass ich da angefangen habe, das zu programmieren.

Wir ersetzen auch (teilweise) unsere Delphi-Anwendungen.
Liegt halt daran das wir ein Web und Desktoplösung haben und nicht weiter zwei Quellcodes pflegen wollen.
Und mit (hier bei uns) Java können wir beide Welten aus einem Quellcode bedienen.
Vorteil liegt damit auf der Hand: 1 Quellcode statt 2 Quellcodes und damit potentiell schon mal 50% Entwicklungszeit eingespart und 50% weniger Fehler verursacht und (theoretisch) immer gleiches Verhalten auf beiden welten.

[greenmile]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1326162)

Liegt halt daran das wir ein Web und Desktoplösung haben und nicht weiter zwei Quellcodes pflegen wollen.

Dem ist leider so. Hätte Firemonkey auf mobilen Geräten korrekt funktioniert, wäre es einfach ein Traum gewesen. So bleibt es leider nur ein Traum. Vielleicht würde es ein klitzeklein wenig bringen, für Mobile AddOn nicht extra Geld zu verlangen, weil es das (meiner Meinung nach) nicht Wert ist. Da die Kuh aber gemolken werden muss, kostet es (FMX für Mobile) aber Geld und ist damit (zumindest für mich) indiskutabel.

[Bernhard Geyer]

Zitat:

Zitat von greenmile (Beitrag 1326164)

Zitat:

Zitat von Bernhard Geyer (Beitrag 1326162)

Liegt halt daran das wir ein Web und Desktoplösung haben und nicht weiter zwei Quellcodes pflegen wollen.

Dem ist leider so. Hätte Firemonkey auf mobilen Geräten korrekt funktioniert, wäre es einfach ein Traum gewesen. So bleibt es leider nur ein Traum. Vielleicht würde es ein klitzeklein wenig bringen, für Mobile AddOn nicht extra Geld zu verlangen, weil es das (meiner Meinung nach) nicht Wert ist. Da die Kuh aber gemolken werden muss, kostet es (FMX für Mobile) aber Geld und ist damit (zumindest für mich) indiskutabel.

Wir haben hier Web Apache/Tombcat auf Linux und Konsorten. Mobile ist ne ganz andere Geschichte.
Und für Mobile mit FMX hätten wir auch alles neu entwickeln müssen. Bei diesen Kinderkrankheiten die man immer wieder hört und sieht ist ein Mobile-Support als Online-Lösung einfacher zu stricken als native auf den Geräten laufen zu müssen.

[OrNEC]

Ist hier die Delphi Sprache oder die Delphi IDE gemeint?

[Phoenix]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1326167)

Bei diesen Kinderkrankheiten die man immer wieder hört und sieht ist ein Mobile-Support als Online-Lösung einfacher zu stricken als native auf den Geräten laufen zu müssen.

Und selbst wenn Du was unbedingt auf den Devices brauchst, machst Du Deine Web-App Offline-Fähig (z.B. Daten im local storage zwischenspeichern und dann wieder syncen wenn man wieder Online ist) und verpackst deine Web-App dann mit Apache Cordova in eine 'echte' Mobile App, die man installieren und mitnehmen kann.

[Bernhard Geyer]

Zitat:

Zitat von Phoenix (Beitrag 1326174)

Zitat:

Zitat von Bernhard Geyer (Beitrag 1326167)

Bei diesen Kinderkrankheiten die man immer wieder hört und sieht ist ein Mobile-Support als Online-Lösung einfacher zu stricken als native auf den Geräten laufen zu müssen.

Und selbst wenn Du was unbedingt auf den Devices brauchst, machst Du Deine Web-App Offline-Fähig (z.B. Daten im local storage zwischenspeichern und dann wieder syncen wenn man wieder Online ist) und verpackst deine Web-App dann mit Apache Cordova in eine 'echte' Mobile App, die man installieren und mitnehmen kann.

Wird bräuchten eine Lösung um einen Java-Applicationserver (Tomcat) + unsere Java-App als "echte" Mobile App bereit stellen zu können. HTML, CSS & JS ist ja nur ein kleiner Teil der Anwendung

[Dejan Vu]

Zitat:

Zitat von p80286 (Beitrag 1326148)

Zitat:

Zitat von Dejan Vu (Beitrag 1326073)

Ja, es ist schade, das Microsoft andere Anbieter verdrängt. Aber ein gutes Produkt verdrängt nun einmal weniger gute.

Du solltest doch wissen, daß der Spruch aus der Märchensammlung der VWL stammt.

Yo. Und Märchen sind auch manchmal wahr.

[sh17]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1326175)

Wird bräuchten eine Lösung um einen Java-Applicationserver (Tomcat) + unsere Java-App als "echte" Mobile App bereit stellen zu können. HTML, CSS & JS ist ja nur ein kleiner Teil der Anwendung

Sollte das jetzt eine Frage sein?

[Bernhard Geyer]

Zitat:

Zitat von sh17 (Beitrag 1326187)

Zitat:

Zitat von Bernhard Geyer (Beitrag 1326175)

Wird bräuchten eine Lösung um einen Java-Applicationserver (Tomcat) + unsere Java-App als "echte" Mobile App bereit stellen zu können. HTML, CSS & JS ist ja nur ein kleiner Teil der Anwendung

Sollte das jetzt eine Frage sein?

Ja. Wie bekommt man eine Java/Tomcat-Anwendung als native App auf iOS/Android?