Alecs, as i said in the first reply, http://code.google.com/p/sfshop/ :)
"sfShop is open source on-line shop e-commerce platform" ... "The platform is available for free under the MIT License. This platform is based on symfony framework." plugins already there. (almost all) it just needs documentation and most of all, collaboration. On Mon, Jun 29, 2009 at 6:26 PM, Alexandru-Emil Lupu <gang.al...@gmail.com>wrote: > it is ok with me. The main ideea is that not to break it to hard. I think > that we could break this plugin in several: > > 1. payment (that i am thinking to be almost like AdoDB. An interface for > the existing / future ) > 2. shopping cart (i think that there is a shoppingCartPlugin, but i haven't > played with it ) > 3. products (where it would be category, products) > 4. billing (you might need to issue billings for other services things that > you are allready using ). I could give the romanian billing format (fields > required and stuff ) > 5. for static pages i think that there is a plugin as well > 6. Stats could be separated (because it could be implemented in different > other projects like blogs, albums ) > 7. user reviews must be standalone ( check pct 6 comment ) > 8. maybe wishlist could be separated (with some slight modifications can > become a user album or so) > > this is what i would have in mind... What do you say guys ? > Who has access to sf trac and want's to get involved ? > > Alecs > > > On Mon, Jun 29, 2009 at 5:53 PM, Tom Haskins-Vaughan < > t...@templestreetmedia.com> wrote: > >> >> As I mentioned before, this is where I suggest we think about breaking >> things down into separate plugins. >> >> As an example, I'd suggest creating a catalogue plugin that deals with >> storing the product SKUs. Then we can just pass the SKU id to the cart. >> That way, if someone finds that the catalogue function is to limiting, >> then he can add his own as long as long as he passes SKUs or the >> equivalent. >> >> What do people think? >> >> Alexandru-Emil Lupu wrote: >> > ehhh too much chat... >> > why don't we just start and make it ? I'm sure that we could write a >> > sf1.2 propel & doctrine plugin... >> > From my point of view, we would need some db tables and actions. >> > >> > tables: >> > - productCategories ( a table that will keep the product types ex: >> > notebooks, desktops, LCD's) >> > - productDetails ( a table with all the product details ) >> > - staticPages (for disclaimer and so) >> > - productReviews (some comments for that product) >> > - productManufacturer ( we keep the producer's name ) >> > - productPrices (to keep a count of some discounts ) >> > - productStats ( some product stats, how many time bought, visited, ) >> > - productWishList () >> > - userBills (we keep the Track of the money :D ) >> > - productStock ( we keep the inventory of the products ) >> > - userBillingAddresses (for multiple billing addresses ) >> > - userCart >> > >> > === maybe they are way to many or way to less, but is a start === >> > some actions: >> > - product details >> > - product listing by category >> > - view my shopping cart >> > - checkout >> > - pay (here can be implemented some plugins like ogone, e-payment, >> > paypal and others - someone heve to do them) >> > - my billings >> > - bill details >> > - add to wish list >> > - list wishlist >> > - edit wishlist >> > - buy >> > - see reviews >> > - add reviews >> > - vote this product >> > >> > And there can be plenty of those pages. >> > Alecs >> > >> > On Mon, Jun 29, 2009 at 12:29 PM, Lee Bolding <l...@leesbian.net >> > <mailto:l...@leesbian.net>> wrote: >> > >> > >> > >> > On 28 Jun 2009, at 00:13, Marius Rugan wrote: >> > >> > > having tried implementing magento, two times until i dropped it >> out >> > > completely, i can say for me it didn't work because whatever you >> do, >> > > it's too damn slow. You need a virtual machine 1GB+ RAM and up >> with >> > > all the possible tinkering under the hood still is java-like >> slow. >> > > To me it's not acceptable >> > >> > Really? I've been developing with Magento in a 384MB VMWare image >> for >> > MONTHS and it's fine... I even saw a Zend guy benchmark Magento >> > running on his crappy Lenovo laptop at 200 pages/sec. Not sure what >> > you're doing wrong there... >> > >> > On 27 Jun 2009, at 21:21, Pablo Godel wrote: >> > >> > > I think it could do better than others, including Magento, >> > > which has tons of features, but it is slow and complex. >> > >> > Ironically, these are the exact same reasons many people don't adopt >> > Symfony. I don't think that's a particularly compelling reason. Why >> > not use CI or Kohana? they're MUCH faster :) >> > >> > But, luckily - AS AN END USER - you don't CARE what framework an >> > application is built upon. >> > >> > If you want to go ahead an make a Symfony based ecommece solution, >> > then go ahead. But I *really* recommend you do some due diligence >> and >> > make *exhaustive* research into the existing solutions available - >> and >> > compare these from the perspective of an end user - before you begin >> > coding. >> > >> > >> > >> > >> > >> > >> > -- >> > As programmers create bigger & better idiot proof programs, so the >> > universe creates bigger & better idiots! >> > I am on twitter: >> > http://twitter.com/alecslupu >> > I am on linkedIn: http://www.linkedin.com/in/alecslupu >> > Tel: (+4)0748.543.798 >> > >> > >> > > >> >> >> > > > -- > As programmers create bigger & better idiot proof programs, so the universe > creates bigger & better idiots! > I am on twitter: > http://twitter.com/alecslupu > I am on linkedIn: http://www.linkedin.com/in/alecslupu > Tel: (+4)0748.543.798 > > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "symfony users" group. To post to this group, send email to symfony-users@googlegroups.com To unsubscribe from this group, send email to symfony-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/symfony-users?hl=en -~----------~----~----~----~------~----~------~--~---
