Magento Naming Convention - magento

Given the class
<?php
class NameSpace_HelloWorld_IndexController extends Mage_Core_Controller_Front_Action
{
public function sayHelloAction()
{
}
}
What should be the name of the layout file?
hello_world.xml
helloworld.xml
What should be the xml action name of the sayHelloAction?
<hello_world_index_say_hello></hello_world_index_say_hello>
<helloworld_index_sayhello>
An article on magento naming conventions would be appreciated. The examples I found only explaned the Namespace_Helloworld_IndexController::sayhello() coding style.

What should be the name of the layout file?
Anything you want. There's no enforced naming convention for the layout file — it's completely decoupled from the module name. All you need to do is specify an XML layout file name in your config.xml file. That said, the convention among the more engineering focused Magento developers is to use a lowercased version of the full module name for third party modules (namespace_helloworld.xml).
What should be the xml action name of the sayHelloAction?
The correct name for this node is the full action handle. The naming here is going to depend on how you configured your router nodes in config.xml, and how a particular URL routed itself through the system. In other words, beyond the scope of a single Stack Overflow answer.
You can peek at the full action name with the following code in your action method.
public function sayHelloAction()
{
var_dump(strToLower($this->getFullActionName()));
}
Generally speaking though, the convention is
[Route Name]_[Controller Name]_[Action Name]
Assuming you setup your route name to match your module name, that would be
route name: namespace_helloworld
controller name: index
action name: sayHello
or
namespace_helloworld_index_sayhello

NameSpace_HelloWorld_IndexControllerfile is incorrect controller class name
controller class name should be ended by 'Controller', Controllerfile is not allowed
about layout file: you should define the name of layout file in config.php
about handlers: if you use camelCase, you just need to lowercase the method name and remove 'action' from the end, for example getSuperDataAction will be < route>_< controller>_getsuperdata

Related

Laravel Nova display user-friendly resource name

Let's say that I have a resource called "Resource_test". When I'm displaying that resource in Nova, that resource name (or "label") displays the name as-is which obviously isn't very user-friendly.
Is it possible to rename the "label" to "Resource Test" (without the underscore for example)?
It seems like they set the name in the file src\Nova.php on the static function resourceInformation but even though I change the name there, it doesn't seem to change the name on the site itself...
You can override the static label method within the resource class like this:
public static function label() {
return 'Your own label';
}
You'll find your resource classes in the app/Nova directory. Do not confuse these classes with the identically-named models! Adding the label method to the model will not work.
You can take a look at the Nova\src\Resource.php class to view all the options.

Correct naming structure for CodeIgniter

I'm starting my 1st CodeIgniter project and want to get some advice before i start. I'm a little confused with how the name of the controller and models work.
If i want the url to my company page to be http://example.com/Company/view
the controller needs to be called Company.php correct?
inside the company controller it would look like this:
public function viewAll()
{
$this->load->model('Companymodel');
$this->load->view('templates/header');
$data['result'] = $this->Companymodel->viewAll();
$this->load->view('company/viewAll', $data);
$this->load->view('templates/footer');
}
ok im confused here, on line 4 above:
$this->load->model('Companymodel');
this call to the company model page needs to have 1st letter capital with the rest lower case?
if that's correct, does the model file need to be called Companymodel.php and placed inside the application/models folder?
is it bad practice to call the controller and model the same
example: Company.php and place it inside /application/controller/
and then have the model called Company.php and place it inside the application/model or should the model be called Companymodel.php
I guess my ultimate question is the naming convention of the controller and model files, and whether they can be upper case or not.
URLs
Your URLs should typically be all lowercase letters. If you expect capital letters, there's a chance you could accidentally exclude their lowercase counterparts, even though they're the same URL. Example: www.example.com/controller/method/param
Controllers
Controller class names should be all lowercase, except the first letter.
If your URL is www.example.com/gallery, the controller name is Gallery.
If your URL is www.example.com/admin_folder, the controller name is Admin_folder.
Controller file names should match the class name, but be all lowercase.
Gallery :: gallery.php
Admin_folder :: admin_folder.php
Controller methods should be all lowercase as well. There is some flexibility with uppercase, but similar to URLs, there are opportunities where it can goof something up (here's an example where capital letters interfered with a form validation callback method).
Models
Models follow most of the same conventions as controllers. The only difference is with model method names, which can use your preference of capitalization. Since these methods are not tied to URLs, and are called using normal PHP OOP, you can name them as you please.
It is recommended to load models using the all lowercase version. While it is not required by CI, it can confuse some users if they load it with a capital letter, but then attempt to access it as all lowercase (this is due to native PHP being case sensitive with class properties [and variables in general], not CodeIgniter).
Model class name: Users_model (the _model suffix is also not required, but some people may use it as a personal preference, or to prevent naming conflicts with a Users controller).
Model file name: users_model.php
Model loading: $this->load->model('users_model')
Model method names (all okay): $this->users->getAll(), $this->users->find_by_name($name), etc.
Libraries
Libraries follow the same conventions except for the file name. In their case, file names should match the class name.
Similar to models, it's recommended to load libraries using the lowercase name.
These rules are the same for CI's libraries (located in application/core and application/libraries, as well as custom or third-party libraries.
Special note: when extending default CI libraries, the prefix as defined in application/config.php comes into play. This prefix typically should be all uppercase, followed by an underscore. The default is MY_.
Library class name: Photos
Library file name: Photos.php,
Library load: $this->load->library('photos')
Helpers
Helper names and loading are all lowercase. The filename consists of the helper name with _helper appended after.
Helper name: url
Helper file name: url_helper.php
Helper load: $this->load->helper('url')
Notes
CodeIgniter is somewhat inconsistent in their naming conventions, but there really aren't too many rules, so they are easy to get used to and memorize. I very rarely have issues with naming and loading in CI, and when I do, it's usually because I was just working on a Composer-related project so I got into a different habit.
The rules in this answer are for CodeIgniter 2.1.x as of this writing. There is discussion on Github for 3.0 to better and add more consistency to naming conventions, which you can read about and contribute to if you'd like.
models/admin.php
<?php
class Admin extends CI_Model {
...etc
controllers/company.php
will include the admin model with
function galleryView()
{
$this->load->model('Admin');
$numRows = $this->Admin->getPhotoNum();
... etc
To browse to galleryView the URL would be mysite.com/company/galleryView
There is very good documentation and examples on the CodeIgniter site

codeigniter class name convention

When I'm developing in NetBeans I have a lot of confusion due to the amount of tabs open. In most cases the controller has the same name of the view or model.
In the convention style guide they say that you can prefix a controller file name with a custom suffix, but doesn't work.
My question is, there is any chance to end all the controller files with "_controller"?
In my example the class is class Verify_login extends CI_Controller { and the file is named verify_login.php. Tried with controller.verify_login.php like they say in the guideline but as I say, doesn't work. Lots of confusion in codeigniter's documentation.
Since the controller is the only thing exposed in the URL, I usually name my views and models with an indicator like "user_view" or "user_model". The controller would just be "user" and in this way I always know which file I'm working on.

Are helper classes mandatory for all Magento extensions?

Many extensions (including the one's I've written) include a helper class that just extend the abstract base class without adding any functionality. The helper usually looks like this:
class MyCompany_MyModule_Helper_Data extends Mage_Core_Helper_Abstract {
}
The extended class is therefore just used for things that the abstract class provides, especially for translations. On the other hand, all Block and Controller classes in Magento inherit the __() method for translations - and in an extension I'm currently developing I don't have the need to call the helper class even once.
Can I just delete the helper class and remove it from config.xml? I've tried it and the extension seems to work fine without, but due to Magento's complexity I'm always a bit worried that there are implications I'm not aware of.
If you're creating a module from scratch, helper classes aren't strictly necessary. I usually skip creating one until it's needed.
However, if any XML file uses the module attribute to specify a translation module, that attribute needs to resolve to a valid helper. For example, in this core file
<!-- File: app/code/core/Mage/Catalog/etc/system.xml -->
<tabs>
<catalog translate="label" module="catalog">
<label>Catalog</label>
<sort_order>200</sort_order>
</catalog>
</tabs>
There's module="catalog". By specifying this attribute, the Magento system code that translates the label will look something like this
Mage::helper('catalog')->__('Label');
So, removing the helper from the catalog module would break parts of Magento.
(The single part class alias catalog is automatically converted to Mage::helper('catalog/data') by Magento system code)
This "helper to group translations" feature is used in many of Magento's XML files, not just system.xml (layout, widgets, etc.). Additionally, there are some systems in Magento that will infer and/or require the existence of a helper module for translations (Access Control, external API system,etc. )
Long Story Short: If you're creating a module from scratch, feel free to leave the helper out until you start getting errors that Magento can't instantiate a helper. Never remove an existing helper from a module, and if you want to make sure you're 100% compatible with assumptions other people might make, always include a Data.php helper class.
Magento's Helper classes contain utility methods that will allow you to perform common tasks on objects and variables. http://www.magentocommerce.com/knowledge-base/entry/magento-for-dev-part-1-introduction-to-magento#6
Assuming that the Helper file is empty with no custom methods eg.
<?php
class MagePal_SomeModule_Helper_Data extends Mage_Core_Helper_Abstract
{
}
Then some of things that may still be affected are:
system.xml - blank screen for your module in admin -> system -> config
$this->__('') - error in your .phtml template (for internationalization/translation)
So if your helper is empty, without a system config section and no translation then it 'maybe' ok to delete.

What should be required for createBlock

I want to create a block and add that block to my template via
$this->_addContent($this->getLayout()->createBlock("device/device"))
Right now, it is not displaying anything.
What are the points to be Noted so that my block will get rendered (what are the files to be aware off?)
Note:
COMPANY NAME: Abc
MODULE NAME: Device
Also, createBlock("device/device") returns "false"
The device/device string that is being passed to createBlock is a class alias. Class aliases give the Magento developer a way to refer to classes without using the actual class name. This indirection allows for one class to be substituted (or rewritten in Magento terminology) for another without having to change any code which instantiates and uses the class.
You start by defining the prefix for your classes in your module's config.xml file as follows (note: add this code into any existing tags, rather than just dropping it in at the bottom of the config.xml):
<config>
<global>
<blocks>
<device>
<class>Abc_Device_Block</class>
</devicer>
</blocks>
</global>
</config>
When building the class name for a block, the part of the xml is the part which comes before the / in the alias, and is substituted for the contents of the tags when generating the class name. The / is then replaced with an _ and the remaining part of the class alias is appended to the class name. So with the class alias device/device, and the above XML, the following class name will be built Abc_Device_Block_Device, which Magento will expect to find in Abc/Device/Block/Device.php. It will search folders in the order specified in the include_path, which is normally app/code/local, then app/code/community, followed by app/code/core and finally `lib.
The same basic logic also applies to model and helper classes.
Alan Storm's indispensable CommerceBug extension has a great tool for testing what model/block/helper class aliases map to in terms of class names and file locations.
The other parameters on this method are a name which can be used to refer to the block (and modify it) from layout XML files, and an array of other attributes which could be found in the layout XML.
That was an excellent answer Jim. Adding a point to it, the priority is the
Local
Community and then comes
Core if I was not wrong .

Resources