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
Related
I found this very popular package on github.
https://github.com/barryvdh/laravel-ide-helper
I've seen this used in several projects I've worked in but I am not sure what the benefits exactly are of this package. If I understand correctly it generates a file in the root of your project with a "clone" of the Laravel Framework. This should help with autocompletion.
I don't see any clear examples in the documentation.
When using with PHPStorm it does suggest autocomplete for methods and properties for facade classes. For instance Mail and DB classes are facades, and when using them, you won't have all the suggestions and also the methods will be highlighted as non existent.
I am new guy to Demandware and I am switching from Magento to Demandware.
Demandware is not opensource I am not getting proper tutorials, stuff to understand the concepts of it.
I am from Magento so I know the Magento MVC structure.
But in Demandware we have different concepts like pipelines, pipelets, ISML scripts, ECMA script, DW scripts etc.
I want to know the MVC pattern of Demandware.
How it works and what are the basic concept I need to concentrate?
I would suggest to request a Demandware XChange account as soon as possible for you, so that you get access to the Demandware community portal and also to the API documentation.
In short:
Models are Demandware Forms and Demandware API objects
Controllers are Demandware Pipelines (there are JavaScript Controllers that are recently released, you may find these easier to understand if you have Node.js experience). These can call DW Scripts (DemandwareScript is based on ECMAScript standard 5.0 for JavaScript with some extensions like E4X and optional types)
Views are the isml templates. You should avoid including a lot of logic in them, either with isml tags like isif, isloop, etc. or with isscript.
Any further questions - let me know.
Hope this helps,
Zlatin
I hope you'll be able to avoid pipelines and dwscript. Those are a bit older. The most recent version works with plain old JavaScript, with pipelines being replaced by controllers.
Be aware that the underlying JavaScript engine is Rhino, which isn't really modern.
The Demandware documentation is open source now anyone can access to without having an exchange account it has the latest SFRA(javascript) based concepts as well
here is the link for the docs
Demadware Documentation
Demandware is very much designed around the MVC concept (in theory). The pipelines are basically your controllers and each pipeline filename (the xml file) is the first part of the URL and the start nodes inside the pipeline are the second part of the URL that basically represent the controller (eg Cart.xml has a start node called Show, so the url is Cart-Show). At the end of the pipeline flow chart is, usually, an interaction node to that links to an ISML file, those are basically the View and are HTML with some minor Demandware-specific markup.
Typically in the MVC world you try to prevent putting business logic in the views, however if you use SiteGenesis as your starting point you'll find that not to be the case on most of the pages. If you switch to using Javascript Controllers instead of Pipelines, then it'll be closer to the Magento style of MVC (but using NodeJS-like syntax).
i am developing an ERP Application, and wanted to structure it in such a way that, i can inject some other MVC web modules into its AREA at later time. this is what something like ORCHARD does. i need to know any such solution available?
to further elaborate my question, consider my application Named "MyERP" has two sub modules in its area.
1. HRM.
2. FRM.
and released this application to my client. later after release i decided to include another module for (AMS)Attendance Management System. so i wanted to structure MyERP in such a way, that my client can install this AMS module through MyERP web interface.
You may take a look at the following article which illustrates how a sample plugin system could be implemented. The project uses the custom virtual path provider that was presented in the following article and which allows to embed razor views as resources into separate assemblies.
i found this article helpful for my question.
I want to make one mvc3 application which is student management.
I've seen some open source projects.
They have used solution structure like core,data serve rice.
is there any reason to use structure like this?
Usually it is a good a good idea to keep things separated.
By that I mean not mixing up business logic with database management code and having non-UI code in the view files.
This makes it a lot easier for others to understand the code you have written. I also helps you, when you get back to some project after some time to make improvements or correct errors.
I hope this answered your question, if not shot again.
Edit: I found this link explaining how it is done in the MVC framework.
Use layered architecture where you isolate each layer by using the Separated Interface pattern. For the database, use Repository pattern (easiest way to archive that is to use a ORM like nhibernate).
Use an inversion of control container to reduce coupling (with the help of interfaces) and make it easier to handle dependencies between classes.
As stated in the previous answers, you should separate your logical tiers into a minimum of BusinessLogic (Entities,validation,etc..), Data(your favorite ORM), and presentation (MVC).
However, if you are just starting out it may be a little daunting to incorporate all of the more advanced concepts of a SOLID architecture.
Separating logical tiers doesn't always have to mean separate projects. The standard MVC3 template demonstrates this with the "Models" folder. Any entity added to this will be under the namespace Myproject.Models. Later you could re-factor the code in the Models folder into a separate dll,add a reference, and as long as the namespace was still Myproject.Models the MVC app will continue to work.
The same thing could be done for your Data Access layer!
If you're just starting out I would recommend developing your app in the MVC project and separating your DAL and Business Layers with a Folder (Namespace). Once your application is working you can re-factor as needed.
I am new to Codeigniter and I am thinking about the use of this framework in my new project.
I am going to need these two extensions. Before digging into too deep, I wonder if anyone already has experience with them and can kindly give some insights on whether there is any compatibility issue when they are used together.
Modular Extensions - HMVC
http://bitbucket.org/wiredesignz/codeigniter-modular-extensions-hmvc/wiki/Home
Datamapper ORM
http://datamapper.exitecms.org/
I believe there are many others who are going to use these two extensions together because they are actually very popular ones. So, many people are going to benefit from this thread.
Many many thanks to you all.
Firstly a caveat : I have used the HMVC extension but not the Datamapper ORM.
As far as I see it the two extensions have separate goals. In principle I cannot see a conflict.
The HMVC extension is useful where your view is composed of multiple sub-views. It allows you to modularise your application so that your views can be built from the output of multiple controller actions.
The Datamapper ORM allows you to map the data in your database directly onto PHP objects in your application. It saves you the cruft of writing SQL queries to pull rows from a database and hydrate objects in your application. You define what table your model is loaded from and how it is related to the other models in your application. The Datamapper generates the queries to perform the CRUD operations behind the scenes.
HMVC is concerned with how you structure your application. The Datamapper ORM is concerned with how you build your models. I don't see how the Datamapper would stop you using HMVC or vice-versa.
I'd also suggest taking a look at Doctrine ORM. It's a very powerful ORM framework that I've been using for the past year or so in all my CodeIgniter projects and works really well without any compatibility issues or such.
Tutorial for installing Doctrine with CodeIgniter.