Hi all, first off, I don't think Magento being too slow is a compelling reason to "rebuild it"... who says building it on SF would be any faster? After all you would want (need) to provide the same or more features and support both doctrine & propel to appease us developers, etc... I've tried Entity-Attribute-Value setups with SF before, and it's no speed demon, especially if you abstract the database. Overall, for all who say that Magento is too complex, that's just what happens with "all in one" packages, they bloat, because you don't know or want to limit what exactly your users want to do with the package.
I think that is the reason that we all found to Symfony - we like to rapidly build separate implementations that fits our individual needs perfectly, rather then picking something that fits us 80% and wrestling with it. And thanks to the granularity of most plugins, building something even as complex as an e-commerce site is not all that daunting at all. That being said, I completely agree with Tom's take on what individual plugins would be nice to have, and that it's important to keep them as separate as possible. That is something I could get behind, and if somebody wants to go the extra mile to put 4-5 plugins together and declare it an e-commerce plugin, that obviously doesn't hurt, but anything more grandiose seems unnecessary to me, and potentially dangerous to the SF reputation if the "Symfony Store" happened to be a total failure. I'd be happy to contribute my experience from building www.skinmedica.com, which is currently flexibly integrated with UPS, Avatax, Mass and ExactTarget. Daniel On Jun 29, 8:26 am, 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 -~----------~----~----~----~------~----~------~--~---
