Both extend the features and functionality of Magento, but what are the differences between them?
I've finally found the answer.
Extensions are simply packed modules. In other words, you extend the features and functionality of Magento by writing a module. Then you have a choice to leave it as it is or pack it up (System > Magento Connect > Package Extensions). An extension (a packed module) is then published on Magento Connect.
The Main difference between extension and module is that, when you create any extension it can be for community as well and can be used by others installing simple package as it is. And module are something that is part of core magento it can be for your own purpose and for others too. Not necessarily you will create package of it to have it work .
In Most cases solely you will use them
The main difference is that you can realize the main functional with an extension or a component. And with a module you realize an additional functional. Extensions include modules, or modules extend components.
Related
I develop with Visual Studio. I have a class library that contains code common to many products I develop, and is now in use by 15+ solutions. I do LOB apps for my non-software company.
I've been adding this class library project directly to the solutions of all the solutions that need to use it. But I've been using NuGet to pull in many 3rd party packages and I really like its way of doings things. I'm thinking about adding this utility library as a NuGet package in our own repository rather than adding it directly as a project reference in the solution.
Is this a good idea? What criteria should I use to determine when to use NuGet vs when not to for internal class libraries? I realize that some might think this is an opinion based question, but I'm looking for specifically what criteria you'd use to decide rather than opinions about which is better.
Internal libraries that used and worked on by multiple teams can be exposed as Nuget packages. This way, multiple teams can work on the library, and each of them can update to a version as and when needed by that particular team.
Where place my custom files in magento if i want develop extension in design/frontend/base/default or design/frontend/default/default. I think be logic place it to design/frontend/default/default, but i am find opinion about that good practice place it to design/frontend/base/default
Thanks!
It depends on what Magento versions will you support.
If you plan to make your extension work on Magento 1.3 and lower than you should put your design files in default/default.
If your extension is for versions 1.4+ then place them in base/default.
You can see other tips and tricks that might help you when building an extension in here
I have been learning to develop my own plugins and components for joomla! 2.5.
After a couple of months of developing features for my site, I am starting to realise that some of the components I have created could have probably been just as effective if I'd developed them as a plugin for com_content or com_user.
My question is what's the best way to decided if a full component is needed and when is it ok to use one or multiple plugins to give the same functionality.
My feeling at the moment is that plugins are a much nicer way to go due to them being self contained. Maybe I've answered my own question, and components are needed when interaction between elements is more complicated, where as plugins can be used for very modular functions.
Anyone else have a view?
Components and Plugins are completely different types of extensions.
Components are applications/systems that will appear in the content area such as VirtueMart and where the articles are shown. Consider them as software for you computer.
Plugins are there to manipulate Joomla and/or there extensions it's using. They contains functions that are associated with trigger events. So in a nutshell, they are there to extend the functionality of an existing extension.
So so answer your question, have a think about what you are creating and if will be an aplication or something to extend functionality.
Hope this helps
I had an issues with some joomla api. The issue was that I was using the latest version of joomla and couldn't find where a joomla class, that was being called in my code, was derived . I searched the joomla api docs and found nothing relating to the class I was looking for.
I then stumbled across the refactoring change log for joomla and noticed that the function i was after had actually been moved from /libraries/joomla/form to libraries/cms/form.
Why would this be the case? There doesn't seem to be any reference to /libraries/cms in the api docs. How are we suppose to know that there are classes living there? Very confusing.
Since Joomla! 1.6 the code has been progressively split into the Joomla! CMS and the Joomla! Platform. You can see this separation in the github repository - a good place to also keep track of changes that are committed to both the CMS and the Platform. The simplest way is fork each repository and keep track of them.
As classes are updated they may be migrated to the /libraries/cms directory if they apply specifically to the CMS application (e.g. html forms are an application level function not a platform level).
I find the best place to hear about changes under discussion are in the respective Google Groups - Joomla! Platform Development and Joomla! CMS Development
[Edit]
Documentation of class's is the hardest thing to find for Joomla! CMS - there doesn't appear to be a current api listing for it, unlike the Platform API reference. Often it is just easier to read through the code.
It's also worth keeping a watch on the developer sub-site.
If you want to define excellence in CMS without coding, Joomla is the right option for you.Joomla the most preferred content management system among developers is an easy-to-use open source solution.If you want to define excellence in CMS without coding, Joomla is the right option for you. In this post, you will find few of its features that make the website development easy and most preferred option for developers.
I'm building several sites that need similar "modules." For example, the sites may have the exact same login system, forum, etc.
Is there a way I could build these modules once and just "drop" them in these various sites? Some of the challenges I see:
Keeping the code consistent in the various sites. Any changes made to a module should propagate to all of the sites using that module. I guess I need a way to upgrade?
Database: these functionality need to work as part of a bigger application. Maybe the module needs to define relationships with other tables in its respective site.
I'm sure there are more problems. I think I should be looking at this: https://bitbucket.org/wiredesignz/codeigniter-modular-extensions-hmvc/wiki/Home, but I don't have any experience with it.
So, I'm looking for solutions, suggestions, or more problems to this idea.
You can create and use third party packages by adding them to the third party folder (which is new for CI 2). There is not much about it in the docs, but i found this.
http://codeigniter.com/user_guide/libraries/loader.html
You can autoload the third party packages in the autoload file. Packages can have their own controllers, models, views etc.
Interestingly, Phil Sturgeon wrote a bit (http://philsturgeon.co.uk/blog/2010/04/codeigniter-packages-modules) about packages not being modules (in the strict sense of the term), but you could probably use third party packages for what you need.
I would write them as libraries and use Git submodules to manage each module. Phil Sturgeon actually just wrote a great post about doing this in CodeIgniter.
If you're not using version control, I can't see an easy way to sync across all of your applications. Yes, HMVC will let you break apart your application into actual modules, but it won't help in syncing those modules across your applications.
Here is my question about 'Database communication in modular software'
that you may find useful.
I'm little bit familiar with Drupal, and as a modular application, I think it can be taken as good example of how relationships between modules should be defined.
Here is one good post about art-of-separation-of-concerns
I would like to hear if you have run into some concrete challenges, solutions and references concerning modular design in CI.