I am new in joomla . my question is why we have to use naming conventions in joomla and which part of joomla delivered with this naming conventions ?
for example when we make a plugin we have to use the plg as a naming conventions for class name . why ?
and I am confused how this class work without make any instance of it ?
As far as I know those naming conventions have historical reasons, which I do not know exactly. They are useful to easily divide between modules, components and plugins, which are all available in Joomla!, what is different to wordpress and Drupal, where you have plugins and modules only.
The last time I have created a Joomla! component, the com_ prefix is/was needed to locate and load the source code of that component, so necessary. If that is now replaced by the autoloader and namespaces, I guess one could omit it, but to hang on to the coding standards, I would recommend to keep on using it.
I asked the same question from my friend # biswarupadhikari
If you don't follow naming convention then how joomla will be able to understand which class joomla needs to call or which file joomla needs to include
Related
I know that naming conventions in Laravel is covered in another question, but blade files are not covered there. I read several blogs and forums and they all offer different approach so I want to ask here:
My controller method is AdminController#listPropertyTypes - which lists and manages the property types..
One blog suggests:
/resources/views/admin/property/types.blade.php
Another blogs suggest underscore or no space:
/resources/views/admin/property_types.blade.php
/resources/views/admin/propertytypes.blade.php
I would personally named this way since it is a view:
/resources/views/admin/property-types.blade.php
Is there a best practice or PSR rule for this?
EDIT: Laravel community mostly use kebab-case or camelCase
ie views/admin/property-types.blade.php or views/admin/propertyTypes.blade.php
Laravel's creator seems to use kebab-case, but Spatie recommends camelCase.
As #MrEduar explained it, there is no strict convention.
NB: https://www.laravelbestpractices.com website is abandonned and not affiliated with Laravel.
OLD: Initial answer
I came across Laravel Best Practices.
Laravel : Best Practices aims to put together all the resources and best practices in using the Laravel Framework. Last Updated: 2020-05-07 12:26:48
Views
You SHOULD use snake_case as file name of your Blade templates
Good
show_filtered.blade.php
Bad
showFiltered.blade.php
show-filtered.blade.php
For blade file names, there is no convention as such. But as #James says in his commentary, and I quote
If you are asking about best practices, then one suggestion would be
to strictly use CRUD controllers; AdminController#listPropertyTypes is
not CRUD. AdminPropertyTypesController#index is more "best practice".
And in this case the best way would be /resources/views/admin/property/types.blade.php.
You can read more about this in Laracon 2017 or in Adam Watham's github repository where he explains it further.
If you are not happy with this result I suggest you also use CamelCase According to the Spatie Guidelines
resources/
views/
openSource.blade.php
So, in the controller
class OpenSourceController
{
public function index() {
return view('openSource');
}
}
Instead of looking at unreliable blogs, be guided by the great minds of the Laravel community.
I want to make an extension that injects videos on product pages.
I already read a lot of documentation in Magento website but, sincerely, I have no clue where to start. What's the difference between Magento Extensions and Widgets? Can I develop my extension using only JavaScript? Do I really need to use PHP to develop one?
So many questions, can't find a focus. Can you please share a simple follow trough for me to read on? Thanks.
Credits : Marius
https://magento.stackexchange.com/questions/8344/how-to-write-a-custom-extension/8345#8345
Here is what I usually do:
Always develop with error_reporting on.
Always develop with isDeveloperMode set to true. Just add SetEnv MAGE_IS_DEVELOPER_MODE 1 to your httpd.conf file (or corresponding file for nginx or something else)
If the extension is linked to a core functionality add the
dependency in the declaration file <depends><Mage_Catalog /></depend>
If the module is for community use, use community as codepool to
give the developers the chance to override some classes without
modifying the code directly
Put your frontend design files in app/design/frontend/base/default
to make them available for all themes.
Put your admin design files in
app/design/adminhtml/default/default and do not change the admin
theme. I may want to change it in one of my modules.
Prefix your layout file names and template folder name with the
company name to make it easier to isolate them.
easylife_articles.xml and app/design/.../easylife_articles
Put your static resources (js, css, images) in a similar folder as
the template files easylife_articles/images/doh.png
Attach a simple text file with how to uninstall the extension: What
files need to be removed, what tables need to be dropped, what
config settings need to be removed from core_config_data table.
Do not write queries directly in models, blocks or helpers, use a
resource model for that.
Do not write queries using the table names directly Select * from
sales_flat_order where .... Use a Zend_Select and transform the
table names using ->getTable('sales/order').
Use the base url to include js files in template. Wrong
<script type="text/javascript" src="../js/some.js"></script>.
Right <script type="text/javascript" src="<?php echo Mage::getBaseUrl('js').'some.js'?>"></script>
Do not rewrite classes unless is necessary. Use observers and if
it's not possible use helper methods that receive as parameter and
instance of a class that you wanted to override. Wrong:
Override Mage_Catalog_Model_Product to add the method
getProductArticles(). Right. In your helper add
getProductArticles(Mage_Catalog_Model_Product $product)
If you override classes put a list of them in a readme.txt file
Use the default admin path for the admin section of your module.
Wrong admin url articles/adminhtml_articles/index. Right admin url admin/articles/index
Add ACL for your admin sections. I may want to restrict access to
some of the admins.
Do not add an other js framework (jquery, mootools, ...) if it's not
necessary. Write you code in prototype.
Make you template html W3C valid (this is for OCD developers like myself).
Do not put images in the media folder. Use skin. The media
folder usually is not versioned and this makes it harder to move the
website on different environments.
Test you extension with flat catalog on and off. In order not to double the development time use Chaos Monkey
Test your extension with cache on and cache off.
Avoid using uppercase letter in the module and class names. If not
properly tested this may cause issues on different OS. This is more a recommendation, not a 'must'.
Dispatch events in your code to make it easier for developers to
alter the functionality.
Follow the same coding standards that Magento uses and comment your code.
[Edited] Do not use php short tags (<? $this->doSomething() ?>). Use full tags (<?php $this->doSomething()?>). Also don't use short echo tags, yet. (<?="D'oh";?>). Use (<?php echo "D'oh";?>)
Translate your texts using $this->__ and add the locale translation file with your texts (app/local/en_US/Easylife_Articles.csv) at least for en_US language. Not all
websites are build in English and the identification of texts to
translate is time consuming.
If you sell an extension offer at least basic support. Or at least
answer the support e-mails you receive.
Do not make constant calls to your servers through your extension for licence validation. Once, at installation is more than enough (I don't like this approach either, but it's better than to make calls all the time).
(Inspired by this question)
Develop with the log activated and from time to time take a look at
the var/log/system.log file. The errors listed here are not shown
even with developer mode on. If there is at least one error you end
up with a large log file after a few months of running the extension.
If your extension affects the checkout process or the orders in
some way, make sure it works with multi-shipping, or if it
shouldn't work with multi-shipping, make sure it doesn't affect it.
Do not replace the default Admin Notification bar (or feed URL). If
I'm interested on what you have to offer I will subscribe to your
newsletter. Let me see what Magento has to say. It's more important
to me.
If you encrypt your code files with Ioncube (or something
else)...well...I just hate you and I hope your business goes bankrupt
That's what have so far. I will add more as soon as I think of something else.
You will definitely need XML and PHP, because this is mainly what Magento is built on.
Additionally to the official documents, there are a lot of helpful and very diverse tutorials out there that explain the mechanics of Magento. A web search helps, and I can recommend everything by Alan Storm, for example this litte module: http://alanstorm.com/magento_list_module
As soon as creating an extension works for you, you will also find a lot of tutorials on how to alter the product-view, or you can then post a more specific question here or on magento.stackexchange.com.
I wish to use models in my package. I've looked on laravel forums/blogs but can't find a definitive answer to this question.
Where should my models be placed and how should they be namespaced?
I know how to autoload my models etc but should the models go in:
panthro/package/src/models
and be namespaced:
panthro/package
OR be located at:
panthro/package/src/panthro/package/models
and be namespaced:
panthro/package/models
What is correct or is there another solution?
Your models can reside anywhere, as long as they can be found. However to keep things more consistent, I would advise you to put them in panthro/package/src/ (or whatever the name of your package is), since src folder is almost the equivalent to app folder in your Laravel main project.
As for namespacing, I think it's fine just keep your namespacing as consistent as possible throughout your package, which usually starts with Author\PackageName for example:
namespace Panthro\Package;
Though I'd be much more specific than naming the package name as Package.
If you take a look at laravel's plugin libraries, you can learn how they do their namespacing and folder structure too.
Example:
APIRouter - Very simple library
Intervention (Laravel) - More comprehensive and bigger codebase but still easy to follow (structural-wise)
Depending on your package, if you have many types of models, it'll be wise to add another level of namespace for your models, otherwise you don't really have to.
I Searched a lot to find the answer to this question, here on stackoverflow and over on google. But was not able to find anything...
So, my question is: It is a good practice to extend a controller (in my case BaseUserController from zfcuser) once in a module, and once more in another module?
Thanks for all your replies!
It's fine, I would not go as far as "good practice".
Excessive use of inheritance can cause you issues in any language and there are numerous of post around explaining the issues and possible solutions.
From a ZF2 perspective in doing so you will have the issue where Module B depends on Module A which may be a problem - However this really depends your application/module design.
There are other alternatives:
Aggregation -
create new functionality by taking other classes and combining them into a new class. Attach an common interface to this new class for interoperability with other code.
Use PHP traits - If you lucky enough to use the more recent versions of (PHP 5.4+) the you can simply reuse these within each controller class that requires it.
A Custom Controller Plugin - ZF2 has a "pluggable" API within the controller, meaning you can write self contained helper classes that can then be used in any controller - No need to extend. You are almost certainly using these already with $this->redirect() or $this->params() so they might be good places to start to see how they are built.
I am searching for a Blogging tools like wordpress. But I want MVC based tools to extend my blog with MVC structure.
My main requirements is
Must be based on MVC
Simple & lightweight
it's blog url structure should be domain.com/cat_name/post_title , because my current wordpress blog is like that, I don't want to lose Facebook Share and Tweets.
I want a simple one, because this is learning only.
Clarifying: if a CMS you use is based on a MVC design pattern or not is irrelevant to you as an user, except if you want to meddle with its inner workings (which you don't - a CMS is made to be used and possibly extended, but in 99% of use cases, if it isn't extendable to your needs, changing the source code is a bad idea, as it will most likely break with any updates you may want to make)
You may want a MVC framework, which will in turn allow you to **code** a CMS of your own, or use a good, extendable, CMS app
The one I use is ProcessWire, which is a CMS/CMF (F stands for Framework) php app, and seems to be the kind of thing you are looking for - it manages your content for you (the default installation comes with a few demo pages) but you define the fields, and you use them to display your content at will. Check it out - the user forum is quite active, and people there are really helpful.
Well there are tons of Content Managment System Based on MVC frameworks (eg . CodeIgniter ) . I personally recommend Pyro ( Based on CodeIgniter) but other also seem promising . but i don't know much since i haven't tried .
Note that this is a highly relative question and will bring forth a ton of opinions and not real answers. With that in mind, here is my answer.
I know of a tool that you can use to install an MVC template for and on top of ProcessWire along with basic project managing tasks using gulp. Note, the M will be considered ProcessWire.
Have a look on github.com and look at the profile of fixate and repo generator-fixate-pw. (ie: generator-fixate-pw, added the sentence if the link breaks).
Install this by following the instructions on the repository. The tool is very specific but learning to use the framework helped improve my php skills allot (still learning allot).
Whether the CMS will be used as a blog or not will depend on your implementation of the install.