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 < [email protected]> 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 <[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 > > > > > > > > > > > -- 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 -~----------~----~----~----~------~----~------~--~---
