I know naming conventions for tables used by plugins generally start with the name of the plugin and then the model pluralized. For example lets say I had a plugin called Poll, with a model also called PollPoll and another model called PollTag then the resulting table names would be poll_polls and poll_tags. They would also have a habtm relationship so what is the convention for that table name? I believe it would poll_poll_polls_poll_tags, although it is a little redundant it makes sense since the first poll_ represents the name of the plugin, while poll_polls and poll_tags relates to the models.
Also have any naming conventions changed for plugins in 1.3? Is the above stated correct?
Not sure about cake 1.3 (I'm not using it yet), but this if you're right this sounds like a perfectly acceptable case of breaking convention and defining the jointable, and foreign keys in the model relationships and possibly in the plugin.
Why does your plugin require a join table? Seems like a design issue. Perhaps there is a case where this is needed, but if I had a HABTM relation with a plugin, I would add a modelname column to the plugin's table, rather than have to create a new table for each model I wanted to use the plugin.
It's actually not yet a convention that "tables used by plugins generally start with the name of the plugin and then the model pluralized."
The only place that idea is introduced is in an example in the book, which actually says, "it is recommended that you name your plugin controllers something relatively unique in order to avoid namespace conflicts with parent applications ... you might want to be creative with controller names, or prepend the name of the plugin to the classname."
Your Table/Model/Controller/View names must follow normal CakePHP naming conventions, and take reasonable precautions to avoid namespace clash. So it would be perfectly fine to have a "foo_orders" table for a "foo_order" model in plugin Bar.
Related
Why do we use reverse domain name like com.something. or org.something. structure for java packages?
I understand this brings in some sort of uniqueness, but why do we need this uniqueness?
About why we do it reversed: Imagine you have two important packages, an accounting package and a graphics package. If you specified these in 'straight' order:
accounting.mycompany.org
graphics.mycompany.org
Then it implies there is a major accounting package, a subsection of which is for mycompany, and a subsection of that package is called the org package which you actually use. However, you want this:
org.mycompany.accounting
org.mycompany.graphics
This makes more sense. Out of all packages from organizations (org), you look at mycompany in particular, and it has two sub-packages, the accounting and the graphics ones.
Globally unique package names avoid naming collisions between libraries from different sources. Rather than creating a new central database of global names, the domain name registry is used. From the JLS:
The suggested convention for
generating unique package names is
merely a way to piggyback a package
naming convention on top of an
existing, widely known unique name
registry instead of having to create a
separate registry for package names.
As you say, reverse domain names as base package name ensures uniqueness. Suppose two companies with DN example.com and example.org both define the class Employee in their framework. Now if you are using both frameworks you will not be able pinpoint which Employee you want to use in your code, but if they are defined in packages com.example and org.example respectively you can tell the compiler/JVM specifically which class you are referring to. If unique packages are not defined you will get compilation errors or runtime errors, e.g. if you are using the com employee class, but the org employee class gets loaded first from the classpath you will get a runtime error, since the two employee classes may not have same structure.
The uniqueness is needed for Class Loading.
It helps by avoiding naming collisions. If there are classes with same package name and class name, Collision will occur while trying to load the classes.
This generally happens if there are multiple libraries(jar) that contain classes with same names.
Also see this.
You need the uniqueness if you might need to integrate your code with third party software, or provide it to someone else for integration. If you don't follow the rules, you increase the risk that at some point you will have a class naming collision, and that you will need to rename lots of your classes to address it. Or worse still, that your customers will have to do the code renaming.
This also applies when code is produces as part of different projects in an organization.
As you said, it brings uniqueness, something that is needed especially when working with third party code. For example, consider that you are using a library I've made. I've used the package "foo" and have a class named Bar there. Now if you are also using the package name "foo" AND you have a class named Bar, this would mean that your implementation would override my Bar implementation, making my implementation inaccessible. On the other hand, if my package were "com.mydomain.foo" and I'd had by Bar class there, then you can freely use the name Bar in one of your classes and both classes could still be uniquely identified and used separately.
Why use the reverse domain name as the package name? I guess that is just a convention to make sure that everybody uses a unique namespace, as you shouldn't use someone else's domain in your package name.
Laravel encourages us to use snake_case, e.g. first_name, for model attribute names. In particular, when snake case is used to access an attribute from outside the class, it will automatically look for an accessor named getFirstNameAttribute.
When it comes to model relationships however, it seems more natural to use camel case. For example, if a stadium has multiple access points, then the stadium class might have an accessPoints() method. I can call this method as a property ($stadium->accessPoints) to retrieve a list of access points, or I can call it as a method ($stadium->accessPoints()) to get an instance of the underlying query builder.
This is different to how I would normally approach naming conventions. I would normally name attributes using the same case (either snake_case, or camelCase), irrespective of how the attribute is realised.
I am now embarking on a large Laravel project. Should I stick with the two different syntaxes, or am I likely to regret it down the track?
There's no true convention, like in Assassin's Creed's saying,
"Nothing is true, everything is permitted"
Laravel follows the PSR-2 coding standard. Source: https://laravel.com/docs/5.5/contributions
Which redirects us to https://github.com/php-fig/fig-standards/blob/master/accepted/PSR-1-basic-coding-standard.md
(from https://github.com/php-fig/fig-standards/blob/master/accepted/PSR-2-coding-style-guide.md which says: Code MUST follow all rules outlined in PSR-1.)
And there it says:
Whatever naming convention is used SHOULD be applied consistently within a reasonable scope. That scope may be vendor-level, package-level, class-level, or method-level.
And from that declaration, that's related to separation between environment level conventions, such as database design conventions and code conventions. Most database design conventions encourage snake case column names, and most code conventions use camel case method names, class names etc.
And when defining a model, to declare that, that the model property relates with a database column, the coding convention changes from camelCase to snake_case.
Well, it is a convention, so you should use the approach you are more comfortable with.
I personally use snake_case only on column attributes and camelCase on everything else (class names, relationships ecc).
Note that camelCase for class names and methods is basically necessary, because all laravel and external modules classes and methods use camelCase. If you use snake_case, it will be a mess with some methods implemented by you in snake_case and framework methods in camelCase.
For relationships, you will basically only use relationships defined by yourself, so i believe you can really pick the one you prefer.
I have made a tournament system in Laravel 5.3.
Now I want to extract the core ( generating trees ) into a plugin, and make it open source.
The idea is doing the plugin, and then replace the code in my app with the plugin's code, and all the references.
I'm making a demo, so people can migrate an seed necessary objects to generate his own tournament tree.
My main concern is that in my system, I have a lot of thing that should not belong to the plugin, but they still are in the same tables.
In my models, I removed a lot of fields / functions that are not necessary in the plugin.
For instance, In my tournament model, I have a function that handle permission, because not all users can "crud" all tournaments. This function has no place in my plugin, as I will not include any policy ( this should up to each use case )
Another example should be printing the tree. In my system, I allow user to print the tree, but in my plugin is meant to be the core functions, not optional stuff.
Also, I think I should use only 1 model, I mean, I should delete my project model, and use my plugin model as they will represent the same data. So what if I remove a field / method as mentioned previously???
For my models, a solution should be that I create child object and just extend my plugins models, but it would mean change all my actual model names, is it a good approach???
How should I manage migration??? Should I include useless fields in my plugin?
Also, which User model should I use, Xoco\my-plugin\User, or App\User
Laravel beginner here. So as you can guess I am creating an blog where user can create an article under a category and have different tags.
I have defined plenty of routes for articles already.
public/article/{id}/show
public/article/{id}/delete
public/article/create
So if I define a CategoriesController and a TagsController, I'm going to have to to define all of these CRUD methods in it and the routes too as:
public/categories
public/categories/{id}/delete
public/categories/create
public/tags
public/tags/create
public/tags/delete
Should I move ahead and build it this way or is there a better way to do this?
If you're talking about an administration system, you need CRUD to maintain your tags table.
In a curated system, where tags are controlled, the process of adding tags involves finding existing tags, perhaps asynchronously. You could utilize id's behind the scenes, assuming you have a relational database.
As people type some characters into the tagging portion of the UI, the system asynchronously finds a matching tag and displays it. Once that has occurred, there is no reason not to use the tag ID, and in that case, having a full set of tag routes is useful, but is not essential unless you have curated tags. For example, even if you want to use relational keys to store the relationship, you probably just need a search function which takes a tag string, searches for the matching tag, and returns that matching data.
In some systems, whatever tags are provided are added on the fly, but even in those cases, they are usually at least conformed. For example, you might want to eliminate bad words, mixed case, punctuation etc.
In short, if you need to maintain a tag table, then you will want CRUD for tags. If not, then adding tags, would just be part of the dataset that is operated on probably as part of the POST, when an article is created.
Also, just logically speaking, you shouldn't have a route for /public/article/{id}/create. It should just be /public/article/create
here are some good directions to look for
use RESTful Resource Controllers so you don't have to define each and every CRUD operation seperately. It would make your routes and controllers neat and clean. plus RESTful its a recommended nice way.
RESTful Resource Controllers
Another way is patterns. use good patterns for designing structure and behavior. here are some good reads. have a look
https://www.ibm.com/developerworks/library/os-php-designptrns/
http://shawnmc.cool/the-repository-pattern
https://sourcemaking.com/design_patterns
one nice and common way is to use repository pattern. In repository pattern the repositories work in between models and controllers.
"Repository commonly refers to a storage location, often for safety or
preservation." - Wikipedia
This would make your controllers and models simple and clean.
I'm making a leave management (HRM) website. I'm using codeignitor HMVC to build this. Following features are included in this site:
A table to display a summary of leaves.
A table for leave types like annual, MC, urgent, other...
I was thinking to create two modules for leave_summary and leave_types, but my friend told me it is useless.
According to HMVC architecture we are trying to create self contained modules for reusability. If I'm creating a different module for leave types, I should be able to reuse it and module itself needs to be self containing. But I can't use leave_types module anywhere else.
My friend asked me to put all the leave related stuff in one module called leave. This sounds strange to me as I found lots of examples people are trying to separate things out.
Do we only need to separate the modules which can be reused in the future (ex: login module, image_gallery module, profile module) and keep all others things inside a one module?
(according to the above example I have to keep everything related to leave in a one module
ex: leave_type, leave_requests, leave_summary will be placed inside the leave module)
What are the benefits I will get, if I separate the leave_type, leave_requests, leave_summary etc... into separate modules?
Will I be able to reuse them? If so How?
In HMVC model classes and other assets can be exchanged among the modules, so how can I call it a self-contained module or a separate entity as it is depending on another module?
(ex: I have to call leave_type module's model class inside the leave_summary module to show the leave type name in a table.)
I'm little lost here. Please help me to understand. Thanks a lot!
As i work lot of MVC projects. And I am agree with your friend.
May times this question arise when i used join that i have to choose in which one module i should go for write query. If you write in one model may next developer will write in another one model.
So according me it is best to keep same type of tables which are handling relation and using for same behavior use this approach like leave model, profile model etc.