Umfrage: Für neuartiges Shopsystem

[pmvstrm]

Guten Tag allerseits,

Nachdem ich nun schon in mehreren Situationen in den letzten Jahren
immer wieder über die halbgaren Shoplösungen wie osc, xtc, apt u.s.w
gestolpert bin und irgendwie keiner so recht das abbildet was man meist
für ein Projekt benötigt, habe ich den Entschluss gefasst ein komplett
neuartiges Shopsystem zu entwickeln das eine Tomcat Servlet/JSP Lösung
sein wird.

Technisches:

Unterstützung für folgende Datenbanken:
-PostgreSQL (ab Version 8.3) (hat immer Priorität)
-MySQL 6.0 (Nur Falcon Storage Engine Tables)
-ORACLE (Express, Standard Edition, Enterprise Edition ab Vers 11.x).

Unterstütze WebApplicationserver:
Tomcat/Jetty (oder jede 100% Compliant J2EE/Jee5 Servletengine)

Unterstützte Betriebssysteme:
Linux, FreeBSD, Windows, Mac, Solaris
(oder jedes Java 6.0 oder höhere Runtimesystem)

Webhostinganforderungen:
Beliebiger V-Server/Root-server

Module:
Katalog mit Bestellfunktion, Multimandantenfähig, Mehrsprachig,
mehrere Währungen, CMS, Forum, Adminmodul, Schnittstellenmodul
mit erweiterbaren import/export, Barriere freie Gestaltung und Liste
eingebundener Agenturen die Standardtemplates oder Maßanfertigungen
liefern.

Das ist geplant für die Version 1.0

Über Anregungen und weitere Ideen würde ich mich freuen,
Grüße Pmvstrm

 

[dkdenz]

...und nun?
Können wir das irgendwo testen?
Ich habe neulich einen Verbrennungsmotor entwickelt, welcher nur durch Zwiebeln angetrieben wird und keiner will in haben...

 

[pmvstrm]

...und nun?
Können wir das irgendwo testen?
Ich habe neulich einen Verbrennungsmotor entwickelt, welcher nur durch Zwiebeln angetrieben wird und keiner will in haben...

Das ist eher ein Request vor Comments denn ein fertiges Produkt.
Wäre es sinnvoll, daß ist doch die Frage.

 

[ZeitGeist]

Was soll denn so neuartig an diesem Shop sein?

 

[pmvstrm]

Was soll denn so neuartig an diesem Shop sein?

Dem Konzept nach setzt er erstmal auf einem V-Server oder Rootserver
auf. Das sollte mittlerweile kostentechnisch ok sein, da es mittlerweile
V-Server schon für unter 4 EUR pro Monat gibt.

Zum Zweiten basiert er auf Apache Tomcat. Tomcat ist anders als
Apache native HTTP kein um CGI ähnliche PlugIns erweiterter HTTP
Server sondern ein WebApplicationserver der von Grund auf und
schon in der Konzeptphase als WebApplicationsystem entworfen
wurde. Natürlich unterstützt Tomcat auch HTTP 1.0/1.1, viele
Webstandards, ein extrem performantes und gut organisiertes
Crossplattform DB Interface und Kryptology sowie alle Funktionen
des Java Runtime Environments auf . Da Tomcat in
Java entwickelt wurde, läuft Tomcat genau die alle anderen
Java Applikationen dort wo ein JRE läuft, das OS drunter
ist ihm egal.

Auf dieser Platform aufbauend ist eine komplett Objektorientierte
Neuentwicklung eines neuartigen Shopsystems möglich, das mit
dem Spagetthicode von PHP4/5 in keinster weise mehr zu
vergleichen ist. Darüber hinnaus bieten sich die Frameworks
Struts, Velocity und Lucene sowie die Apache Commons
bestens für CMS-Funktionalität, PDF-Creation on the Fly zum
Nulltarif an. Sehr gute IDE's gibts einige kostenlose
(Eclipse, Netbeans, IntelliJ oder ORACLE JDeveloper).

Im Schnitt schlägt jede gut programmierte Tomcat WebApplikation
eine PHP Applikation um den Faktor 2 in Punkto Performance,
Wartbarkeit/Erweiterbarkeit und Codesicherheit (unter Java sind
z.B keine Bufferoverflows möglich). In einem IX Test zog eine
Optimierte Tomcat Applikation PHP, PERL und native C CGI
gnadenlos davon. Einige inoffizielle Tests zeigen sogar,
das Tomcat sogar schneller statisches HTML auf einer
vergleichbaren Maschine ausliefert wie der der alte, native
Apache HTTPd.

Es sprechen sicher mehr objektive Argumente dafür von PHP4
auf Tomcat b.z.w Serverside Java umzusteigen als auf PHP5.
Im Gegensatz zum PHP Versionsdesaster laufen sogar noch
die Sourcecodes von 1998 in jeder JVM ohne zu murren,
wenns 100% Javacode ist, da kann sich php mal ne gute
scheibe von abschneiden.

 

[Curtains]

Hallo pmvstrm,

Java und PHP bieten zahlreiche Möglichkeiten, um sexy objektorientiert zu programmieren.
Ich finde allgemein, dass Technologiefragen überbewertet werden. Schlanke und transparente Programme sollten problemlos von einer Programmiersprache in die andere übersetzbar sein.
Das Einzige, was ich wirklich an PHP vermisse, ist eine gute Lucene Portierung. Aber vielleicht hat Zend mittlerweile eine brauchbare Version.

 

[pmvstrm]

Hallo pmvstrm,

Java und PHP bieten zahlreiche Möglichkeiten, um sexy objektorientiert zu programmieren.
Ich finde allgemein, dass Technologiefragen überbewertet werden. Schlanke und transparente Programme sollten problemlos von einer Programmiersprache in die andere übersetzbar sein.
Das Einzige, was ich wirklich an PHP vermisse, ist eine gute Lucene Portierung. Aber vielleicht hat Zend mittlerweile eine brauchbare Version.

PHP hat so viele Schwächen, die erst langsam durch Trial and Error
das Qulitätsniveau von Java erreichen.

Mal ein paar Beispiele:

-Kein virtueller Maschinencode, der zur Laufzeit ncoh otimiert wird.
-BufferOverflowproblematik durch Pufferüberläufe (da native/statisch gelinkt)
-Zeitverzögerung durch den Wirkungsregelkreislauf von Apache1/2
-Kein Default Caching ohne teure Zend Platform
-Kein Connectionpooling ohne Dirty Tricks oder teuere Zendplatform
-Desaströse Sicherheitslage der meisten verfügbaren Skripte
-Codeausführbarkeit hängt vom OS Webservereinstellungen ab.
-Kein Out of the Box Loadbalancing und Sessioncaching
-Kein halb so gutes, einheitliches DB-Interface wie Java JDBC
-Keine State of the Art IDE's wie Eclipse, Netbeans, IntelliJ, JDeveloper
-Kein Mehrschichtiges n-Tier Application Szenario verfügbar das an die
Qualität der garantierten J2EE/Jee5 Applicationserver herranlangt.

Fangen wir nur nicht mit den tollen OOP-Features von PHP5 an, die
sind so unausgereift und billig das nicht mal ein Vergleich mit Java lohnt.

 

[Bieber]

und wo ist jetzt dein Problem? was willst du hier eigentlich?

uns davon überzeugen das PHP mist ist? und JAVA das non-plus-ultra? Das ist schwachsinn... jede Sprache hat seine Vor- und Nachteile....

also viel Spaß mit deinem Shopsystem... wenn du es wirklich so hinbekommst wie du erzählst bin ich einer der ersten der es testet, aber bis es soweit ist werden wohl noch ein paar Jahre vergehen (zumindest wenn du es alleine machst)

 

[ein schlauer]

Das Problem an der ganzen Sache ist wohl eher, das Szenario das du beschreibst dürfte für die meisten (mich eingeschlossen) zu professionell sein. Java, Tomcat, Struts und Server - das alles zu beherrschen bestimmt nur wenige ausreichend gut, um allein das alles einzurichten.

Mich als Autodidakt mit 25 Jahren Programmiererfahrung überfordert schon Eclipse. Ich glaube das Problem haben sicher viele für kleinere Firmen Internetshops betreuen und selbst mit einem Informatiker Studium wird man ja auch nicht unbedingt in die ganze Bandbreite der Techniken eingeführt (auch wenn man dann sicher eher die Fähigkeit hat komplexe Anwendung zu verstehen).

Insofern wirst du mit deinem Vorhaben sicher professionelle Firmen ansprechen, die auf der Suche nach einer Shopanwendung sind, aber kaum einen Ersatz für OS Commerce und Varianten bieten können. Genauso wenig wie Java ein Ersatz für PHP ist, bei allen Vorteilen.

 

[pmvstrm]

Das Problem an der ganzen Sache ist wohl eher, das Szenario das du beschreibst dürfte für die meisten (mich eingeschlossen) zu professionell sein. Java, Tomcat, Struts und Server - das alles zu beherrschen bestimmt nur wenige ausreichend gut, um allein das alles einzurichten.

Also ich glaube das Du das für den Endanwender sogar wesentlich
konfortabler gestalten kannst als es mit PHP möglich ist.

Tomcat installieren:
1.Tomcat unzippen
2.Startup.bat / Linux Startup.sh

Danach im Webbrowser Test Page for Apache Installation aufrufen und schon
haste die Grafische Veraltungswebsite.

Install einer Tomcat Application:
MyApp.war in den Tomcat Ordner
/webapplications
werfern und zugucken wie Tomcat sie automatisch
installiert.

Danach http://localhost:8080/MyApp

Das ist nicht so schwer

Mich als Autodidakt mit 25 Jahren Programmiererfahrung überfordert schon Eclipse. Ich glaube das Problem haben sicher viele für kleinere Firmen Internetshops betreuen und selbst mit einem Informatiker Studium wird man ja auch nicht unbedingt in die ganze Bandbreite der Techniken eingeführt (auch wenn man dann sicher eher die Fähigkeit hat komplexe Anwendung zu verstehen).

Eclipse ist auch mitlerweile zu einem Monster angeschwollen. Ich nutze
lieber Netbeans, das hat alles notwendige und läuft überall schnell,
robust und mit allem Komfort. IDEA kann man auch noch empfehlen.
Eclipse setze ich nur ein wenn ich muss

NetBeans hat so tolle sache wie z.B Du tippst for für eine For Schleife und
er baut dir das gesammte Syntaxkonstrukt rundherrum. Verrät Dir wo
noch Excetions sind und bietet per Knopfdruck das passende
Wrapperkonstrukt an,das spart zeit und hilft ennorm in der
täglichen arbeit. Hab sogar jetzt mal ein VI PlugIn ausprobiert,
damit kann man noch fixer zu werke gehen

Insofern wirst du mit deinem Vorhaben sicher professionelle Firmen ansprechen, die auf der Suche nach einer Shopanwendung sind, aber kaum einen Ersatz für OS Commerce und Varianten bieten können. Genauso wenig wie Java ein Ersatz für PHP ist, bei allen Vorteilen.

Also nen Kompletten Webserver sauber mit PHP ud allem anderen, notwendigen zu betücken, die Versionitis und Sicherheitsaspekte
im Auge zu behalten, halte ich für Aufwendinger, obwohl weniger performant.

 

[Albu]

Das ist nicht so schwer

Na dann geh mal zu einem Massenhoster, wo die überwiegende Anzahl der KMUs hockt und versuch Dein .war dort zu installieren.

Also nen Kompletten Webserver sauber mit PHP ud allem anderen, notwendigen zu betücken, die Versionitis und Sicherheitsaspekte
im Auge zu behalten, halte ich für Aufwendinger, obwohl weniger performant.

Versionitis kannst Du auch mit Java haben. Sicherheitslücken machen keinen Umweg um Java und sind, zusammen mit der Performance, direkt abhängig von der Unfähigkeit des Programmierers.

Zu Deinen anderen Argumenten: Bei manchen hast Du sicherlich Recht, bei manchen anderen muss man laut Bullshit rufen:
- eine VM hat schon gewisse Vorteile, aber daraus automatisch einen Nachteil abzuleiten, ist etwas weit hergeholt.
- Pufferüberläufe sind sicherlich ein Problem, wenn der PHP-Kern schlecht programmiert ist, aber Javas NPEs sind auch nicht zu verachten (zugegebenermaßen dürften diese in der VM eher selten sein)
- Dein Wirkungsregellaufkreis ist doch bei einer J2EE Anwendung wesentlich höher als bei PHP. Bei entsprechender Konfiguration kann ich nach Ctrl+S in PHP sofort testen, während ich für den Applikation Server erst ein .war kompilieren muss, welches dann auch noch deployed werde muss.
- die desaströse Lage ist durchaus richtig, aber es zwingt Dich keiner diese kaputten Skripte zu verwenden. Überhaupt ist die Anzahl verfügbarer PHP Skripte weitaus höher, als die von .war Dateien, bzw. fertigen Java Klassen für den Einsatz des unbedarften Webfricklers. Außerdem sind die Hürden für Einsteiger bei PHP wesentlich niedriger als bei Java, es ist deshalb nur logisch, dass die Anzahl schlechter Skripte wesentlich höher ist. Und wie gesagt schlechter Code geht auch in Java.
- Codeausführbarkeit hängt immer von OS und Webservereinstellungen ab. Genauso wie Java und ein Appliaction Server ala Tomcat, JRun, und all die anderen als Paket installiert werden müssen, muss auch Apache und PHP als Paket installiert werden, sonst geht gar nix.
- IDEs gibt es auch für PHP (Eclipse oder Dreamweaver um ein paar zu nennen). Das Eclipse Plugin für PHP ist sicherlich nicht auf dem Stand der Java Umgebung, aber zum Skripten völlig ausreichend.
- Dein Mehrfach Tier kannst Du Dir auch in die Haare schmieren, das ist überhaupt nicht die Zielsetzung einer Skriptsprache wie PHP. Vielleicht solltest Du hier keine Äpfel mit Birnen vergleichen. Wenn dann solltest Du J2EE mit Corba oder .Netz vergleichen. Allerdings hindert Dich PHP nicht daran innerhalb Deiner Applikation eine multi-tiered Architektur zu implementieren. Es gibt eben nur vom (PHP) Framework keine Hilfsmittel, best-practices oder Vorgaben die eingehalten werden, die Pflicht das multi-tier zu implementieren und einzuhalten liegt ganz allein bei den Entwicklern.

 

[ZeitGeist]

Ich glaube es ging hier nie um einen Programmiersprachen-Krieg und das ganze wurde erst du Biebers etwas agressiven Thread ein wenig aufgebläht. Unterschiedliche Programmiersprachen haben unterschiedliche Einsatzziele und damit auch ihre jeweils eingene Existensberechtigung.
Größere Webprojekte in Java statt in PHP zu entwicklen, ist sicherlich sinnvoll. Man muss sich dann nur im klaren sein, dass der Anwenderkreis kleiner ist, da Server mit Tomcat und Javauntersützung doch seltener und teuerer sind.

Als Anwender und Shopbetreiber ist mir dass aber recht egal, solange der Shop gut läuft und das kann was ich brauche. Wo da jetzt bei dir die Neuerungen sind, sehe ich immer noch nicht.

 

[skooli]

Also nen Kompletten Webserver sauber mit PHP ud allem anderen, notwendigen zu betücken, die Versionitis und Sicherheitsaspekte
im Auge zu behalten, halte ich für Aufwendinger, obwohl weniger performant.

Aber die Nachfrage danach ist wesentlich höher. Ich finde gerade keine Grafik mit PHP/Tomcat "Marktanteilen", aber ich wäre sehr überrascht wenn PHP dort nicht in einer deutlichen Mehrheit vertreten ist.
PS: schonmal nginx (statt apache) mit php als fcgi und xcache versucht? um den faktor 10-1000 schneller als standard apache mit standard php

 

[pmvstrm]

Größere Webprojekte in Java statt in PHP zu entwicklen, ist sicherlich sinnvoll. Man muss sich dann nur im klaren sein, dass der Anwenderkreis kleiner ist, da Server mit Tomcat und Javauntersützung doch seltener und teuerer sind.

Deshalb meine ich auch das VServer, die heute für unter 4 EUR zu haben
sind, wo man eine ganze, virtuelle Linux Instanz hat (also quasi sein
eigener Admin auf dem Webserver) hier bald alle vorkonfektionierten
Webhostingpaketen mit ihren Einschränkungen und Sicherheitsrisiken
ablösen werden. Natürlich brauch man dafür Adminerfahrung und das
ist meiner Meinung nach auch richtig so.

Als Anwender und Shopbetreiber ist mir dass aber recht egal, solange der Shop gut läuft und das kann was ich brauche. Wo da jetzt bei dir die Neuerungen sind, sehe ich immer noch nicht.

Also für Java sprechen in diesem Umfeld für deine Sichtweise als
Endanwender ganz konkrete und praktische Dinge. Zum ersten
das Thema Erweiterbarkeit und Wartbarkeit. Selten läuft etwas
so direkt von der Stange. Es ist wesentlich einfach große Projekte
in Java zu verwalten, als in PHP, das liegt schon an der Struktur,
den Werkzeugen (z.B Refactoring Tools) und der einheitlichen Doku
sowie der absolut 100% einheitlichen Standards, die bei Java
einfach funktionieren. Bei einer WAR Schopapplilation wirst Du nie
einen Unterschied erleben ob Du das Ding auf Tomcat nun auf
Windows oder Linux, MAC OS X oder FreeBSD laufen lässt, es
ist wie bei PDF's immer exakt das gleiche Bild das sich einem bietet,
weil die Shopapplikation selber komplett vom Betriebssystem isoliert
abläuft und alleine das beitet ennorme Sicherheitsvorteiel und auch
bei Fehlersituation kein direktes durchgreifen auf die Betriebssystem
Schichten.

Sicherheit:
Oben kurz angesprochen: BufferOverflows. Pufferüberläufe brauchen
maschinencode Einsprungadresse um auf den Stack ausführbaren Schadcode
zu platzieren. Da der Java Code komplett "virtuell" ist und zu keiner
CPU-Architektur spezifisch ausgelegt ist, kann sowas nicht fruchten,
daher gibt es in der Java Welt keine Pufferüberläufe. Sicher kann
es mal passieren, das der kleine I/O-Layer (also die VM selber) die
ja anteilig auch in C geschrieben wurde einen Pufferüberlauf beinhaltet,
der lässt sich aber in der Regel nicht ausnutzen von der internen
VM aus und ist erstens sehr selten und zweitens so gut wie nicht
verwendbar.

Investitionssicherheit:
Java Code ist, egal ob nun unter Windows oder Linux/ MAC u.s.w
entwickelt immer 100% Indentisch (es sei denn einer verwendet irgend
welche nicht authorisierten, nicht anerkannte Native Extensions, um
Lowlevel zugriffe zu erzwigen, was so gut wie keiner macht und im
Tomcat umfeld schon gar nicht). Daher läuft ein bereitgestellter
Code oder ein Codebeispiel immer 100% auf jeder JVM und man
hat keinen Stress mit JVM oder PS spezifischen Restriktionen zu
kämpfen. Write once, runs everywhere and ever. Das macht jede
Programmentwicklung sehr nachhaltig und lässt einem zur ruhe kommen
und auf die Features statt auf so unnötige Dinge wie OS / JVM
Spezifika rücksicht nehmen zu müssen.

Last but not least:
Tomcat ist dem alten Apache HTTPd im Bereich der Seitenauslieferung
und bei der Geschwindigkeit dynamischer HTML Seiten längst überlegen.
Ein nicht ganz aktueller Java5 vergleich zeigte dies auf eindrucksvolle
weise und bei Java 6 ist noch mal alles 30% schneller geworden.

OOP und mächtige Funktionen:
Bei Java stehen State of the Art Sprachfeatures wie Generics, LinkedLists,
Collections, Mehrfachvererbung, Abstrakte Klassen, Interfaces, Umgang mit
großen Zahlen, Namespaces, Scopes für Sichtbarkeiten und ein ausgeziechnetes, DB unabhängiges Corssplattform Datenbank Interface
parat um einfach und ohne großen Aufwand mal eben auf ORACLE, MySQL,
PostgreSQL , DB, Informix, SQLLite, Sybase u.s.w) zuzugreifen und das
alles auf einheitliche weise. Kein kompilieren, keine Zusatzkosten, alles
for Free.

Fazit:
Du investierst als Kunde bei so einer Platform in weniger Stress, bessere
Performance, grössere Sicherheit und bessere Wartbarkeit.

 

[Albu]

Fazit:
Du investierst als Kunde bei so einer Platform in weniger Stress, bessere
Performance, grössere Sicherheit und bessere Wartbarkeit.

Du scheinst im Marketing zu arbeiten. Zieh' mal die rosa Brille aus.

Außerdem wusste ich bis dato nicht, dass Java plötzlich Mehrfachvererbung unterstützt.

 

[pmvstrm]

Na dann geh mal zu einem Massenhoster, wo die überwiegende Anzahl der KMUs hockt und versuch Dein .war dort zu installieren.

Kann ja sein das sie das bisher getan haben, aber wenn Du für
4 EUR nen VServer in dem Du ohne Restriktionen alles machen und
installieren kannst bekommen kannst, dann wirst Du das in der Zukunft
jeden zusammgezimmerten WEbhostingpaket mit WEbfrontent Assist
vorziehen. Natürlich muss man von Webservern und der Administration
etwas verstehen. Es ist aber auch keine gute Entwicklung das DAU's
überall dran schrauben und dann werden diese Systeme für DDOS und
Wurmepedimien als Schadwerkzeuge mißbraucht.

Versionitis kannst Du auch mit Java haben. Sicherheitslücken machen keinen Umweg um Java und sind, zusammen mit der Performance, direkt abhängig von der Unfähigkeit des Programmierers.

Nein, in Java gibt es keine Versionites. Ich habe noch kein einziges Javaprogramm gesehen, das nicht mehr lief weil sich am Betriebsystem
was geändert hatte und du deswegen dein Programm neu durch den
Compiler jagen musstest. Bei Java können sich Details in den Packages
ändern, das mekst Du aber schon bei der Entwicklung auf deinem
Entwicklungsrechner und wenn Du das dort gelöst hast, läuft es überall
(im Gegensatz zu PHP!!)

- eine VM hat schon gewisse Vorteile, aber daraus automatisch einen Nachteil abzuleiten, ist etwas weit hergeholt.

Wenn man es anhand von NAchteilen/Nutzen aufwiegt, sicher mehr
nachteile, also ein NACHTEIL!

- Dein Wirkungsregellaufkreis ist doch bei einer J2EE Anwendung wesentlich höher als bei PHP.

Unsinn, das genaue Gegenteil ist der Fall! Tomcat ist der meistverwendete
Servletcontainer und damit der Standardweblayer für J2EE. Tomcat bearbeitet
alle Webrequests autonom. Bei Apache+PHP sieht es ganz anders aus.
Apache war nie als WebApplication server gedacht sondern als HTTP-Server
der statische Inhalte ausliefert. PHP ist eine fremde Erweiterung für
den Apache HTTPd und titt somit in ein Wechselwirkungsprinzip zwischen
HTTP und dem eigenlich MOD PHP oder PHP CGI Interpreter. Die Interprozess
kosten sind wesentlich höher, weil es keine gleichförmigen Keisläufe sind sondern verschieden Konzepte die an einem Verbindungspunkt gekoppelt
wurden. Tomcat ist schon in der Entwurfsphase ein in Java geschriebener
Webserver Container der speziell für WebApplikationen, sprich dynamisches
HTML entwickelt wurde, da ist alles aus einem Guß.

Bei entsprechender Konfiguration kann ich nach Ctrl+S in PHP sofort testen, während ich für den Applikation Server erst ein .war kompilieren muss, welches dann auch noch deployed werde muss.

Man sieht, Du kommst nicht aus der Ecke.
Manche IDE's wie IntelliJ oder Netbeans bieten Dir die Möglichkeit
im "Exploded" Mode die Files direkt im Tomcat Root auf Fileebene
zu editiren, da benötigt man zum testen allenfalls ein Reload im
WebBrowser.

- die desaströse Lage ist durchaus richtig, aber es zwingt Dich keiner diese kaputten Skripte zu verwenden. Überhaupt ist die Anzahl verfügbarer PHP Skripte weitaus höher, als die von .war Dateien,

War's sind fix und fertige mit Setup.exe vergleichbare Anwendungspakete
zum installieren der WebApplikation auf Tomcat oder einem anderen 100%
Compliant Servletcontainer z.B Jetty. Das sind keinesfalls Scriptschnippsel.

bzw. fertigen Java Klassen für den Einsatz des unbedarften Webfricklers. Außerdem sind die Hürden für Einsteiger bei PHP wesentlich niedriger als bei Java, es ist deshalb nur logisch, dass die Anzahl schlechter Skripte

Wer von der PHP Seite kommt, kann ja mit JSP's anfangen, die sind
wesentlich besser strukturiert, so einfach wie PHP und verursachen
weniger stress um z.B einen Datenbankzugriff bereitzustellen.

- Codeausführbarkeit hängt immer von OS und Webservereinstellungen ab. Genauso wie Java und ein Appliaction Server ala Tomcat, JRun, und all die anderen als Paket installiert werden müssen, muss auch Apache und PHP als Paket installiert werden, sonst geht gar nix.

Das ist ja das gut. Wenn eine Java Laufzeitumgebung da ist, also JRE
dann, dann ist Tomcat mit allem zufrieden und es gibt keine Dependencies
auf die LIBC, order irgendetwas anderes das man dann nachinstallieren müsste.

1."apache-tomcat.zip unzippen"
2.startup.sh (Linux/Unix) / startup.bat (win)

fertig, keine broken dependencies gedöns u.s.w

- IDEs gibt es auch für PHP (Eclipse oder Dreamweaver um ein paar zu nennen). Das Eclipse Plugin für PHP ist sicherlich nicht auf dem Stand der Java Umgebung, aber zum Skripten völlig ausreichend.

Dazu brauche ich nicht mal Eclipse, da reicht notfalls Notepad.exe
oder VI / Emacs, aber wir sprechen ja von professioneller Entwicklung
und nicht von dem was Scriptkiddies machen.

- Dein Mehrfach Tier kannst Du Dir auch in die Haare schmieren, das ist überhaupt nicht die Zielsetzung einer Skriptsprache wie PHP. Vielleicht solltest Du hier keine Äpfel mit Birnen vergleichen.

Mir war so als ob ZEND in der letzten Zeit seine ZEND Platform genau
dafür positionieren wollte. Lustig finde ich dabei, das sie immer die
verquickung und Side by Side Features zu Java hervorheben ;D

 

[Albu]

Kann ja sein das sie das bisher getan haben, aber wenn Du für
4 EUR nen VServer in dem Du ohne Restriktionen alles machen und
installieren kannst bekommen kannst, dann wirst Du das in der Zukunft
jeden zusammgezimmerten WEbhostingpaket mit WEbfrontent Assist
vorziehen.

Und für die 4 Euro kriegst Du ein performantes System, welches Deine Anforderungen vollends erfüllt? Bandbreite ist auch ausreichend? Uptime, Anbindung, Support ebenfalls?

Es ist aber auch keine gute Entwicklung das DAU's
überall dran schrauben und dann werden diese Systeme für DDOS und
Wurmepedimien als Schadwerkzeuge mißbraucht.

Äpfel und Birnen. Ein DDOS wird eher von versuchten Windows Systemen, als von gehackten Websites ausgehen.

Nein, in Java gibt es keine Versionites. Ich habe noch kein einziges Javaprogramm gesehen, das nicht mehr lief weil sich am Betriebsystem
was geändert hatte und du deswegen dein Programm neu durch den
Compiler jagen musstest. Bei Java können sich Details in den Packages
ändern, das mekst Du aber schon bei der Entwicklung auf deinem
Entwicklungsrechner und wenn Du das dort gelöst hast, läuft es überall
(im Gegensatz zu PHP!!)

Nee natürlich nicht, alle .jar Bibliotheken haben immer die richtige Version. Umfangreiche Java Projekte werden i.d.R. nicht von einer einzelnen Person entwickelt, ohne Versionsverwaltung kommt man da in Teufels Küche. Also nicht zu vergleichen mit Deiner Entwicklungsumgebung aufm Laptop.

Man sieht, Du kommst nicht aus der Ecke.
Manche IDE's wie IntelliJ oder Netbeans bieten Dir die Möglichkeit
im "Exploded" Mode die Files direkt im Tomcat Root auf Fileebene
zu editiren, da benötigt man zum testen allenfalls ein Reload im
WebBrowser.

Wenn man aber keine solche IDE besitzt, dann bleibt nur der komplette Zyklus (wie angerissen), um eine neue Version zu testen.

War's sind fix und fertige mit Setup.exe vergleichbare Anwendungspakete
zum installieren der WebApplikation auf Tomcat oder einem anderen 100%
Compliant Servletcontainer z.B Jetty. Das sind keinesfalls Scriptschnippsel.

Und alle .war Dateien enthalten nur 100% reinen Code, der keinesfalls desaströs sein kann.

Wer von der PHP Seite kommt, kann ja mit JSP's anfangen, die sind
wesentlich besser strukturiert, so einfach wie PHP und verursachen
weniger stress um z.B einen Datenbankzugriff bereitzustellen.

Und die vorher grottigen PHP Skripte werden plötzlich um Längen besser, weil die Sprache gewechselt wurde?
Schlechter Code hat absolut gar nix mit der Programmierspache oder Umgebung zu tun (mit Ausnahme vielleicht von Visual Basic).

Das ist ja das gut. Wenn eine Java Laufzeitumgebung da ist, also JRE
dann, dann ist Tomcat mit allem zufrieden und es gibt keine Dependencies
auf die LIBC, order irgendetwas anderes das man dann nachinstallieren müsste.

1."apache-tomcat.zip unzippen"
2.startup.sh (Linux/Unix) / startup.bat (win)

fertig, keine broken dependencies gedöns u.s.w

In der heutigen Zeit existieren für so ziemlich jede Distribution entsprechende, fertige Pakete für Apache, PHP, Tomcat, mySQL, Postgres, usw. da muss man nichts mehr von Hand installieren, oder sich um Abhängigkeiten kümmern. Selbst für Windows gibt es fertige Pakete.

Dazu brauche ich nicht mal Eclipse, da reicht notfalls Notepad.exe
oder VI / Emacs, aber wir sprechen ja von professioneller Entwicklung
und nicht von dem was Scriptkiddies machen.

Scriptkiddies werden kaum mit VI und Emacs arbeiten und die Unterstützung von PHP in Eclipse ist zwar noch ausbaufähig, aber durchaus brauchbar.

 

[Luz]

Es kann sein, dass Du Dich etwas fest auf die Technik versteifst, was u.U. ein Fehler sein kann. Ich würde mir nochmals Zeitgeist's Frage, was denn das besondere an Deinem Shop sein soll, aus Kundensicht durch den Kopf gehen lassen. (Du hast sie nur aus der Sicht eines Programmierers beantwortet)
Momentan wissen wir:

Module:
Katalog mit Bestellfunktion, Multimandantenfähig, Mehrsprachig,
mehrere Währungen, CMS, Forum, Adminmodul, Schnittstellenmodul
mit erweiterbaren import/export, Barriere freie Gestaltung und Liste
eingebundener Agenturen die Standardtemplates oder Maßanfertigungen
liefern.

Tönt für mich ok. Als Shopbesitzer interessiert mich wohl weniger die technische Umgebung, als vielmehr, welche Umsätze ich mache -> statistische Auswertungen würde ich unbedingt reinnehmen, ebenfalls eine Kundenverwaltung, welche mir gute/schlechte/nicht zahlende etc. Kunden sinnvoll listet; ein Newslettersystem würde sich ebenfalls anbieten. Durch eine vernünftige & schöne Benutzeroberfläche kannst Du Dich vielleicht von anderen Systemen abgrenzen.
Wenn Du Dich an ganz grosse Kunden richten möchtest (was ja gemäss Deinen Anforderungen an ein hochskalierbares System sein könnte ) würde ich noch bedenken, dass die wahrscheinlich ohnehin bereits an bestehende Systeme (z.B. SAP) angehängt sind.

 

[Curtains]

Mich würde auch deine Strategie interessieren, wie du all die vielen Dinge in nützlicher Zeit umsetzen willst.
Nimmst du ein vorgefertigtes CMS Framework und passt es nach deinen Wünschen an? Oder planst du den ganzen Core selbst zu entwickeln?
Als PHP-Programmierer (der es ja bekanntlich "quick, dirty, fast" mag) würde ich ein paar edle Teile (Drupal, WordPress, MediaWiki, ...) aus der Open Source Welt herauspicken, um diese auf einzigartige Weise miteinander zu verknüpfen. Das Resultat wäre dann ein neuartiges System.

 

[pmvstrm]

Als PHP-Programmierer (der es ja bekanntlich "quick, dirty, fast" mag) würde ich ein paar edle Teile (Drupal, WordPress, MediaWiki, ...) aus der Open Source Welt herauspicken, um diese auf einzigartige Weise miteinander zu verknüpfen. Das Resultat wäre dann ein neuartiges System.

Also das scheint doch nur auf´den ersten Blick schneller, in Wirklichkeit ist
es doch so, das jedes dieser einzelnen System für sich alleine laufend
entwickelt wurde. Da braucht jedes Teil ein Backend, die Sessions und
Varaiblen sond ganz unterschiedlich. Die Webservereinstellungen die bei
der einen Version noch fuktionierten, gehen dann im Zusammenspiel mit
den Rest Fragmenten nicht. Das eine setzt schon ganz modern auf
Unicode, OOP und PHP5 und MySQL, das andere ist wie es üblich
ist noch MySQL 3.x /4x lastig.. Du erkennst das Problem oder?

Mit hat mal so ein Stratege den Auftrag gegeben XT Commerce und
seine bereits über zig tausend Zeilen PHP Code über mehrere Jahre
gewachsene Codestruktur zu verheiraten. Anfroderung, bau das
mal da ein und mach das Multimandantenfähig. Davor haben sie
es 2 Jahre schon bergeblich mit vorherigen Mitarbeiten und auch
hochbezahlten Externen versucht. Alles mist, sowas geht selten
gut. XTC wird seid 1999 entwickelt, kannst Dir ja schon denken wie
viele Hacks da drin sind (ca 70.000 Zeilen Code).

Ich gehe so vor:
1.Minimaler Prototyp der Modulartig angelegt wird
2.Dann das nächste Modul und irgendwann steht das Basesystem
3.Sobald das Basesystem steht, kann man die Mechanismen schon
nutzen und wird automatsich schenller.
4.Und da das ganze in Java läuft ist man auch noch produktiver