The symfony4 documentation states that you shouldn't use Bundles in your main code anymore:
In Symfony versions prior to 4.0, it was recommended to organize your
own application code using bundles. This is no longer recommended and
bundles should only be used to share code and features between
multiple applications.
Any ideas how I can organize my code instead?
I think about having 200 entities. When they live all on the same level inside the Entity dir... that's a f****ing chaos!
Maybe namespacing/subfoldering?
PS: In django I'd think in the term of an app.
yes, I think organize your entity by domain is a good solution. Like Entity\Shop, Entity\Forum. This is also applicable to controllers, views, etc
Using codeigniter 2. Don't want to reinvent the wheel. Have tried Grocery_CRUD and found it takes as long, or longer, to learn it that it did to learn codeigniter.
Looking for crud library that makes sense, easy to learn so I don't reinvent the wheel.
Many thanks for any ideas.
You can use http://www.grocerycrud.com
It's easy to use with codeigniter.
Sample use
$this->grocery_crud->set_table('customers');
$this->grocery_crud->columns('customerName','phone','addressLine1','creditLimit');
$this->grocery_crud->render();
Also you can take look at https://github.com/jamierumbelow/codeigniter-base-model
This is very basic base model class for CI
Subjective but take a look at https://github.com/keevitaja/simple-crud-codeigniter
Why don't you try MY_Model to do all the CRUD functionality?
MY_Model
Just want to inform all you that I have released CRUDDER. This is a plug-in module for your application that works as a CRUD solution, ideal for systems back-ends.
CRUDDER is developed using CodeIgniter and Bootstrap for look&feel. You can develop your own skin appart from the Bootstrapped one. Full localization is possible. CRUDDER is designed to be intuitive and easy to use. The interfaces always show on-line help tips related to the CRUDDER itself and also to your database characteristics.
I'm attaching here an image of the CRUDDER example contained in the product web page so you can figure how easy it's to use.
On the other hand, you will find that configuration is very easy. There is no need to write code other than your own custom validation rules (more powerful than the CodeIgniter ones). There are only two classes: one contains all the functionality code and the other, Crudderconfig, encapsulates the configuration and localization parameters.
In contrast to other commonly used open-source CRUD solutions available, in CRUDDER all the table-and-field-specific metadata don't require to write code. All of this is contained in two "metatables", that can also be managed using the CRUDDER itself... so you use the CRUDDER to create your own CRUD rules (don't need to use phpMyAdmin, for example). This is a plus for users seeking for simplicity.
A full list of features is available:
Open the project web page
Among them:
Pluggable to applications not developed with CodeIgniter.
Sort, filter and pagination features, among others.
Soft deletes with unique-index collision avoidance.
Automatic menu-type form fields based on other tables content.
Extensible event triggering when a value is changed in a form.
Interface help tips for fields are contained in the database.
Designed with strong security in mind.
Take a look! Write me if you like it, have questions or want another functionality.
CRUDDER is released under the GNU LGPL license.
I was looking for models in Symfony2 structure and bundles but there are none.
What is the reason Symfony2 do not have models?
Is MVC the wrong way to go?
I am just curious because I know that CodeIgniter in fact doesn't need to use models too. You can place everything in controllers or even in model in some scenarios ;).
Could somebody explain it more in depth?
That's because Fabien Potencier, the former of Symfony2, does not think Models belongs in Symfony. That's why he called it a HTTP framework instead. See also this article he wrote: "What is Symfony2?"
[...] you should know that Symfony2 is really about providing the tools for the Controller part, the View part, but not the Model part. It's up to you to create your model by hand or use any other tool, like an ORM. Of course, tight integration exists for the most well known ORMs like Doctrine2 and Propel; but they are optional dependencies. The Symfony2 core features do not and will never rely on any ORM.
The Doctrine2 ORM uses repositories to take over the control of mapping databases to a class. If you want to have custom methods in your repository, you can create your own repository. That means that a Repository can be seen as a sort of model.
Because they didn't want to.
Tough answer, but there is no set in stone way to program. There are many different methodologies and you can choose to follow them if you wish, but nobody is making you. In this case, the developers for Symfony2 decided models weren't necessary.
That doesn't mean MVC is wrong. I own a sedan, but if you own an SUV, does that mean you're doing it wrong? Just a different way to get the job done.
Because there are no "models" in proper MVC. Model is a layer. Just like presentation layer (which contains controllers, views and templates).
What you should be looking for instead are: services, mappers and domain objects. Those are the more common parts of model layer.
VS2010 Pro + SqlServer Express.
Having been dropped into ASP.NET MVC 3 with no guidance but the web (2 books on order), I can't even get off the ground.
The MVC itself I get. Not a problem.
PHP, Ruby, and even ghastly WebForms firmly tucked into my toolbelt, with a long history of C++ QT client-server development before that.
Tying ASP.NET MVC 3 to a database using EF4 ORM is killing me.
The goals:
Use database modeled by DBA. I can specify all naming conventions, but code first is not an option!
Import to EDMX. This will be regularly updated using VS tools from the DBA's DB, never edited directly.
Generate partial classes from EDMX, for use as model. This will regularly be updated using VS tools, never edited directly.
Use 'buddy' to extend above model class with code as the Controllers/Views need.
Intuitively use the resulting model, pass it to the view, retrieve posts into it for insert/save, etc...
I've seen and read so many blogs, forum posts, walkthroughs, and stack overflow posts regarding this very use case.
I even tried riding the magic unicorn, followed by the latest 4.2beta1 with DbContext generators.
But can't get off the ground.
I follow instructions, but just not understanding how to do anything with it.
What conventions does the 'buddy' require (if any)? How do I use it? How do I get data with it? How do I write data?
Every example looks different. MVC guides are always focused on the UI side. EF guides don't cover usage in the MVC.
These are basic questions, and I'm feeling like the most incompetent idiot in the WWW right now.
Is anyone out there currently using MVC3 & EF4.x in the way I describe above?
This video is a good starting resource. Its a video of a guy creating an app from scratch that uses entity and a sql database (though he makes the db in the video, its still good for seeing some basics in action). You can see how he pulls data from the database, displays it on the page, and saves changes back to the database.
The first question I would ask is why are you stuck on using EF as an ORM or even insisting an ORM at all? I'd choose tools to suit the job here, especially given the constraints of the data layer.
Buddy classes were a concept invented in a day when the main .NET ORMs had no code-first option as ORM-encumbered class instances really don't behave well under things like model binding. Nevermind you could not decorate them with the DataAnnotations one used to indicate fields were required. Typically, the technical requirement is to use [MetadataType] attributes to tie your buddies to your models and perhaps something like AutoMapper to map data to and fro.
All that said, as a guy who has a few apps with lots of buddies and lots of automapping going on, you might want to think otherwise -- it is a bit of a maintenance nightmare. I'm living it.
There are some really good getting-started videos and tutorials right on ASP.NET MVC's site. The "Model (Data)" section is Entity Framework focused and touches on hot/trending topics like Repositories and Units Of Work.
Closed. This question is opinion-based. It is not currently accepting answers.
Closed 7 years ago.
Locked. This question and its answers are locked because the question is off-topic but has historical significance. It is not currently accepting new answers or interactions.
Some people consider WordPress a blogging platform, some think of it as a CMS, some refer to WordPress as a development framework. Whichever it is, the question still remains. Is WordPress MVC compliant?
I've read the forums and somebody asked about MVC about three years ago. There were some positive answers, and some negative ones. While nobody knows exactly what MVC is and everybody thinks of it in their own way, there's still a general concept that's present in all the discussions.
I have little experience with MVC frameworks and there doesn't seem to be anything about the framework itself. Most of the MVC is done by the programmer, am I right? Now, going back to WordPress, could we consider the core rewrite engine (WP_Rewrite) the controller? Queries & plugin logic as the model? And themes as the view? Or am I getting it all wrong?
Thanks ;)
Wordpress itself is not architected in MVC, but one can build very MVC oriented themes and plugins within the framework. There are several tools which can help:
WordPress MVC solutions:
Churro: # wordpress.org/extend/plugins/churro
Tina-MVC: # wordpress.org/extend/plugins/tina-mvc
Plugin Factory: # wordpress.org/extend/plugins/plugin-factory
MVCPress: http://mozey.wordpress.com/2007/01/22/mvcpress-screenshots/#comment-3634 (abandoned, but interesting ideas)
MVC threads on WordPress.org Ideas and Trac:
http://wordpress.org/extend/ideas/topic/mvc-plugin-framework
http://wordpress.org/extend/ideas/topic/complete-reestructuring
http://wordpress.org/extend/ideas/topic/rewrite-wordpress-using-mvc
http://wordpress.org/extend/ideas/topic/wordpress-theme-revamp (more on XSL than MVC)
http://core.trac.wordpress.org/ticket/12354 (on MVC in widgets)
Wordpress is kinda-sorta MVC. If anything it is a pull-type MVC layout, where the View 'pulls' data from the model. It does this in a very proceedural way, instead of using lots of different objects, but this actually makes the front end templates easier to write in a lot of ways.
This also gives the views some degree of controller logic (thus the kinda-sorta MVC).
Lets run this down:
Wordpress gets a URL. The wordpress core acts as a controller and determines what initial queries to run of the database, and by extension, what view should be loaded (category view, single post or page view, etc). It then packages that INTIAL query response and sends it to the view file.
That view file CAN be a strict display only file OR it can request additional information/queries beyond the built in one. This is the pull-type of the MVC, where the view pulls data from the model instead of the controller 'pushing' data from the model into the view.
Thus, when the view sees code to load a sidebar or widget area, it asks for that information. However, what widgets should be there is determined by the controller, which looks at the model for what widgets are in the sidebar, and then selects those that are set to show on the current page, and returns those to the view.
That each part of that isn't an object doesn't make this any less MVC. You can alter WP core without (necessarily) altering anything about a theme. Similarly, as long as you use built in functions like 'get_pages()' then the model and the database tables could change as long as those functions still returned the right data. So, the model is independent of the view, and the controller is independent as well (except when the view adds controller logic to do more than the core normally does).
While you COULD have a model object holding a number of methods and stuff like WPModel::get_pages('blah blah'), and contain everything that way, there is still fundamental separation of concerns.
View: template files
Controller: WP core
Model: the various functions that handle specific data handling.
As long as the names, arguments, etc, stay the same (or just have new ones added) then separation of concerns is maintained and one can be altered without disturbing the others.
It isn't a super-clean version of MVC, (especially when hooks get involved), but at a basic level it starts there.
And being proceedural about it isn't a bad thing IMO. A request from a website is pretty inherently proceedural: it is a process with a clear beginning and end, and just needs a procedure to process the request, get data, package it, then die. You can set up those steps with objects and object methods and OOP layouts (which would make some things easier) or you can just write alot of function calls and separate them out that way. Class members like private variables are lost that way but depending on the needs of the application... you might not care.
There is no one-grand-way to do development, and WP sits at like 20% of websites so it is doing something right. Probably something to do with not making people have to learn/memorize complex class hierarchies to get the database to answer the question 'what pages are child of page x?' and deal with that data. Could you make it that easy with OOP? yes, but if Joomla is any example of how hard it is to implement a complex custom website with OOP, then WP is FAR easier and quicker, and time is money.
As already mentioned in the comments, MVC is an architectural design pattern, not a specific framework, and no, Wordpress doesn't follow the MVC pattern.
There is a separation of views (templates) from the programming logic, but only in the frontend, not in the admin panel and a general separation of views and application logic is not inevitably MVC. An implementation of the MVC pattern usually assumes some kind of object oriented programming paradigm behind it and Wordpress is mainly implemented in a procedural way, with plain SQL queries in the PHP functions, therefore not having an actual model either.
One of the topics that periodically crops up in discussions as it relates to WordPress is the idea of WordPress and MVC.
But the thing is that MVC is not the silver bullet of web development that we try to make it out to be. Yes, it’s an awesome design pattern, and I personally think that it fits the web application model like a glove, but not every framework or platform implements that design pattern.
Case in point: WordPress is not MVC.
And that’s okay. I think we need to leave the desire of trying to shoehorn it into our projects aside especially when the pattern WordPress provides is not only sufficient, but works well when leveraged correctly.
“But I Love MVC!”
So do I! In fact, I spent the last year working on a project that more-or-less mimicked the MVC architecture.
A high-level example of MVC.
A high-level example of MVC.
For example:
Views were implemented using templates
Controllers were implemented by a combination of using function names like create, read, update, destroy, delete, and so on (even though these functions were hooked into the WordPress API
Models were functions also were called to validate and verify data prior to serializing the data. Again, this required that certain functions be hooked into WordPress to achieve the desired result.
Finally, a set of rewrite rules gave the application a clean set of predictable URLs in the format of /people/update/1 or /people/all.
What Pattern Does WordPress Implement?
WordPress implements the event-driven architecture (of which there are several variations such as the Observer Pattern).
In short, you can conceptually think of this as the following:
Things happen when WordPress is processing information.
You can register your own function to fire when these things happen.
Not too complicated, is it?
A high-level example of event-driven patterns
A high-level example of event-driven patterns
When you begin to think in terms of the paradigm in which it works rather than trying to make it work the way that you want it to work, it’s liberating. It helps to solve problems much more easily.
The bottom line is this: WordPress implements the event-driven design pattern, so even if you end up trying to implement MVC, you’re still going to have to utilize the hook system.
If you’re not careful, you can end up trying to craft the perfect architecture without actually getting your work done, and thus end up finding yourself so high up in the atmosphere of software that you’ve effectively become an architecture astronaut.
So You’re Saying Avoid Design Patterns?
Not at all! Design Patterns serve a purpose because, above all else, they basically give us solutions to previously and commonly solved problems. Use them!
But the point I’m trying to make is that we don’t need to try to force things to fit pattern just because we like the pattern. That’s not their purpose. Instead, leverage the primary pattern that your platform of choice implements – in our case, it’s an event-driven pattern – and then implement patterns where they fit (such as dependency injection or something like that).
Otherwise, it’s like trying to put your foot in a glove.
Courtesy (and totally copied :P) from : http://tommcfarlin.com/wordpress-and-mvc/
Just to update this with more recent information for people hitting this from search engines - the wp-mvc plugin http://wordpress.org/extend/plugins/wp-mvc/ goes a long way to creating a mvc framework for plugin development. You can find out more here: http://wpmvc.org/documentation/70/tutorial/
Just to add to the list of options, (I'm admittedly biased as the author,) swpMVC is a fully featured, lightweight MVC framework, inspired by Rails, Sinatra, Express, and FuelPHP. It's thoroughly documented, and while I have used and enjoyed wp-mvc, I wanted something where the models were able to populate views themselves, including form controls for interacting with said models.
I put this together largely to reduce the amount of controller code required to put together an app on top of WordPress, and the result is a very fast and effective framework that runs inside WordPress. The models are based on PHP Activerecord and 8 models are included for existing WordPress data types, including Post, PostMeta, User, UserMeta, Term, and a few more. Modeling data is very easy thanks to the activerecord library, and I've enjoyed working with this framework immensely thus far.
Also ships with underscore PHP and PHP Quick Profiler (as seen in FuelPHP.)
RokkoMVC is a micro MVC framework built especially for WordPress. The project is meant to simplify AJAX functionality in WordPress applications, as well as bringing in all the other benefits of using models, views, and controllers to your theme.
I had a bash recently at creating a plugin that makes use of a simple view-controller system, and quite liked the results, so I separated the template stuff out to its own repo. It offers object-based controllers, passing variables locally to PHP templates, template fragments (templates within templates) and components (template fragments with their own sub-controller). All in two tiny classes!
Of course, I wrote this code thinking that no other WP developer had considered the problem before ;-).
It's far from mvc, there is no kinda-sorta thing like some people say, it's either MVC or not... The fact that you write logic on the view level doesn't qualify it as a mvc framework. The reason people use it - it's easy to learn, you don't need to be hardcore php programmer, they're lazy.