I just started to work in symfony 3.4 and i'm pretty lost.
I want to make a CRUD for Products.The products table have multiple columns(name,description,CATEGORY_ID).
In create page, for this category_id, i want to make a select with the names of the categories that are stored in another table(id and category_name).
For this i need to select all the categories, but i don't really know how to do that.
I worked in codeigniter before and there i would make a function getAllCategories in category_model and i would call it in Controller.But here...i don't know how to do this.
Can you explain to me please how this should work?Where should i make the sql functions?
Your seem lost on things that are very basic for Symfony.
You probably have to start reading a lot and from the start.
You have two parts that you have to cover.
One is doctrine and how you can declare entities and manage them with the entity manager, and the second is Forms and how you can use them to render your form (including the foreign entity relation), to handle and validate your submitted data, and to pass the validated data to the database through the entity manager.
Your example is pretty simple, so it should be very easy to follow a tutorial while modifying it to fit your code.
Related
Running: Laravel 5.3 with Laravel Backpack CRUD 3.1
I am running into situations where I have a Model that I would like to add multiple related (child) records too, using just one CRUD form. Some examples would include adding multiple files... but let's start small. I have found the following posts that have similar topics, but not clear answer on the best way to do this.
Is the best way to use the table Field Type? https://laravel-backpack.readme.io/docs/crud-fields#section-table But, I guess the drawback is not having validation on the child records?
A similar tutorial to this one would be cool: https://backpackforlaravel.com/articles/tutorials/nested-resources-in-backpack-crud
So, an example would be where I have a Journey model and would like to add multiple Chapters to the Journey directly on the same Journey CRUD form.
Let me know if this question makes sense... and any suggestions/advice you can share.
Backpack doesn't support adding more entities in one form - every such form is very different.
My recommendation would be to edit the EntityCrudController::store() and EntityCrudController::update() methods, to check for the values of the "table" field and add/update/remove connected entries.
I'm brand new to Symfony but am loving getting familiar with it (and many of the concepts behind it). MVC is pretty new to me in terms of the way I'm encountering it in Symfony.
My question is that if I have a simple array of commonly used data that I don't think necessarily belongs in a database table where should I store this. Is it an Entity? Should I store it in the Should I put it in the controller? Somewhere else?
I'm talking specifically about something like a US States array that I might use to power a dropdown. Right now I'm having to build an entity and store these in the database but would like to know if there is a better / preferred way to do this.
In my procedural days I would keep a file called "includes/arrays.php" and pull that when I needed one of these.
Thanks
If you want to use this data with other Entities, for example State would be connected to Adress object, I would stick with Entities, because it makes relations easier to implement and work with (I assume you using some kind of ORM e.g. Doctrine).
If you don't want to use this data with other entities, maybe you would like to hardcode them into all the templates somehow. http://symfony.com/doc/current/cookbook/templating/global_variables.html (I assumed you are using Twig).
A similar question was answered here:
Where to define static array related to an entity in symfony2 ?
It depends. I would opt by having that kind of data in the database. Suppose you in the future would have a back-office that update data.
Or you could use config files. For example, in yml format, arrays is easy to define.
Just like #foxtrot said, any data that is changeable should be stored in the database, just so you do not have to edit any code when a change occurs.
Firstly, I would create the Entity for the common data, and then I would use Fixtures to generate the entries in the database when you deploy your code.
This way, you allow later editing through either forms or phpMyAdmin, but you also get to write the default values into a PHP class so you don't have to manually enter all of them into the database.
See Symfony - DoctrineFixturesBundle
I am currently working on a huge refactoring project. We have taken over a classic PHP/MySQL project, where most code is procedural, duplicated, and there is very little hint of an architecture.
I am planning on using Doctrine to handle our Data Access, and have all of my tables mapped to entities. However, our MySQL tables are largely messed up.
The table I am currently working with has over 40 columns, and is not normalized by any means. A quick example of what we have:
Brand
id
name
poNumber
orderConfirmationEmail <---- these should go into a BrandConfirmations entity
shippingConfirmationEmail <-----
bill_address <---- these should go into a BrandAddress entity
bill_address2 <-----
city <------
.
.
.
Ideally, what I would like to have is for Doctrine to pull out the fields that reference different Entities, and actually put them into those Entities. So for instance id, name, and poNumber would get pulled out into a Brand entity. orderConfirmationEmail and shippingConfirmationEmail would get pulled out into a BrandNotification entity. Next, bill_address, and the rest of the address fields would get pulled out into a BrandBillAddress entity. Is there a way to configure Doctrine to split the table into these models for me, or do I have to custom write code myself that would do that?
If I do have to write the code to split this table myself, do you have any resources or advice that tackle a similar issue? I haven't been able to find many yet.
The latest version of Doctrine 2 supports what they call embeddables: http://doctrine-orm.readthedocs.org/en/latest/tutorials/embeddables.html. It may solve some of your problems. However, it requires D2.5+. Currently, S2 uses Doctrine 2.4. You could experiment with using the very latest doctrine.
What you can do is make your domain models (entities) act as though you had value objects. So $brand->getOrderConfirmation() would actually return an order confirmation object. You have to do some messing around to keep everything mapped to one table and you might be limited on some of your queries but it's not that hard. The advantage is that the rest of your new applications deals with proper normalized objects. It's only the internal persistence code that needs to get messy.
There are quite a few links on this approach. Here is one: http://russellscottwalker.blogspot.com/2013/11/entities-vs-value-objects-and-doctrine-2.html
Your best bet of course is to refactor your database schema. I like to do kind of a raw dump of the original database into a yaml file with the desired object nesting. I then load the yaml file into the new schema. If you are really lucky then you might even be able to create new views for your existing application which will allow it to keep working in parallel with your new application.
Is there a reason why Create and Update are distinct when making MVC application in PHP?
I see why they are distinct in theoretical explanations, but is it worth keeping separate actions and views for create and update in CRUD controller? If I only need to change the title of save button it seems logical to have one action for both create and update operations. which will save object as new DB row or update existing depending on the id it has (or hasn't).
PS. I've always merged them into one action and recently when started searching for information about Zend Framework I've found that every tutorial with some CRUD functionality has distinct create and update actions and views that have almost the same code. It seems strange why authors copy-paste 90% of the code from one method to another.
I think you're asking more of a style question than a purely functional one. For me it's separation of concerns - there is no guarantee that create and update will truly overlap, and there may well be functional differences, so it's a potential landmine in the future to lump them together.
I'm using Codeigniter to flesh out a pretty large project (especially for a n00b). One issue I'm having is how to organise my files and methods. I've broken my project down into features - the app is a task management software so already we have basic features such as "Task", "Project", "User" etc.
The way I intend to do this is by creating controllers for each and then following CRUD methodology in each. So for example in Task we would have the following methods:
create()
read()
update()
delete()
This makes sense in my head. Now in terms of Views, should I have multiple views, or should I combine create and update into the same form? Also, where does non-View functionality go, such as setting cookies etc?
This is quite a specific question but if anybody has any more holistic guides on general structure convention for CodeIgniter projects I'd be very grateful.
I'd say you got it right. This is what I do.
I tend to use the same view for create and update, keep it DRY (don't repeat yourself) if you can.
Non-view related stuff that does not handle anything business-related goes in what I call helper-classes. If it's business related, I put all the logic into services, so I can unit-test them without being dependant of any framework (not sure how new you are at this, but oh well :) ).
You can also use Grocery Crud, a library that provides out of the box CRUD functionality for codeigniter.
It handles pretty good 1->n and n->n relationships so its convenient for small projects.
I don't know if you are familiar with it. If not give it a try. It will save you tons of time and effort.
My controller consists of these methods, which follows REST API guidelines:
read -> get all records.
find -> find record by primary key/id.
create -> show the form view.
store -> insert data from the form into the database.
edit -> show the form view, populated with current records' data.
update -> update data from the form into the database.
delete -> delete data from the database.
This is called Resourceful Controllers.
Yes, you can combine create and edit in same form. However, there are cases those require you to use different create and edit form. In that case, just make 2 separate forms.
And... like #Theodore suggested, GroceryCRUD is worth a try if you don't need too many customizations.