Ideas

[keymaster]

Sylius is coming along beautifully. The code, and even the organization (google groups, twitter accounts, website, online sandbox....) both seem well thought out.

Congratulations on some really good work.

Wondering if you'd consider publishing a roadmap?

As Sylius develops, more and more people will be considering it as a possibility for ecommerce sites. So, it would be nice to see how you plan to roll all this out.

Also, after working through your online sandbox, I wondered whether you had planned to do any/some of the following:

1. Customer accounts
- checkout with account
- customer panel to view order history, change billing/shipping details.

2. checkout (single page vs. multiple page)
- billing/shipping details, terms, etc. - the standard checkout flow

3. Payments
- interfaces to standard gateways like Authorize.Net, Paypal, Google CO,  etc.

4. Shipping (single warehouse, multi-warehouse)

5. Discounts, coupons

6. Even though you've chosen to implement your own Guard bundle, you might consider making it configurable so people can plug in their own user bundle, as long as it conforms to a certain interface (eg. many people may already have built systems with FOSUserBundle, but might still like to use your bundles)

7. Flexible cart

FWIW, I think the real value in Sylius would be if it could also work with abstract product types (as long as they implemented a common Interface), such that for example a product can be an event ticket, a hotel reservation, a download, a site membership, a recurring magazine subscription, etc.

Users can contribute productTypeBundles which could implement "assortable", "categorizeable", "cartable", "orderable" interfaces (as you define them to be), etc. so the various bundles (assortment, categories, cart, sales, etc.) can work any product type.

So, to plug in a new product type, the developer just implements all the interfaces, plugs in his MyFavoriteProductTypeBundle, and it will work with Sylius.

That would be a very flexible ecommerce system. People could contribute product type bundles which plugin and just work (together with the events/plugins system).

sorry for the blabbler.

Thanks for all your efforts.

[Paweł Jędrzejewski]

Hey keymaster,

Thanks for this post, I am really happy that more and more developers are interested in project. Also thank you for the good words.

And the idea about roadmap, I will definitely work on it.

1. and 2. Sure, there is even some code written for SyliusCheckoutsBudle, I hope I will manage to finish initial version and implement checkout in sandbox app.

Customer panel is a must but I am not sure if it should be part of SyliusSalesBundle or core bundle. I will think about it.

3. There is a SyliusPaymentsBundle but to be honest, I made it for my own needs and I am not so confident if it is a good implementation for Sylius, It is mostly inspired by JMSPaymentsBundle, which I planned to use. Not sure if it will fit with some Sylius architecture concepts. ( I plan to write a documentation part about the general architecture and organization of bundles.

4. Shipping bundle is a big todo, I created repository for it quite long time ago, I will push some initial code soon so maybe somebody will have some ideas about it. : )

5. For sure, but can't say it is top priority now.

6. My testing app when I was starting Sylius was powered by FOSUserBundle and I switched it to guard bundle in like 15 minutes so it's quite flexible.

All of Sylius bundles are completly decoupled, you can use any of them in custom application, not only Sylius, that is one of key concepts behind Sylius.

7. To be honest, I am not sure if I am happy with the current SyliusCartBundle implementation. Your idea looks very cool. After I finish ThemingBundle refactoring ( zip, tar etc. package formats, theme inheritance ) I will focus on the cart system. What you said about product type bundles is great, maybe it can be easily done with tags in di container configuration!

Thank you again and have a nice evening,

Paweł

[Flyingmana]

7. i dont know if putting many logic into the product model itself is a good idea.
My Idea would be to add an ProductType and handle most of the things over events.
maybe only a calculate final price function, the normal showing would be more related to the Product view and listItem templates.

For example i will write a coupon extension, where the customer can chose the value of the coupon/price himself.
Showing the Price on catalog page and on product page on the one side, showing price in cart and checkout on the other side.
First side should be mainly a template part, as the way it is shown depends on the producttype.
Second side we need a final value, so this could be a function on the product model.

Are there any other thoughts or suggestions about this?

[Paweł Jędrzejewski]

7. This is kinda complex topic, what you say Flyingmana sounds good but I would need to see some code example to tell more.

You can simply create class Coupon extends Product and handle it this way. About pricing, there is a plan for separate bundle that will handle it, with twig function and more.

To this functionality must be extracted I think. I have some big changes coming up for many bundles.