Delphi Win Anwendung -> Web Anwendung

[Phoenix]

Und wenn Du das ganze mit Delphi Prism machst hast Du die ASP.NET Vorteile, und es ist trotzdem Object Pascal ;-)
Und wieso sollte man mod_mono aussen vor lassen? Das Funktioniert doch einwandfrei.

[mschaefer]

Eigentlich ist das eines der Hauptprobleme von Delphi.

Anstatt einen Pascal Interpreter für Apache zu entwickeln, den Hoster mit vermarkten könnten, setzte CodeGear auf PHP, was letzlich viel Handumcodierung erfodert.
Bei kleineren Projekten scheint mir das aber so einigermasen zu passen.

Die VCL for te Web hat eine zu kleine Community, um die Tücken zeitnah zu klären und davon gibt es noch einige, dass es mit dem Hosting nur relativ teure Lösungen gibt, macht es nicht besser.

RemObjects empfiehlt Delphi Prism und damit kann man eignen Routinen und Objecte wiederverwenden. Dies sehe ich auch. Die Hauptarbeit ist allerdings das Framework und da ist natürlich auch die Überlegung nicht fern gleich C#, ASP zu nehmen, da es in dem Bereich viele Projekte und große Community gibt. Bei RemObjects sehe ich es viel interessanter an Pascal auf Java-Maschinen laufen zu lassen. Da kommt Host ins Spiel (ok - anderes Thema)

Grüße in die Runde

[Phoenix]

Zitat:

Zitat von mschaefer (Beitrag 1097329)

RemObjects empfiehlt Delphi Prism und damit kann man eignen Routinen und Objecte wiederverwenden. Dies sehe ich auch. Die Hauptarbeit ist allerdings das Framework und da ist natürlich auch die Überlegung nicht fern gleich C#, ASP zu nehmen, da es in dem Bereich viele Projekte und große Community gibt.

Bei .NET ist doch die Sprache egal. Du tust ja grad so, als sei ASP.NET mit Prism was anderes als mit C# und das man das Framework nachprogrammieren müsste.

Das Framework kommt von Microsoft, wird dort gepflegt und mit ASP.NET WebForms bzw. ASP.NET MVC werden auch Alternativen angeboten. Auch von Novell gibt es das alles als Mono, was einwandfrei auf Macs, Linux und sonstigen Unixoiden Systemen läuft. Andere Hersteller wie Telerik, DevExpress und Infragistics liefern hervorragende Komponenten um die Arbeit noch eleganter zu machen.

Und wenn man eben Delphi kann, dann ist es eben einfacher, als Sprache zu Delphi Prism / Oxygene zu greifen und bei Object Pascal zu bleiben als oben auf den Einarbeitungsaufwand für .NET und ASP.NET auch noch C# zu lernen. Und da man die C# Beispiele die man so im Netz findet ganz einfach kopieren und als Pascal-Code wieder ins eigene Projekt einfügen kann (Paste Code from C#) ist es auch nicht so wild wenn man C# nicht unbedingt lesen kann, weil es ja automatisch nach Prism übersetzt wird.

[Bernhard Geyer]

Zitat:

Zitat von Phoenix (Beitrag 1097330)

Auch von Novell gibt es das alles als Mono, ...

Da jetzt Novell offiziell der SW-Geschichte angehört: Wer macht das jetzt eigentich weiter nachdem es Novell nicht mehr gibt? Suse?

[Phoenix]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1097332)

Zitat:

Zitat von Phoenix (Beitrag 1097330)

Auch von Novell gibt es das alles als Mono, ...

Da jetzt Novell offiziell der SW-Geschichte angehört: Wer macht das jetzt eigentich weiter nachdem es Novell nicht mehr gibt? Suse?

Attachmate wird das offensichtlich ganz normal weiterführen.

Und bei Mono, MonoDevelop, MonoMac, MonoTouch und Mono for Android geht es auch munter weiter, es wird viel neues Entwickelt und es wird immer angenehmer damit zu arbeiten. Vor ein paar Jahren war noch vieles Buggy, heute kann man sogar WCF aus MonoTouch-Anwendungen heraus ansprechen. Ich vermisse da nichts.

[chuckholdt]

Hi,

wir haben auch große Codemengen in Delphi (win32). Um die Business-Logic gemeinsam zu benutzen haben wir zwei Wege.
1. die schon oben erwähnten ApplicationServer (mit RemObjects oder KBM, funktioniert beides gut)
2. wir haben Module, die sowohl mit Win32 Delphi als auch mit Prism zu übersetzen sind (ein paar ifdefs sind leider nötig)
diese können problemlos in C# asp.net Anwendungen eingebunden werden (wir benutzen zur Zeit das MVC3 Framework)

Chuck, MORE Projects

[mschaefer]

Habe sowohl Delphi XE als auch Visual Studio und noch einiges anderes als Vollversionen und finde es durchaus vorteilhaft, wenn jede Sprache seine eigene Umgebung hat. Wenn es irgend geht würde ich aber bei einer Anwendung in einem Framework bleiben.

PS: Wenn VCL for the WEB genommen wird, würde ich die Anwendung nicht nachbauen, sondern auf die wichtigsten Formualre beschränken.

[Jackie1983]

Ich möchte ungern Vcl for the web nehmen, schon im Editor ist das Designen recht blöd, das ganze wird nicht richtig dargestellt.

Dann kommt noch dazu das man nicht alle Komp. hat und die Form recht schlecht aussieht. Und ein Umstieg ist nicht möglich das Programm besteht aus vielen Sourcen und Forms. Die Exe ist ca. 20MB.

Hatte auch schon gedacht vorzuschlagen das ganze mit PHP/JavaScript/Ajax/YUI zu machen. Vielleicht bekomme ich das durch.

Wollten auch nur bestimmte Formulare fürs Web tauglich machen, halt die wichtigsten.

[mschaefer]

Bei 20 MB steckt da sicher einiges an Arbeit drin. Eine Frameworkumstellung ist da sicherlich auch aufwendig, das gilt leider aber auch für die Neuentwicklung in PHP. Wenn es jetzt meine Aufgabe wäre, würde ich überlegen, ob die Applikation teilbar ist. Wenn nicht, dann hätte NET seine Chance. Wenn das Programm sich gut teilen läßt würrde ich einen bisher nicht erwähnten Weg gehen:

Die Logik würde ich in der Delphi-VCL-Anwendung lassen und diese um SOAP Funktionalität erweitern. Die Dateneingabe kann dann auf einem Webserver mit PHP erfolgen und die Eingabeseiten würden dann mit PHP-SOAP abgeschlossen. Daten können auch direkt mit Omatas PHP-MySQL-Tunnel abgerufen werden. Die Eingabedaten werden in der Delphi-VCL-Anwendunng verechnet und Ergebnisse wieder an das PHP-Frontend gesendet. Der Vorteil dieser Variante ist, dass Ihr getestete Code der VCL-Anwendung in Teilen verwenden könnt. Nachteil ist, dass Ihr einen PHP und eine Server für Delphi-Anwendung braucht.


Grüße in die Runde