CONTENIDO Forum

Die Einbindung auf Artikelbasis hätte zudem den Vorteil, dass dadurch die Produktbeschreibungen durch die "class.search.php" mit in die Keywordliste aufgenommen werden. Die Produktbeschreibungen können dann ohne Anpassung durch das (in der 4.6.x) enthaltene Suchmodul ausgewertet werden. Für alle anderen Daten (Artikelnummer, Preis, ...) oder evtl. auch später bei Artikelvarianten sollte man eben auf andere DB-Tabellen zurückgreifen. Eine Einbindung in die Artikel ließe sich dann vielleicht durch neue CMS_TYPEs (z.B. CMS_PRICE[1], CMS_ARTNUM[1]). So ließen sich die Produkte sehr gut durch entsprechende Artikellisten darstellen, sogar mit Filtern (z.B. "Preis 10-30 Euro").
Aber ich gehe vielleicht schon etwas zu stark ins Detail...

kein problem. genau solche diskussionen sind gefragt. bist du bei der entwicklung mit von der partie?

kummer hat geschrieben:kein problem. genau solche diskussionen sind gefragt. bist du bei der entwicklung mit von der partie?

Ja, bisher hattest du aber nur eine E-Mail von mir bekommen.


Gruß

Ingo

na, falls dieser Punkt noch Diskussionsbedarf hat, würde ich mich für eine Lösung OHNE Plugin/Erweiterung aussprechen. Das wäre perfekt für all diejenigen, die nur eine geringe Artikelzahl anbieten wollen, und dafür nicht extra osCommerce oder ähnliches installieren und integrieren wollen (wie z.B. mich ,-)).

Ansonstens kann ich mich nur vorbehaltlos kummers Ausführungen und Ideen anschließen...

Ich spreche mich auch für einen Shop auf Basis von Artikeln aus.
Ansonsten würde ich conShop viel eher als Integration eines Subsytemes verstehen, als eine Erweiterung des CMS selbst.

Weiter finde ich Dodger77's Ansätze sehr gut.

ich schliesse mich wiederum dodger und kummer an ich denke sonst würde irgendwann einmal ein "shopsystem mit cms" und nicht wie angedacht ein "cms mit einer shopfunktion" . Desweiteren denke ich das mit den Artikeln ist doch ne gute Lösung und wenn man sich mal im Forum umschaut gibt es da die eine oder andere Site die auch schon Ihr 10.000 Artikel und mehr hat von daher mache ich mir keine sorgen um die Größe.

Aber ich bin nur der Kaffeemacher und Pausenclown, aber wenns Aufgaben gibt bitte melden .

greets

die wirds bestimmt geben. besten dank im voraus!

ich würde auch gerne was dazu beitragen. auch wenn miene zeit, wie bei den meisten von euch wohl eher eingeschränkt ist und meine php-künste ledigtlich den status fortgeschritten erfühlen. in oop könnte ich auch noch nachhilfe gebrauchen .

was mich jetzt noch interessieren würde, ist der ca. (ich weiß wir stecken da noch in den kinderschuhen und wie oben schon erwähnt ist die zeit für alle knapp) geplante realisierungszeitraum.

wie wohl die meisten hier, bräuchte ich so eine lösung eher heute als morgen

meine mail findet ihr unten.

gruß
funomat

Würde es eventuell interessant sein, Schnittstellen zu Bezahldienstleistern à la Firstgate zu implmentieren? Oder ist das eher weniger interessant? Wir haben so etwas mal in purem Java realisiert. War nicht ganz ohne. Eventuell hier über einen Web-Service?

wenn möglich ja. allerdings müssten sich solche lösungen modular einbinden lassen. dann fällt es einfacher, in zukunft andere systeme zu integrieren.

Tja und da könnte man ja mal schauen, wie xtCommerce das macht ...

Gruß
HerrB

die threads zur shopanbindung, z.b. auch der zur 'Hochzeit' interessieren mich schon seeeeeeeeehr, bis dahin bleibe ich bei meiner lösung osc content über ein script in contenido einzubinden

guckt ihr z.b. hier oder in meiner signatur des current development

dazu gibt es wie bereits in einem anderen thread beschrieben eine osC contribution (oder besser ein script mit readme, denn mehr ist es ja nicht) vieleicht lässt sich da was verwenden/modifizieren/einbauen.

somit kann ich meinen content über contenido pflegen, und die volle shopfunktionalität nutzen. und da ich den shop über eine warenwirtschaft befülle incl artikelbeschriebungen blder etc, ist osc einmal aufgesetzt und wird danach nicht mehr angefasst.

Hallo mvf,

so wie ich das rauslese, soll es gar nicht so umfangreich sein wie OSC.
Es soll einfach die Möglichkeit geben IN Contenido eine Shopfunktionalität zu nutzen.
Für größere Shops ist die Möglichkeit der "Hochzeit" sicherlich interessanter.

ich habe mir mal ein paar gedanken darüber gemacht, was zu einem produkt konkret für daten gespeichert werden sollen, die nicht in einem normalen artikel gespeichert und verwaltet werden können. die folgende aufzählung ist nicht notwendigerweise abschliessend, dient für mich allerdings vorerst für die erstellung des beiliegenden erd.

1. artikelbezeichnung (mehrsprachig)
2. artikelnummer
3. preis
4. währung
5. mehrwertsteuerklasse
6. optionen (schlüssel-werte-paare, mehrsprachig)

ich möchte an dieser stelle betonen, dass es bei obiger aufzählung als auch im unten publizierten erd nur um den artikel selber geht. also noch keine zahlungen, kein warenkorb und keine kundendaten. die kommen allesamt erst später.

so prima vista gehe ich davon aus, dass damit alle daten abgedeckt werden, die nicht über die cms-kernfunktion erfasst werden. bilder und texte können ja ohne weiteres immer zum artikel gespeichert werden.



von dem teammitgliedern (und das sind inzwischen hoffentlich so einige) wären jetzt folgende zwei fragen zu klären, respektive zu diskutieren:

1. was fehlt in obiger liste, respektive im erd? (nur in bezug zum produkt selber)
2. wer wäre bereit, sich der programmierung der produktklasse anzunehmen? eine api-definition sowie eine klassenvorlage mit den publc-methoden würde ich zur verfügung stellen.

wenn sich jemand findet, der sich dieser aufgabe annehmen möchte, wäre ich froh, um entsprechende meldungen im forum. ich wäre auch froh, wenn der- oder diejenige mir auch gleich einen zieltermin für die fertigstellung der klasse angeben könnte. ich weiss, das ist etwas viel verlangt. die frage des termins stellt sich allerdings immer wieder und wir sollten in der lage sein, wenigstens für einzelne teile des projektes zeitauskünfte geben zu können.

ohne auch zu wissen, was konkret zu machen ist, will sich dieser aufgabe wohl kaum jemand annehmen. deshalb ein kurzer abriss der klasse:

• überprüfung, ob die tabelle in der datenbank besteht
• gegebenenfalls die tabelle anlegen
• aufnahme aller obigen daten (über public-methoden)
• speicherung der daten in der datenbank
• einlesen der daten aus der datenbank aufgrund eines oder mehrerer folgender kriterien: pk_product, produktbezeichner, artikelnummer sowie idart (habe ich im erd noch vergessen, wird aber nachgereicht werden)
• rückgabe der daten (über public-methoden)

so, ich hoffe, ich habe niemanden verschreckt. also bitte melden, wer interesse hat, sich dieser aufgabe anzunehmen.

mfg,
andreas

kummer hat geschrieben:ich habe mir mal ein paar gedanken darüber gemacht, was zu einem produkt konkret für daten gespeichert werden sollen, die nicht in einem normalen artikel gespeichert und verwaltet werden können. die folgende aufzählung ist nicht notwendigerweise abschliessend, dient für mich allerdings vorerst für die erstellung des beiliegenden erd.

1. artikelbezeichnung (mehrsprachig)
2. artikelnummer
3. preis
4. währung
5. mehrwertsteuerklasse
6. optionen (schlüssel-werte-paare, mehrsprachig)

Hallo Andreas,

was ist denn mit Farbangaben, Größen, Ausstattungsmerkmalen wie: 5 MB, 15MB, bzw. Versionen WIN, MAC, Linux, bzw. Boxprodukt, Download-Version oder anderen Artikelmerkmalen?