conShop
conShop
hier also wie verprochen der thread von den shop. interessenten bitte melden (mit interessenten sind leute gemeint, die fähig und willens sind, an diesem projekt mitzuarbeiten).
aitsu.org :: schnell - flexibel - komfortabel :: Version 2.2.0 (since June 22, 2011) (jetzt mit dual license GPL/kommerziell)
gebt doch bitte auch gleich die email an. dann fällt die kontakt-aufnahme etwas einfacher.
aitsu.org :: schnell - flexibel - komfortabel :: Version 2.2.0 (since June 22, 2011) (jetzt mit dual license GPL/kommerziell)
ich hoffe, es ist nicht beängstigend, die email anzugeben.
aitsu.org :: schnell - flexibel - komfortabel :: Version 2.2.0 (since June 22, 2011) (jetzt mit dual license GPL/kommerziell)
-
- Beiträge: 1536
- Registriert: Fr 20. Aug 2004, 10:07
- Kontaktdaten:
alles klar. eine aufgabe findet sich für (fast) alle. hauptsache man kann die leute auch kontaktieren.
ich bin mir bewusst, dass viele ihre email nicht angeben möchten wegen spam und so. allerdings ohne ist es mir schlicht nicht möglich, die koordination einigermassen durchzuführen. alleine über das forum ist das nicht zu machen.
wer also die email hier lieber nicht publizieren möchte, soll mir doch einfach eine email mit dem betreff conShop senden.
ich bin mir bewusst, dass viele ihre email nicht angeben möchten wegen spam und so. allerdings ohne ist es mir schlicht nicht möglich, die koordination einigermassen durchzuführen. alleine über das forum ist das nicht zu machen.
wer also die email hier lieber nicht publizieren möchte, soll mir doch einfach eine email mit dem betreff conShop senden.
aitsu.org :: schnell - flexibel - komfortabel :: Version 2.2.0 (since June 22, 2011) (jetzt mit dual license GPL/kommerziell)
also, da ich selber einen Shop bräuchte, und "prinzipiell" ebenfalls dabei bin, einen zu schreiben, kann ich meine begrenzten Fähigkeiten auch gleich hier anbieten: michfress@avanitas.de
PS. Spam kann man eh nicht verhindern und Spamassassin arbeitet zuverlässig. ,-)
PS. Spam kann man eh nicht verhindern und Spamassassin arbeitet zuverlässig. ,-)
"Es wird keine Handlung geben, keine Geschichte mit ihrer Versprechung auf einen Anfang und ihrer Hoffnung auf ein Ende." (Andrzej Stasiuk)
-
- Beiträge: 5478
- Registriert: Di 2. Mär 2004, 21:11
- Wohnort: Halchter, wo sonst? ;-)
- Kontaktdaten:
Andreas, ich weiss nicht, ob sich seit deinem Posting was geaendert hat, aber alle Leute, die geantwortet haben, haben den e-mail-Button unter ihrem Beitrag, so kannst du die erstmal kontaktieren, dazu muessen sie nicht im Klartext die Mailadresse angeben. Danach koennt ihr euch ja direkt ueber Mail austauschen.
Re: conShop
Hallo,
also ich möchte so einen Shop ja haben Ich habe zwar keine Ahnung vom Programmieren, aber ich kann testen und auch Webspace und Subdomain (evtl. auch Domain) zur Verfügung stellen falls bedarf besteht.
Es sollte allerdings ein Koordinator sein, der alles lenkt!
Ich schreibe auch gerne eine kleine Anleitung (Installation und Pflege und so weiter).
Also wenn Ihr mich brauchen könnt!?
eMail: shop@aixtraweb.de
also ich möchte so einen Shop ja haben Ich habe zwar keine Ahnung vom Programmieren, aber ich kann testen und auch Webspace und Subdomain (evtl. auch Domain) zur Verfügung stellen falls bedarf besteht.
Es sollte allerdings ein Koordinator sein, der alles lenkt!
Ich schreibe auch gerne eine kleine Anleitung (Installation und Pflege und so weiter).
Also wenn Ihr mich brauchen könnt!?
eMail: shop@aixtraweb.de
Mit freundlichen Grüßen
Jörg Knörchen
Meine Hobby-Webseite:
www.mein-foto-abc.de : contenido 4.6.15 - I love it! : www.yogie.de : www.bastelstun.de
Jörg Knörchen
Meine Hobby-Webseite:
www.mein-foto-abc.de : contenido 4.6.15 - I love it! : www.yogie.de : www.bastelstun.de
super, das sind ja schon einige. über weitere interessenten freuen wir uns alle. also einfach eine kurze email mit betreffe conShop an kummer@w3concepts.ch.
by the way: ich habe ja wie gesagt eher wenig zeit. aber das projekt tönt interessant. ich werde programmiertechnisch wenig beitragen können. die koordination könnte ich - als hobby gewissermassen - übernehmen. aber ich möchte niemandem im weg stehen, der das gerne übernehmen würde.
damit wir nicht ewig auf der gleichen stelle treten, möchte ich die inhaltliche diskussion etwas in gang bringen und aufzeigen, wie ich mir eine zusammenarbeit im prinzip vorstelle. it's not a must, but a proposal. in diesem sinn:
und nun zum eingemachten. die erste frage, die sich stellt (neben dem umfang ganz allgemein ) ist, ob die artikelpflege über ein plug-in, respektive eine erweiterung erfolgen soll oder ob dazu artikel verwendet werden können oder sollen.
ich denke, das ist mithin auch eine frage persönlicher präferenzen. bestimmt allerdings auch den umfang des gesamtprojektes. ich würde eine lösung vorziehen, die von artikeln ausgeht und deshalb ohne erweiterung auskommt. und zwar aus folgenden gründen:
by the way: ich habe ja wie gesagt eher wenig zeit. aber das projekt tönt interessant. ich werde programmiertechnisch wenig beitragen können. die koordination könnte ich - als hobby gewissermassen - übernehmen. aber ich möchte niemandem im weg stehen, der das gerne übernehmen würde.
damit wir nicht ewig auf der gleichen stelle treten, möchte ich die inhaltliche diskussion etwas in gang bringen und aufzeigen, wie ich mir eine zusammenarbeit im prinzip vorstelle. it's not a must, but a proposal. in diesem sinn:
- für ein projekt dieser grösse müsste nach meiner einschätzung die programmierung ausschliesslich objektorientiert erfolgen. und zwar mit jeweils sauberen api-definitionen.
- innerhalb der einzelnen objekte werden grundsätzlich keine globalen variablen verwendet. es steht nur zur verfügung, was in der api-definition angegeben und mit dem konstruktor oder einer public-methode in das objekt übernommen worden ist. auf diese weise lässt sich die funktion eines objektes kontextfrei überprüfen.
- die einzelnen objekte machen keinerlei ausgaben an den browser, sondern stellen ihre attribute mit public-methoden zur verfügung. die ausgabe an den browser erfolgt zentral durch ein einziges objekt, welches die übrigen objekte instantiiert.
- da anfänglich noch nicht sicher ist, wie die einbindung in contenido erfolgt, sollte jede klasse nur unter der bedingung definiert werden, dass noch keine entsprechende definition erfolgt ist. also bitte die klassendefinition in eine if-prüfung mit class_exists einschliessen.
und nun zum eingemachten. die erste frage, die sich stellt (neben dem umfang ganz allgemein ) ist, ob die artikelpflege über ein plug-in, respektive eine erweiterung erfolgen soll oder ob dazu artikel verwendet werden können oder sollen.
ich denke, das ist mithin auch eine frage persönlicher präferenzen. bestimmt allerdings auch den umfang des gesamtprojektes. ich würde eine lösung vorziehen, die von artikeln ausgeht und deshalb ohne erweiterung auskommt. und zwar aus folgenden gründen:
- conShop soll keine konkurrenz zu reinen online-shops werden, sondern genau dort eingesetzt werden, wo tendenziell eine eher geringe anzahl produkte direkt in die website integriert werden sollen.
- bei der pflege als artikel hat man in der gestaltung einer produktseite alle freiheiten, die man gerne haben möchte. eine produktseite kann deshalb genau so aussehen, wie jede andere seite im cms.
- für die produktpflege ist keine weitergehende schulung erforderlich. wenn jemand weiss, wie artikel neu aufzunehmen und zu editieren sind, wird er oder sie auch produkte pflegen können.
- die speicherung der produktdaten (wie z.b. artikelnummer, preis, einheit, währung usw.) kann trotzdem ausserhalb der normalen tabellen erfolgen.
aitsu.org :: schnell - flexibel - komfortabel :: Version 2.2.0 (since June 22, 2011) (jetzt mit dual license GPL/kommerziell)
-
- Beiträge: 1536
- Registriert: Fr 20. Aug 2004, 10:07
- Kontaktdaten:
-
- Beiträge: 1758
- Registriert: Mo 1. Aug 2005, 00:35
- Wohnort: in der schönen Hallertau, mitten im Hopfen
- Kontaktdaten:
hallo community
zugegeben binich was contenido und php angeht Laie, aber vieleicht ist ja genau darum auch mien input nicht uninteressant.
als erstes würde mich interessieren, warum nur für eineige wenige produkte? wenn die funktionalität steht, dann sollte die menge der produkte doch keine frage sein, oder?
desweiteren denke ich, dass nicht unwichtig ist, dass jeder der etwas verkauft auch eine warenwirtschaft und finanzbuchhaltung nutzt/benötigt. oscommerce und xtc sind z.b. mit cao-faktura sehr simple über scripte verbunden.
praxisbezogen denke ich sollte das ziel sein, produkte kunden geschaftsabläufe (rechnungen liferscheine tec.) über eine schnittstelle mit conshop zu verbinden.
wenn bedarf an informationen zu einer warenwirtschaft und shopanbindung wie bei osc und xtc mit z.b. cao-faktura besteht, dann kann ich gerne aushelfen.
fazit: conshop wäre schon klasse, aber am ende des tages will ich meine produkte nicht nur feilbieten und dann einen verkauf generieren, die prozesse die mit einem 'online-verkauf' verbunden sind wollen auch geregelt sein.
just 2cents of a DAU
zugegeben binich was contenido und php angeht Laie, aber vieleicht ist ja genau darum auch mien input nicht uninteressant.
als erstes würde mich interessieren, warum nur für eineige wenige produkte? wenn die funktionalität steht, dann sollte die menge der produkte doch keine frage sein, oder?
desweiteren denke ich, dass nicht unwichtig ist, dass jeder der etwas verkauft auch eine warenwirtschaft und finanzbuchhaltung nutzt/benötigt. oscommerce und xtc sind z.b. mit cao-faktura sehr simple über scripte verbunden.
praxisbezogen denke ich sollte das ziel sein, produkte kunden geschaftsabläufe (rechnungen liferscheine tec.) über eine schnittstelle mit conshop zu verbinden.
wenn bedarf an informationen zu einer warenwirtschaft und shopanbindung wie bei osc und xtc mit z.b. cao-faktura besteht, dann kann ich gerne aushelfen.
fazit: conshop wäre schon klasse, aber am ende des tages will ich meine produkte nicht nur feilbieten und dann einen verkauf generieren, die prozesse die mit einem 'online-verkauf' verbunden sind wollen auch geregelt sein.
just 2cents of a DAU
Grüsse, Guido
"A common mistake that people make when trying to design something completely foolproof is to underestimate the ingenuity of complete fools."
Mostly Harmless - Douglas Adams
"A common mistake that people make when trying to design something completely foolproof is to underestimate the ingenuity of complete fools."
Mostly Harmless - Douglas Adams
soweit bin ich mir dir einer meinung. wie du allerdings weiter ausführst, kommen mit einer grösseren zahl produkte automatisch auch höhere ansprüche. und contenido ist eben ein cms und als solches zwar geeignet, einen shop zu beherbergen. aber du würdest ein versandhaus auch kaum in einer wohnung eines wohnblock unterbringen, nicht? genau so wenig, möchtest du in einer lagerhalle wohnen. die ansprüche sind nicht gleich. wenn eine integration gelingen soll, wird man keinen riesenumfangreichen shop in das cms integrieren.mvf hat geschrieben:als erstes würde mich interessieren, warum nur für eineige wenige produkte? wenn die funktionalität steht, dann sollte die menge der produkte doch keine frage sein, oder?
ich sehe das etwa so: contenido ist ein limousinenservice. da soll es auch mal möglich sein, mehr als einen koffer zu transportieren. zu diesem zweck ist vielleicht ein anhänger gefragt. aber eine limousine ist kein sattelschlepper.
letztlich wird ein reiner online-shop für gehobenere ansprüche (was das volumen und die ansgesprochene anbindung anbetrifft) stets besser geeignet sein, als ein cms mit shop-modul. das soll nun allerdings nicht heissen, dass weitergehende funktionen später nicht hinzu kommen können. aber ich denke, für den start wird das wohl oder übel zuerst aussen vor bleiben müssen.
aber freilich gilt auch hier: it's an opinion, not a fact...
gruss,
andreas
aitsu.org :: schnell - flexibel - komfortabel :: Version 2.2.0 (since June 22, 2011) (jetzt mit dual license GPL/kommerziell)