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 <[email protected] > <mailto:[email protected]>> 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 > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "symfony users" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/symfony-users?hl=en -~----------~----~----~----~------~----~------~--~---
