ich brauche in der Firma einen Webshop und soll mich da mal einlesen.
Hat hier jemand schon Erfahrungen auf dem Gebiet. Was ist sinnvoll (ich bin ja eigentlich für Open Source), aber erst mal soll was von der Stange genommen werden.
Kann hier jemand was empfehlen. Schön wäre, wenn Seiten manuell (auch die Kaufprozesse) angepasst werden könnten (z.B. Produkt-Detailseiten, Pflichtfelder ect. hinzufügen).
Kennt jemand gute Open Source Webshops (PHP, Java und / oder .NET)?
Danke schon einmal im Voraus für etwaige Antworten.
Wenn man davon ausgeht, dass sich die Aufrufe (ggf. über einen längeren Zeitraum oder gar über die ganze Anwendungszeit hinweg) stauen, dann ist von der Methode abzuraten.
Kommt es aber nur vorübergehend zu solchen Warteschlangen, hier Anfragen minimal im Sekunden-, und nicht im Millisekundenbereich, dann kann man MethodImplOptions.Synchronized imo ohne Bedenken einsetzen.
Also ich benutze bei kleinen Projekten nur noch XML.
Bei einem aktuellen Projekt stellte sich die Frage auch, da ich das Programm auch weiterreichen möchte und ich benutze auch hier XML, obwohl die Größe, Maximalfall, 30 MB! erreichen kann.
Ich konnte aber keine signifikanten Performance-Probleme feststellen - bei 30 MB sind schon eine Menge Daten enthalten.
Ich hätte das erst nicht für möglich gehalten, ist aber so. Da keine Transaktions nötig sind und es sich um eine Single-User-Anwendung handelt, bekomme ich das auch ohne Datenbank mit LINQ ganz gut hinne.
... und dann braucht beim Fat-Client nicht extra eine Datenbank installiert, bzw. hochgezogen werrden.
Bei einer Webanwendung würde ich aber trotzdem immer eine Datenbank nehmen, da die ja nur einmal vorhanden ist - also nix mit öfter aufsetzen, bzw. installieren.
Transaktions + Multiuser-Zugriffe haste frei Haus ... und wenn Du mit LINQ weitermachen willst, bzw. dich einarbeiten, dann kannst Du das auch benutzen, Stichwort LINQ to SQL / LINQ to Entities
Ups .. habe gerade gesehen, das ja der Nils ... Hallo, altes Haus .. Gruß rüber nach Bamberg!
Ich mache das immer auf die "althergebrachte Art" mit IConfigurationSectionHandler - hatte damit noch nie Probleme. Bekomme eben den kompletten Knoten und muss mich halt dann selbst ums Mapping kümmern.
In C (oder C++) ist es jederzeit möglich, eine physikalische Speicheradresse auf einen Pointer zu mappen. Dieser kann dann auf Instanzvariablen usw. des Objektes zugreifen.
Man könnte, jetzt mal den Sinn einer solchen Aktion außer acht gelassen, einer statischen Methode die Speicheradresse übergeben.
Ist aber in C# nicht möglich, denn ...
Zitat
... in C# pointer can only be declared to hold the memory address of value types and arrays... Quelle
Die 0.001% wären doch eine (aber nicht die) Lösung auf die Ausgangsfrage des Threaderstellers. Jetzt habe ich mich gefragt, ob dies überhaupt in C# möglich ist.
Komme ich via C# von einer Adresse auf einen Pointer und dann auf z.B. ein Property?
LOL, genau das war der Grund, warum meine E-Mails gegenwärtig überprüft werden, bevor ich die zum Kunden schicken darf ... naja, so krass ist es nicht, aber da hat es schon gewaltig gescheppert bis nach ganz oben.
Die bringen auch Fehler zurück in einer ErrorCollection, wo dann als Text sehr oft drinnen steht, dass ein Fehler passiert ist, aber nicht näher spezifiziert. So nach dem Motto, immer der gleiche Fehlercode und die Meldung, Hallo, es ist ein Fehler passiert.
Der absolute Hammer ist, dass die die Fehler mitloggen in der DB und ich als Benutzer muss dann anrufen und ggf. manuell eingreifen, bzw. Fragen, welcher Fehler denn bitte aufgetreten ist.
Auch verrückt ist, dass die öfters die Datenbank (Oracle) durchstarten müssen, danach geht es (andere Fehler, nicht die Threadproblematik) dann wieder 8o ?( HALLO!
{Connection: close
Content-Type: text/xml;charset=utf-8
Date: Fri, 19 Mar 2010 09:37:35 GMT
Server: Apache-Coyote/1.1}
Im Original:
HTTP/1.1 500 Internal Server Error
Server: Apache-Coyote/1.1
Content-Type: text/xml;charset=utf-8
Date: Fri, 19 Mar 2010 09:37:35 GMT
Connection: close
Die Fehlermeldung (also HTTP-Response-Body) fehlt:
<?xml version="1.0" encoding="UTF-8"?><soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"><soapenv:Body><soapenv:Fault><faultcode>soapenv:Server.userException</faultcode><faultstring>org.xml.sax.SAXParseException: An invalid XML character (Unicode: 0x1b29e0) was found in the element content of the document.</faultstring><detail><ns1:hostname xmlns:ns1="http://xml.apache.org/axis/">gtprint-test</ns1:hostname></detail></soapenv:Fault></soapenv:Body></soapenv:Envelope>
gibt es eine Möglichkeit, genauere Fehlermeldungen zu bekommen, wenn z.B. als Response HTTP-StatusCode 500 (Internal Error) geliefert wird.
Ich kann diesbezüglich in dem Exception-Objekt nichts finden.
Untersuche ich den Response mittels Sniffer, dann sehe ich die Fehlermeldung.
Welche Möglichkeit gibt es hier?
Wichtig bei mir ist das aktuell, weil ein Kunde bestimmte Exception im Programm nicht handelt, so könnten wir zumindest sehen, ob es sich um einen Fehler des Ziel-Systems (z.B. Datenbank nicht ansprechbar) handelt oder um fehlerhafte Requestdaten des Clients.
Vielen Danke für evtl. Antworten schon einmal im Voraus.
Erst mal vielen Dank für eure Anregungen und Hilfestellungen.
Das Problem wurde nun ausfindig gemacht, dank Sniffer via WireShark.
Bei jedem Request wird der Envelope im UTF-8-Format erwartet, und die Attachments in Latin-1-Kodierung.
Axis verschlüsselt Sonderzeichen, die nicht explizit als UTF-8 kodiert sind, mittels der Entity-Schreibweise, z.B. wird aus einem ü
&XFC;
Bei den Attachments wird mittels AXIS immer der Latin-Code-1, welcher hier beim ü, auch der gleiche wie bei UTF-8, nämlich FC ist.
Ich habe natürlich bei den Anfragen im Envelope gleich UTF-8 genommen, denn warum soll ich Filtern, es gibt zig Namen, die Sonderzeichen besitzen usw.
Das bedeutet, dass z.B. ein ü im Envelope und in den Attachments als FC übermittelt werden.
Nun muss den Leuten, die die Schnittstelle zur Verfügung stellen, das auch schon aufgefallen sein, und die haben angefangen zu filtern - denn, bei allen bis auf zwei Elementen, funktionieren Sonderzeichen.
Bei den zwei Elementen gingen übrigens nur das kleine ü und das kleine ö nicht - wahrscheinlich im Filter vergessen oder Copy-und-Paste-Fehler.
Die Fehlermeldung, also der Internal Server (500) Error war:
An invalid XML character (Unicode: 0xfc) was found in the element content of the document.
Wirklich sehr peinlich, denn 0xfc steht für ein kleines ü sowohl beim Latin-1-Code, wie auch im UTF-8-Code.
Dieser Fehler (+ Fehlermeldung) hat es somit in meine TOP-5 der verrücktesten Vorfälle in meiner fast 10 jährigen Programmierlaufbahn geschafft.
wenn ich ganz ehrlich bin, dann verstehe ich das auch alles nicht mehr.
Das Java-Programm läuft auf einer Windows-Kiste und auch der Server.
Man kann es kurz auf den Punkt bringen:
Ich lese aus einem File eine XML ein (UTF-8-Encoding) und baue damit den Request zusammen. Steht in einem bestimmten Element ein Umlaut, dann kracht es, lösche ich den raus aus dem File und lasse das Programm wieder laufen, dann geht es.
Öffne ich jetzt wieder das File und schreibe einen Umlaut rein, dann kracht es wieder.
Wie gesagt, bezieht sich das alles nur auf ein bestimmtes Element - bei allen anderen gibt es keine Probleme mit den Umlauten.
Noch verrückter ist, dass z.B. morgen oder übermorgen genau das File dann doch geht, also mit Umlauten in dem einen bestimmten Feld.
Ja, das ist soz. der völlige Wahnsinn! (und verstehen muss es nun wirklich niemand)
was ist denn der Unterschied zwischen Request A und Request B?
Hallo MrSparkle,
Wie oben beschrieben, Request a hat Apostroph drinnen und funzzt nicht und in Request b wurde das Apostroph reinkopiert und funktionierte das.
Ich habe den Fehler jetzt gefunden. Immer wenn in einem ganz bestimmten Feld im Attachment-XML ein Umlaut steht (oder sonstige Sonderzeichen), dann knallt es. Kurios ist, dass es manchmal einenen halben Tag später geht und dann wieder erst zwei Tage später, bzw. bei anderen Requests das völlig OK ist. Es kracht aber nur bei dem einen Feld (das nicht mal verwendet wird) ... bei Sonderzeichen, bzw. Umlauten in anderen Feldern (Straße, Ort ect.) fuzzt es und es wird auch das PDF richtig generiert.
Ich habe das weitergeleitet, das können die ausmachen. Ich bin hier mit meinem Latein am Ende. Bin echt mal gespannt was da zurückkommt.
Was erschwerend noch hinzukommt ist die Tatsache, dass es eben beim Java-Programm immer geht.
Das einzige was mir noch einfällt wäre Caching-Problem, aber da habe ich auch schon "rumgespielt" mit den Eigenschaften auf no-cache usw.
1. Request A hat Apostroph im Request -> Aufruf schlägt fehl (Internal Server Error HTTP-Code 500)
2. Request B wird der Name von Request A, also mit Apostroph hinzugefügt -> Aufruf ohne Fehler, Apostroph steht im PDF File
3. Jetzt wird es total verrückt. Request A Apostroph wird ersetzt mit XXX -> Aufruf ohne Fehler, PDF Files OK (natürlich steht da XXX)
Jetzt bin ich völlig verwirrt, denn es liegt bei Request A am Apostroph, der aber nicht zu einem Fehler bei Request B führt 8o
Hat jemand schon einmal eine ähnliche Erfahrung gemacht, denn ich komme hier definitiv nicht weiter.
Ich dachte dann noch, dass es ein Caching-Problem ist, was ich jetzt definitiv ausschließen kann, da vorhin auf Anfrage der Server neu gestartet wurde.
Es gibt hier zwei Möglichkeiten, je nachdem, was Du dann weiterhin vorhast:
1, wie User Marduk schon angesprochen:
Du untersuchst den Quellcode, also hier speziell schaust Du dir die JavaScript-Methode callPublish an und rufst diese und nur diese auf und wertest das Ergebnis aus
... oder
2, Du navigierst mit dem Internetexplorer applikationstechnisch, über einen nicht sichtbaren IEXPLORE-Prozess im Hintergrund auf die Ausgangsseite, holst Dir das DOM des XHTML-Dokuments und clickst applikationstechnisch auf den Button und liest dann, nachdem XmlHttpRequest (oder AJAX, wie das seit Web 2.0 heißt) die Seite aktualisiert hat, eben diese dann aus.
Was bedeutet das konkret? Klappt es oder nicht oder nur manchmal? Üblich ist meistens ISO-8859-1 oder ISO-8859-15 (mit €-Zeichen).[/quote]
Sorry, ich meinte schon Latin-1 (aka ISO-8859-1). Die Typen können mit meinen Fragen nichts anfangen, die haben null Plan - die haben den Service programmieren lassen und das erstellen der PDFs läuft bei denen intern über einen dritten Anbieter. Die schreiben wirklich in ErrorCollections rein, wenn ein Fehler passiert ist die ErrorMessage, Error occurred (das wars, nix weiter!). Es ist zum verzweifeln.
Problem ist halt, warum die sich so langsam bewegen, dass intern eine funktionierende Javalösung vorhanden ist, die quick 'n' dirty "hingezaubert" wurde ... ich darf das jetzt "saubermachen" ... würde das auch gern, aber kann ich ja nicht. Das kann 1000 Gründe haben!
Der Ansprechpartner hat mir vorhin bestätigt, dass die Requests richtig sind, also bei Ihnen generiert werden kann und auch heute Vormittag in Produktion ist es auch gegangen, nur wenn ich dann mit .NET "daherkomme" funzzt das nicht (immer).
ja, ich verstehe es auch nicht, ich mache seit Jahren alles über UTF-8, aber es gibt ja Sachen "da draußen" ... X(
verstehen muss er das aber irgendwie schon, denn mit der Java-Lösung gibt es diesbezüglich überhaupt keine Probleme.
Encoding-Default ist bei mir Windows-1252 - Western Europe.
Wenn ich es explizit mit ISO-8859-2 probiere klappt es auch, also PDF passt mit Umlauten, bis eben immer zu den oben genannten Zwischenfällen, dann geht der Aufruf mit 500er Statuscode gar nicht erst (nie) durch.
Aufgrund des Requests werden die Dokumente auf dem Zielsystem generiert und im Response an den Client gesendet.
Problem ist wirklich, und jetzt trage ich hier nicht dicke auf, dass ich für manche Requests den Internal Fehler bekomme und dann für den absolut identischen 10 Minuten später durchkomme - bei manchen, wie eingangs erwähnt, komme ich nich durch (immer 500, wobei das total schwach ist, das bedeutet, dass die Anwendung, an die der Server weitergeleitet hat, hier Tomcat an Servlet, eine unbehandelte Ausnahme wirft ... leider gibt es hier nix, was gelogged wird - aufgrund einer Nachfrage, werden genau diese, also HTTP-Status 500, gar nicht mitgelockt, sind also dem System völlig unbekannt).
Die Requests sollten eigentlich, nach Rücksprache richtig sein.
Problem ist hatl, dass es mit Java läuft, ist ein auf Java optimierter SOAP, also verwendet Java-spezifische Objekte, so dass ich eben das Zeugs plain via SOAP und parsen der Boundaries durchführen muss.
Bei der Java-Lösung ist nix besonderes, außer, dass die Attachments auf der Festplatte in Form von XML-Dateien (ANSI-Default) zwischengelagert werden und AXIS dann den SOAP-Request zusammenbaut, der aber dann hinterher genau so wie der von mir gepostet aussieht, also Axis nimmt bei Java die Arbeit ab, was auf .NET-Ebene WCF machen würde.
ich kann es leider nicht zu 100 % sagen ob es am Encoding liegt.
Es gibt folgenden Sachverhalte nochmal kurz zusammengefasst:
Ich schicke immer den Request mit Encoding.Default, dann passen auch immer die PDF-Dokumente (also die Umlaute), aber nur dann, wenn der Request auch durchgeht, das bedeutet, wenn kein 500-er HTTP-Statusmeldung (Internal Server Error) kommt.
Schicke ich dagegen den Request mit Encoding.UTF-8, dann kann ich zwar immer den Server aufrufen (also kein 500er Error), aber hier passen die Umlaute dafür nie!
genau das mache ich ja, ich werte die Boundaries (PDF-Attachments + XML-SOAP-Response-Envelope) aus.
Ich schreibe alles in den Boundaries, die nicht im ersten (hier SOAP-Envelope) mit BinaryWriter wech und das passt auch zu 95 Prozent, nur eben nicht zu 100 Prozent.
Kann mir vielleicht auch mal jemand sowas erklären, wie kann das gehen? Binär und XML-Encodierung Latin-1? 8o
------=Path-Separator
Content-Type: application/octet-stream
Content-Transfer-Encoding: binary
Content-Id: <order-attachment-1>
<?xml version="1.0" encoding="iso-8859-1" standalone="yes"?> ... usw, Content von Attachment für Request ...
Oktett bedeutet doch, dass jedes Zeichen aus genau 8 Bit besteht, oder?