Leaderboard

I guess you don't understand that phpfreaks is a free site, with expert help provided by volunteers. Given the fact that everyone is donating their time and expertise to try and help people like yourself, the argument that you host a free site with source code you got from somewhere else for free, means you shouldn't ever have to learn anything (which can be learned in a few hours) will not get you much sympathy here.

The commonality of most frameworks, is that most of them are built using Object orientated design patterns, typically implementing the "Model View Controller" (MVC) pattern. The model layer, when using a relational database is also an ORM. Symfony (and Laravel) are also frameworks, where the underlying pattern of library design is known as "Dependency Injection" (DI). A big benefit in using Symfony or Laravel, is that they facilitate the use of components as services, and you also can easily write your own classes that can be used as services. A quick example, that is frequently needed would be email services in the application. Typically you add the mailing component library to your project, do a bit of config (and in many cases the basic config gets added for you if you use a symfony recipe package) and at that point actually using the library is trivial. The "Dependency Injection Container" that comes with symfony can make decisions on when to load a library that is required (or not). It is thus important to learn something about DI design for use in your own classes. The originator/project lead of Symfony wrote these articles back in 2009, and I still recommend them to anyone trying to understand Dependency injection as a pattern. Read here -> http://fabien.potencier.org/what-is-dependency-injection.html Once you have more comfort with Oop, and at least a basic appreciation of the existence of OOP design patterns, you will have a lot more comfort using any framework. People who really are just trying to wade through a sophisticated framework without any understanding of how/why, can easily get lost, or have the feeling of not knowing what to do when they encounter an issue. With that said, here's a solid free course in Symfony 6, which if you can follow it, you will give you a good foothold in Symfony: I am a long time Symfony user, going back to symfony 1, and the earliest versions of symfony 2. Symfony 1 was an entirely different framework, and 2 was a very influential ground up rewrite that was intended to be a Dependency Injection framework from the start. Almost every major component from Doctrine to Twig was based upon the existence and design philosophy of some other popular library from the Java world or in the case of Twig, from Python's Jinja and Django projects. In most cases all frameworks start with models (the data persistence in a database) and routing configuration into controllers. Views are "templates". This is where you concentrate your markup code where appropriate. Beyond that, a lot of the really good stuff in Symfony or Laravel is in handling of dependency injection, and in providing for features like "event handling" or "security" or "form building and handling". Really smart people have worked on these frameworks and generally use well known and applicable object oriented design patterns like in the case of Laravel for example, the "Chain of Responsibility" pattern. They don't come right out and say that, but after you study patterns a bit and look at how some of these features work, you may recognize them. You don't need to know any of this to build apps with these frameworks, but you do need to understand basic PHP oop, and interfaces, type hinting, annotations (and now in PHP 8, attributes which have basically replaced the need for annotations) inheritance etc. You MUST get comfortable with Composer. You MUST understand autoloading. You MUST understand how autoloading works with your own classes, and where to put those when you need them. It is possible to do full apps just using the models/controllers/twig templates in the places the symfony manual and tutorials tell you to put them, although this will often lead to lots of "not DRY" code and fat controllers. From a learning standpoint, that's somewhat natural, and nothing to worry about, but eventually you will probably see the problems and seek to remedy them by creating your own classes, which will then be used as services in your controller code. Last but not least, I highly recommend getting a handle on unit tests, and how to write and run them. Test coverage is another area where these frameworks are an amazing value because the developers have worked hard to provide unit tests for their code, so there's a high degree of built in quality. There are lots of frameworks out there, where people did their own take on a framework, and inevitably, they lack unit tests, documentation etc.. One last thing on Symfonycasts. Symfonycasts is a superb resource, started by the long time Symfony documentation lead, Ryan Weaver. The tech built into the tutorial system is fantastic. Full transcription, and code snippets built into everything, so you can alternate between reading or watching as you desire. It costs $25 a month, and if you simply want to learn Symfony in all its sophistication, it's highly worth it, as you can sit down and power through the material in directed fashion. There is a huge amount of material they have covered, but it can also be dense. With the proliferation of javascript UI/UX frameworks like React and Vue, people aren't building apps the same way anymore, and there are a lot more apps where the backend is a REST api, and the frontend is built using a javascript framework, and pulls the data from the backend as a REST client. Ryan has been adding a lot of content in these areas, reflecting the state of the art, and where the professional developer market has been going. I would suggest getting a handle on the traditional first, and then perhaps looking at some of these emerging techs that look to better bridge frontend/backend code. What I wouldn't recommend is buying a year subscription to save some bucks, and then finding out you didn't get enough use out of the subscription. Better to pay the higher monthly and make sure you are getting value out of it. Last but not least, I really like "Programming with GIO"'s youtube channel for foundational state of the art PHP and things like autoloading/composer/core OOP etc. It's free, and as good and probably better than a lot of paid courseware. Symfonycasts and Laracasts both have that material available (sometimes free) but in my opinion you want to spend your time on the stuff that is specific to symfony or laravel rather than the general stuff, should you subscribe to these services in order to advance your education in how to use them.

Symfony is typically used with the Doctrine Object Relational Mapper (ORM) library. The projects have long had a close collaboration. Having done projects with many different frameworks over the years, my preference would be to use Doctrine as an ORM vs. alternatives like Laravel's Eloquent. One reason for this, is that Eloquent is an implementation of the "Active Record" pattern, whereas, Doctrine is an implementation of the "Data Mapper" pattern. These are differing approaches to how ORMS are designed to work. You can find many active record ORM's in the PHP world, going back to frameworks like CakePHP. ORM's aren't quite as useful when using NoSQL databases like MongoDB. I did a project where there was a mix of data persistence between MySQL and MongoDB, and there was some utility in using Doctrine to interface with both, but many of the features of an ORM are specific to relational databases, and document databases are just an entirely different way of looking at things with different strengths and weaknesses. However, to conclude, Doctrine is a really great ORM to use with MySQL, and it is well integrated into Symfony, should you want to use it.

https://symfony.com/doc/current/doctrine.html "Symfony provides all the tools you need to use databases in your applications thanks to Doctrine, the best set of PHP libraries to work with databases. These tools support relational databases like MySQL and PostgreSQL and also NoSQL databases like MongoDB." I think it's just a case of learning and figuring it out.

HTTP based API's typically have a design. One popular way of creating an API is to utilize REST. I would encourage you to search for "REST API" and read some articles on it. It is not a cut and dry thing, but there are some important concepts to understand, and the best practice for applying HTTP methods GET/POST/PUT/DELETE as well as understanding the idea of idempotency in relation to resource location. Generally speaking, most api's are REST api's. It's also been a common best practice in most cases to utilize json as the format of data transfer (which is not dictated by REST or RESTfulness). Where OOP comes in, is that you want to think about and abstract the "entities" your application works with. As OOP is great for organizing data, I would highly recommend its use, and to think about the entities present in whatever application you are trying to create. There is a lot of overlap in these areas, with relational database design.

Greetings, Laravel is popular, but I also find Symfony to be better. A lot of stuff (including Laravel) uses Symfony components under the hood so it's good to know it as well. Symfony uses Twig by default for it's templates. Twig has a lot of features, but at it's most basic level is fairly simple. You make one base template that defines your site structure then put {% block Blah '' %} anywhere that you want to be able to add content. Then you make a second file for your page and use {% extends 'base.html.twig' %} {% block Blah %}<p>The content</p>{% endblock %} To specify the content to be placed in said block. Keep up the learning and it'll all click eventually. PHP is a great and versatile language, and if you use it well and learn good design/architecture (which Symfony helps with I think) you can carry that knowledge over to other languages.

Object-oriented programming tends to be one of those things that doesn't really make sense until you find the right piece of information, or read something phrased in just the right way, or happen to be in the right frame of mind, at which point it all starts to click together. Which makes it hard to explain or teach. But basically, think of what you're doing - whatever it is - in terms of "Things" and the "Actions" those things can do. For now, forget programming and try applying it to real-world concepts. For example, I'm here sitting at my computer. The computer is a Thing. It has a power button, which also counts as its own Thing if you really want to go that deeply into it. If I perform the Action of "press the power button" on my computer, it'll either turn on (if it's off) or start shutting down nicely (if it's on). Or I can press the power button for a few seconds, in which case it'll either turn on or it will immediately turn off. And if I were to sketch that out in some pseudo-code, it might look like thing Computer { action PressThePowerButton(HowLong) { if PoweredOn { TurnOn // doesn't matter HowLong I pressed the button for... I think } else { if HowLong == Short { TurnOffGracefully } else { TurnOffImmediately } } } } For another example, I'm hungry because I haven't eaten today, so I'm going to go into the kitchen and cook something. I'll be using my stove Thing. It has four burner Things, each wired to one of four corresponding knob Things, and I can turn the knob right/left to turn on/off the associated burner. thing Stove { has Burner1 has Burner2 has Burner3 has Burner4 has Knob1 has Knob2 has Knob3 has Knob4 action Manufacture { Knob1 = create a new Knob connected to Burner1 Knob2 = create a new Knob connected to Burner2 Knob3 = create a new Knob connected to Burner3 Knob4 = create a new Knob connected to Burner4 } } thing Knob { knows about a Burner action TurnKnobRight() { set Burner on } action TurnKnobLeft() { set Burner off } } thing Burner { has Temperature action SetOn() { Temperature = High } action SetOff() { Temperature = Off } } Basically, 95% of OOP is thinking about Things and Actions, and by doing so you can take a complicated concept and reduce it into smaller pieces that are easier to manage. Like how I didn't try to "code" all the burner and knob stuff in one place: the knob knows how to do knob things, the burner knows how to do burner things, and they're hooked up to each other. But now I'm really hungry.