There seems to be two styles of folder structure in the core Magento when it comes to resources. There are quite a lot using the mysql4 folder and other simple using Resource folder.
I.e. install script would live here: Mycompany_Mymodule_Model_Resource_Setup.
Is there a reason for this, legacy or otherwise - or is this simply a coding style between different core developers?
First: Magento's folder structure exists only because of its autoloader's implementation. If you try to derive too much meaning from where a file is placed in Magento you'll go mad, and different modules seem to follow different conventions. The autoloader will look for
Mage_Core_Model_Foo_Bar
in
Mage/Core/Model/Foo/Bar.php
So I'll be talking about naming conventions below, which will indirectly address why a file is in a particular folder.
Originally all database resource were named with the Mysql4 convention. I've talked to a few of the original developers, and the intention was to denote that the resource was for the then "standard" Mysql 4 database. If a resource used a specific feature of say, Mysql 5, then they'd have used a Mysql5 convention.
As Magento Inc. went through the usual startup churn and other developers took over where the original developers left off, the thinking changed on this. The Magento 1.6 release, which laid the groundwork for Enterprise Edition's support of multiple RDBMS, altered how these resources worked and were named.
Backwards compatibility was maintained, but most of the old Mysql4 resources were renamed to use the generic Resource, and a new method for multiple RDBMS support was introduced.
Related
I have the following WebSphere Liberty file layout (with a few choice directories and files show) which uses a custom usr dir of wlp-usr.
wlp/etc/server.env
wlp-usr/servers/server1/apps/
wlp-usr/servers/server1/extension/
wlp-usr/servers/server1/resource/
wlp-usr/servers/server1/bootstrap.properties
wlp-usr/servers/server1/jvm.options
wlp-usr/servers/server1/server.xml
wlp-usr/servers/server2/apps/
wlp-usr/servers/server2/extension/
wlp-usr/servers/server2/resource/
wlp-usr/servers/server2/bootstrap.properties
wlp-usr/servers/server2/jvm.options
wlp-usr/servers/server2/server.xml
The file wlp8554/etc/server.env contains
WLP_USER_DIR=/home/me/wlp-usr
I want to get the servers (there will be more than 2) using their own extension folders, rather than the default wlp-usr/extension/lib.
The documentation on Liberty directory locations and properties suggests that usr.extension.dir is what I want. http://www-01.ibm.com/support/knowledgecenter/SSAW57_8.5.5/com.ibm.websphere.wlp.nd.doc/ae/rwlp_dirs.html?cp=SSAW57_8.5.5%2F1-3-11-0-2-3
I have tried setting this in bootstrap.properties and jvm.options, but without success. I am wondering if this is a read only property or if it is something that I can actually set. Has anyone used separate extension directories before? Is this even possible? If so then some guidance on how would be most appreciated.
Cheers, Steve
The usr/extension directory is per-user-directory, so it is effectively read-only from a server perspective (all the variables on that page are derived and cannot be changed except wlp.user.dir, which can be set by WLP_USER_DIR, and server.output.dir, which is derived from WLP_OUTPUT_DIR). That is, it is not possible to have per-server extensions. If you really need that capability for some reason, then I would recommend opening an RFE.
That said, usr/extension is really intended for convenience during feature development (or perhaps for minor deployment scenarios). Product extensions are really intended to be applied to an entire installation, so they should probably be used for any sophisticated environments. Since individual servers are unaffected by extension features unless they enable them, there should not be much reason to have per-server extensions anyway.
When developing a module that will be reused outwith the scope of any one particular project i.e. using the community code pool, should I use the base theme to store my template, layout and skin files?
I am almost 100% certain that i should, but i see so many community modules using the default skin and theme directories that it has planted a tiny seed of doubt.
Yes, you should absolutely be using base/default for your community modules theme - in doing so you are utilising the fallback hierarchy Magento provides, allowing your theme to be portable and easy to extend by clients wishing to do so.
I'm not expecting upvotes for this answer, but would like to clarify on Tim and Drew's answers:
Unfortunately at the moment Magento only provides us with 3 levels of fall-back:
base/default
current_package/default
current_package/current_theme
Because 'current_package' is 'default' on standard Magento installations, you will often see extension developers place their files in 'default/default'. That is poor decision-making as it will mean the files will no longer be found when a non-default package is specified.
Obviously placing files in 'base/default' is also not the most optimal place, because in a sense you are removing the distinction between core and 3rd-party files. As others have mentioned, right now it is the only way of reliably adding your files while still allowing fallback to take place.
Fortunately, this will not be an issue in Magento 2, as these files will be part of modules instead, allowing pretty much infinite fallback.
Yes. Best practice is to create
app/design/frontend/base/default/template/your_extension_dir/
and
app/design/frontend/base/default/layout/your_extension_dir/
and put your files there.
I have an existing MFC product and am planning on supporting a couple of other national languages thru the use of resource-only DLLs. I've read a number of articles and tutorials on how to go about this, but admit that I don't have a lot of in-depth knowledge of Windows resources (mostly just use VS 2008's graphical interface).
The major area that I am trying to understand is that it seems like all of the resource source files (i.e., resource.rc) for these DLLs -- and the main program -- should be sharing the same copy of resource.h. After all, all those IDD_xxx values have to be consistent, and it seems like making updates to the resources would be even more complicated by having to keep multiple resource.h files in sync!
So am I correct on this, and does anyone have any tips for how to best implement this? Should I modify resource.rc in the DLL projects to point to the "master" resource.h in the main program directory?
Yes, use the same resource.h file for sure.
One way is to just copy the resources you need to be translated into the the new resource project--stuff like menus, strings, dialogs. Bitmaps and icons probably don't need to be translated unless you put some text on them that is language specific. If you know your localse, at program startup you can call AfxSetResourceHandle() with the resource DLL you manually load.
Another way to approach the problem if you have a multitude of DLLs and EXEs is to use binary resource editing tools. What they do is create token files from your resources. Your translators edit the token file with the binary editing tool. When all is done, you run a tool to apply the translation to the binaries. Basically, you don't distribute resource DLLs, but distribute different versions of your DLLs for each language. The tools are smart enough so that if you make a change like add a string or dialog, it will get picked up and your translator can see that he needs to translate something new. The previously translated work will be saved in the token files. This is how we do it at my shop. We used to use Microsoft's Localization Resource toolkit. I don't know if we still use it or not since it is somebody else's responsibility now.
I found the MSDN article ID 198846 a good starting point for sharing of resources via a dll, though it does need updating for newer versions of visual studio, it was quite easy to follow and understand.
http://support.microsoft.com/kb/198846
I'm using Magento 1.6. I've created my own theme (mytheme) under base.
So my file structure is app/design/frontend/base/mytheme
I could also develop my theme under app/design/frontend/default/mytheme
Which is best practice? And what are the implications of using base/mytheme rather than default/mytheme?
Cheers,
Eddie
I do disagree with the solution of Mr Storm.
ref: http://www.magentocommerce.com/knowledge-base/entry/magentos-theme-hierarchy
Those documents recommend You avoid to use the package default (as the base package too)
You have to creating Your own package 'mytheme' and to define a theme 'default'
ref: http://info.magento.com/rs/magentocommerce/images/MagentoDesignGuide.pdf
"Please ignore legacy Magento instructions and tutorials that instruct
you to create your custom theme inside of the default design package,
or to edit files in the default/default directory directly.
Rather,
the method that affords the best upgrade path for your theme and the
most protection from accidental changes is to create a new designpackage
and to create your custom theme inside of there."
So the correct answer is
app/design/frontend/your-package/default
Do NOT use:
app/design/frondend/default/your-theme
You don't want to put your theme in the base folder. The base folder is meant to contain the "core" theme that ships with Magento. It's the ultimate fall back, and the last place a file is looked for. It was specifically introduced to provide a place where core Magento developers could blow the entire directory away and replace everything (if need be)
To create a theme for Magento, you'll want to create a theme folder in your design package
app/design/frontend/default/mytheme
Then, in the admin go to
System -> Configuration -> Design
and enter mytheme in the Default field. Your theme will now the the "default" place Magento looks for files. If it doesn't find one, it will fall back on what it finds in the base folder.
I have a zope instance with many plone sites each for different customers. I want override particular translations such as the date format just for a single plone site without affecting the others. How do I do this?
Tutorials such as http://maurits.vanrees.org/weblog/archive/2010/10/i18n-plone-4#overriding-translations seem to indicate custom translations override all sites on a zope instance.
This is how I solved it. It's a bit of a hack solution but it worked for my particular scenario.
As per http://maurits.vanrees.org/weblog/archive/2010/10/i18n-plone-4#overriding-translations I
created my own locales package.
overrode the the plonelocales domain just for one particular language variant, in this case en_AU.
loaded the package in zope via buildout with particular attention to make sure it's the first ZCML slug (not instructions in the blog post incorrectly state it must be the first package in the egg section. This wasn't enough to make it work for me).
for each site I wanted to switch date formats I went to site setup > Languages and switch the language to "English (Australian)".
The other gotcha is that when releasing and deploying your locales package make sure that you've
generated the the .mo file first (done for you if you run zope locally)
and you've used an MANIFEST.in file to tell setuptools to include all .mo files as you shouldn't put .mo files under source control and by default setuptools only includes files under source control.
This does not get me a custom date format for every single site but good enough if the custom date format you want is actually that of the language variant you choose to use.
You can implement your own zope.i18n.interfaces.ITranslationDomain utility which looks up translations in a different place. The normal translation domain utilities stores a list of gettext message catalogs. Those are loaded from mo files on the file system and registered with ZCML.
But you can implement a different translation domain, store it as a persistent utility per site and give it some additional storage to look up messages in.