We are going to build something like cratejoy.com, but don't want spend lot's of time building which is already builded before for developers.
I was going through sonata and sylius, but not sure if we can build subscription based model with one of them. If yes we can, then which would be best to use? or should we just build complete custom solution, because it involve b2b solution.
What we will be building?
Basically e-commerce software like any os-commerce shopping system, but the only difference is, we will be adding subscription on each product.
So let's say, if you order a product, we will ship it to you every month to your door step.
but we are building this as service, so many people can just create their site and start using our tools to start selling there products.
I might be a little biased towards Sylius, as I work with it constantly - I've tried using Sonata bundles in projects before but failed in making use of them.
Reasons for using Sylius are that it's heavily decoupled and customizable, which is exactly what you want if you need an e-commerce solution that is not the conventional "add product to basket, pay for it once" model.
There are two approaches you can take to use Sylius: Either use the full stack application and customize it, which is the most common approach and better supported. The other approach is to install Sylius like a library rather than an application and build the application and frontend yourself, using Sylius classes and services when you need to (which is what I do).
Things to be careful when using Sylius are that it's still in beta, with breaking changes occurring between releases. Also the documentation is very incomplete or outdated (something I plan to help improve), with the exception of Resource and ResourceBundle - these packages are the most important part of Sylius and are therefore very well documented. For your project, I recommend the first option.
For subscriptions, areas of Sylius you want to look at configuring and extending are OrderBundle, PricingBundle and PaymentBundle. If you're very familiar with Symfony, this should be straightforward.
Related
We're planning a new intranet for our organization. Some part is like a CMS, and there are some custom-made applications.
The Symfony2 CMF distribution looks fine for building the CMS part of the intranet, but other parts like Doctrine, "normal" SQL databases, etc, looks better for the custom-made applications for the intranet.
Because I need common authorization and authentication system for this intranet (against an Active Directory), I supose that I'll get better results building all in only on app. So, can I mix a CMF application with a normal application, and both use the same database (an Oracle DB)?
Yes you can easily mix the CMF with other Bundles. For example the routing allows using both routes from the CMF as well as "static" routes defined in yml files. Also you can easily also add the ORM next to PHPCR ODM. If you use Doctrine DBAL for storage in PHPCR, you can even reuse the same connection configuration with the ORM etc.
In brief yes it is, and I do this in my own Symfony2 project. I combine both SF-SE and SF-CMF bundles.
In fact, with Symfony2 it's very simple (this is just a matter of choosing the most suitable Bundles; SF is a very decoupled framework, which is why I don't plan to migrate to any other solution for the moment), but I'd like to share some of my experience with doing that. Actually the one most important question to think through to make a decision about how to combine both "worlds" is this:
Composer.
After some inquries I found out that since Symfony CMF is (in a way) based on Symfony SE, and not vice versa, it's better to start with the latter, as it contains the most core features (though I did it also in the opposite way, rather not recommended). So just take a SF-SE's composer.json, take a look at bundles from there you need, and then take a look at differences within SF-CMF's composer.json. You should end up with the most suitable set of bundles.
The basic features from these bundles to look-up for are:
MODEL - Doctrine ORM, PHPCR-ODM, or both - if still not sure, don't hesitate to ask a comment, I'll share here my experience furthere.
ROUTING - the primary question here is how flexible routing do you actually need? If not sure, I'd go with standard SF Router, and then possibly replace it e.g. when still on a dev stage.
OUT-OF-THE-BOX CMS FUNCTIONALITY - bundles such as CreateBundle, MenuBundle or MediaBundle may help you building surprisingly fast, but not quite flexible soltions. In general, I ended up without using most of them, and if using, then I mainly take some Interfaces I do implement in my own Bundles (to ensure future compatibility with possible other bundles to be potentially used).
Besides of these above, I created a number of Bridge Design Pattern and Provider Design Pattern solutions to make some bundles working together, to adjust their functionalities, or simply to decouple things.
In programming almost everything is possible. But think about restrictions delivered with CMF (routing for eg.).
Maybe you should consider Standard Symfony with Sonata? I think CMS pages it's only small part of your system and implementation it in standard symfony will take smallest part (and cost) of whole project.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
We're developing an e-commerce application with Symfony2. It will have different features like product, sales, customer, shipping management, etc..
And it will have 3 subsystems: Web Frontend, Admin and a RESTful API.
Should we organize our bundles by features or by subsystems?
Well, it's your choice! Traditionally, if you explore the vendor bundles that Symfony comes with and the 3rd-party bundles that are available, they are organized by feature.
For example, the Sonata Project starts with a core bundle and provides features in each of the other bundles.
What you should be more concerned about when splitting your system up into bundles is finding a way to de-couple them from the other bundles so that they can be re-used in other projects with minimal modification but more configuration instead! Your best approach (just an opinion of course) will be to make all of these features individually in the bundles and tie them all together with another bundle.
You may find that answers will become subjective depending on each developer's view on the matter.
We've developed an e-commerce solution with Sf2 and at the beginning we asked ourselves the very same questions. Should we organize our bundles around entities or sub-systems(admin, front …) ?
We decided to go for the features/entities solution and we embedded the sub-system in the bundle.
What made us take this decision is the possibility to attach functionalities to the core feature.
For instance, we created bundles like product, catalogs, order, customer … these are the basic bundles that you will find in any e-commerce solution. We also implemented a core bundle that ties them up.
But some of our client may want to use more functionnalities/plugins like tracking, assets/images, reporting.
These bundles are optional and if we give our client the code of the application, I don't want him to get the code of unwanted/unpaid plugins. So the features are split up in different bundles and they're linked by interfaces and config files.
The bundles also carry the sub-system applications like the administration panel. If the client does not have the tracking bundle, then the administration panel will not show the tracking interface because it is not activated in the kernel.
I hope this will help you make you mind.
Per symfony's documentation you can organize bundles in any way you see fit. So long you stick to the coding convention, and overall good coding practices. Especially if you plan to release this bundle to the public (which might not be the case in this scenario).
That said, I would advice against organizing your project by features because the number of features will always increase over time; whereas the number of subsystems in your project is more than likely to remain constant.
Take in consideration that a new bundle, is a new sub-project to manage, if you're using other bundles or libraries like Assetic, then you would need to enable every single bundle in the configuration, so the bigger the number of bundles, the more difficult it is to manage the overall project.
So, if I were in your position, I would break up the system in subsystems. Create a bundle that exposes a RESTful API, another for the Admin, and another for the Front-end.
Structure them in a way that every bundle can live on their own, just in case you need to deploy every sub-system of your project to different servers, so that is just as easy as striping them out of the main project, and integrate them into a new one.
I'm new to version 2 of the Symfony framework. I made some projects with v1 but now trying to get my head around the new version and it's features.
I read over the concept of Bundles but it's purpose is not yet very clear to me.
Say you have a big web application, a CRM for example. How would the bundles look like?
Would it be NewsletterBundle (for sending newsletters), ContactManagementBundle (for managing contacts), UserBundle (for editing users and their permissions).
Or would it be less cut-up like, EmailBundle (for handling the entire email traffic), CRMBundle (for putting in all your CRM code), PermissionsBundle, ApiBundle.
I like to think of it like this: a bundle should represent a specific feature or set of like features for a project.
Your first example is a better use of bundles than your second example, because the purpose of each bundle is more defined. While it's possible to use one CRMBundle for everything, you wouldn't really be taking advantage of Symfony's ability to organize your code. Additionally, if you wanted to port over your Newsletter code to a new project, but not all of the CRM code, you'd have an easier time copying over a NewsletterBundle versus copying over the CRMBundle, and then pruning it.
When thinking about a Symfony2 project, sometimes you want to forget everything you know about symfony 1.x, since they take wildly different approaches to solving many problems. For example, in symfony 1 it was common to build a 'frontend' and 'backend' app for a project, and each app would obviously contain logic specific to those parts of the project. So you might have a Newsletter controller in both the frontend and backend apps. In Symfony2, you're better off using only one Newsletter bundle, but with two controllers (perhaps named 'frontend' and 'backend'). Again, an immediate benefit to this is how reusable your code becomes.
I'm currently working on a PHP project using CodeIgniter as my framework. I took a look at a few templating systems I could probably use - Strogen's Templating System (currently used in PyroCMS - if I'm not wrong), Twig, Smarty etc.
But I have decided to go on my own to build one from scratch. Since I have experience dealing with Wordpress templates, I was thinking of creating something similar.
To give you a run down of how wordpress themes work - Wordpress has a set of functions (Theme functions) that help gather data. I was wondering if following the same would be a good idea for my project as well?
If I did create such template functions which I would be calling within my views, would it work against the MVC principles? And would it affect the performance in any way?
Well, with MVC, models do the db interactions, views display the data, and controllers are the go-between. If you created your "template functions" in the controllers, I suppose you would be complying with MVC. If you wanted to say, create a library or helpers to do the gathering of/manipulation of data, you would not be complying with MVC convention. AFAIK, it's a matter of preference which way you choose. As far as performance, you could use profiling to test which is better.
However, if your aim is to build a templating system for CI that is similar to WP just because you are familiar with the way WP templating works, I'd proffer that it would likely take you substantially less time to learn a new one than build your own. I'd also imagine it would take much less time to learn the new one than it did to learn the WP one.
Also, I think pyro uses a combination of Phil's templating and smarty, but not positive. Phil has a templating system available for CI here: https://github.com/philsturgeon/codeigniter-template May be worth checking out.
cheers.
I'm starting work on a personal site that's primarily a blog, with a section for various tech projects as small as a custom photo gallery to as large as a restaurant-review web-app. Not having worked with WordPress or Kohana before, I'm curious what the advantages are of integrating WP into Kohana (or any other framework, for that matter), and vice versa, given this situation.
I've seen bits of this mentioned here and there online, but no definite post comparing the two approaches, so I'm hoping others can pitch in here :)
I've not used this before, but kerkness has written a plugin for it: https://github.com/kerkness/kohana-for-wordpress However, it is quite old so you might want to look for something newer.
Integrating Wordpress with a framework (be it Kohana, CodeIgniter, Zend, etc.) is often sought without addressing the first and most important question: How far do you want to integrate the two at a feature level?
Broadly speaking, there are two high-level approaches to integrating any two PHP products:
1) In the PHP code, include the libraries, bootstrap scripts, etc. from both products into a script or scripts (creating a "hybrid").
As a developer you should be able to use most of the features from both products in the resulting hybrid. For example, in the case of Wordpress and Kohana, the complete result would allow you to use Kohana features (e.g., routing, auth, etc.) and Wordpress features (e.g., fetching post contents, authors, etc.).
The difficulty with this approach is competing APIs and code expectations that might make the hybrid behave unexpectedly, e.g.,
Will there be competition between the class autoloaders?
Are there duplicate function or class definitions?
How extensively can plugins in Wordpress be supported if they depend on PHP settings that the framework is going to change on bootstrap?
The first issue I would want to resolve when attempting this process is the routing, am I going to delegate fetching of posts, attachments, etc. to Wordpress from within Kohana, or am I going to have to build an interface between Kohana's router, controllers and Wordpress?
While this option is appealing because you can access both product APIs, you must be prepared to make significant changes to the application behaviour in order to allow both products to co-exist peacefully. If this sounds like a lot of work, it is because it is a lot of work!
2) Use the webserver to intelligently route requests to different products.
From your question, it sounds like you want parts of the website to load web applications that don't necessarily need the level of integration indicated above (e.g., would you really need to get Wordpress API in the review application, or the photo gallery?). If you are just looking for a way to load two applications using the same application domain, this option would be better suited because you don't need to perform much (if any) integration between the two.
Assuming you are using a webserver like nginx or Apache Httpd, you should be able to create aliases for different parts of the site to different applications.
e.g.,
http://myblog.nonex/ - points to the Wordpress installation, which in turn manages the default site (shows pages, blog posts, etc. all from Wordpress).
http://myblog.nonex/apps/review - points to the review application, which is the Kohana installation.
http://myblog.nonex/apps/gallery - points to the gallery application, which (with proper modularisation) could exist alongside the review application in the same Kohana installation.
Since you are still in the planning and development stage, I would recommend going for option 2) first - build a prototype, identify any areas where you absolutely need features from Wordpress in Kohana (e.g., would either the review or gallery application need to use the Wordpress user credentials?) and look at performing a minimal integration before creating a full hybrid.