I did a bit of searching and found this thread on the topic but it's specific to XML files, and so the answer makes sense (/etc/) for XML files.
In my case, I'm actually storing a txt file, which happens to be an SVN version number that I dumped out within my modman script.
The place that I'm using this is within a frontend model (Blocks/System/Html.php) which outputs the version number within the module config. So I went with the Blocks/System/ directory for now - the filename is Version.txt - but it feels like there should be a better place to put this.
Since this SVN version number is being written by an external tool I would prefer it not mess with the contents of code directories (which in a live environment may have write restrictions) and instead have it write to the "var" directory. In which case to get the correct path within "var" you would use:
$fullpath = Mage::getBaseDir('var') . DS . $path;
The contents of "var" are disposable, they may be deleted at any time so be prepared for a missing file.
version numbers can be added to app/code/local/Your/Extension/etc/config.xml
<config>
<modules>
<Your_Extension>
<version>0.0.0.0</version>
</Your_Extension>
</modules>
</config>
magento knows how to handle your extension version changes and can call update scripts based on version number change. This is the preferred method for this kind of stuff.
if you need to add random non php classes files to your extension then add them to your extension folder and ask them from there:
Mage::getModuleDir('etc', 'Your_Extension');
Mage::getModuleDir('whateverfolder', 'Your_Extension');
This is not a good practice though as this might just break magento compilation feature or introduce other issues so it is better to handle external data also through php classes or xml files inside your extension structure
I ran into the same kind of problem when developing a shipping module. I had a bunch of CSV files that contained maximum weight / delivery cost mappings. For what it's worth, I created a data/ directory at the module level and threw everything in there.
I don't think this kind of situation doesn't happens often enough in the Magento codebase for there to be an established convention. As long as you use sensible naming, and provide a level of abstraction to cope with any change of file location in the future, I'd say put it in any folder at your module's root.
Related
I have a parseFile function that given a file parsing for certain information and returns a struct. How do I write a test for this function?
With Java, I could have a file in the test folder but I not sure how to best do it in Go.
Thanks and regards
You can do exactly the same in Go, albeit it is handled a bit differently.
Create a folder called "testdata" next to your *_test.go files.
This folder is by convention ignored by the go tools, as are all folders beginning with an underscore. This is why I name my resources directories for web applications _components instead of bower_components, for example.
Now, you can access said folder with a relative path from your tests, and it won't pollute your namespace or sth.
You should be able to commit a file to the same folder as your test, and read in a relative path by way of os.Open("./path_to_file").
If the issue is that you're looking for a file in a specific location, I'd recommend parameterizing whichever method loads the information to accept different filepaths.
I have setup a simple website based off of this structure. I run main.go and everything works fine. I'd like to be able to use this webapp in another package, say "github.com/my/package". I copied "main.go" to the "github.com/my/package" directory and run it but then get:
"panic: open templates/user/view.html: no such file or directory"
What is the recommended way to modify the path to the template file in this file, for instance, so that I can access the templates? I can think of two solutions:
Hardcode an absolute path in view.go to the template file.
Have a global variable in view.go then figure out where the template files are in relation to the new main.go file & set the variable to that path.
The first will obviously break if someone else were to try to use the package. The second option is a bit convoluted b/c you need to find the path to main then work your way through & figure out where the templates are...seems very convoluted.
Is there a better way?
you could look at go-bindata. It makes external files, like templates, as part of the binary. Although it's not a great solution if you want to be able to change the templates without recompiling
If there is functionality meant to be used as a package/reused elsewhere, then the idiomatic way to do this is to move that functionality into a package - typically in the pkg directory.
Obligatory camlistore example is at https://github.com/camlistore/camlistore/tree/master/pkg
Another resource for how to do this is the '12 golang best practices' talk
Here's how I usually develop an application:
I start with having all the code in a single source file.
When it grows enough to be modularised, I break the code into several modules.
When the modules grow enough, I split them again. And so on, iteratively.
Over time, some modules get shrunk, deleted or merged with others.
This workflow implies the need to move source files between modules sometimes. And here comes the problem:
When I move a module to another location, it changes the module's name, so I have to walk through all the other files renaming imports by hand.
Is there some organisational technique to avoid that annoying procedure? Or is that the way it goes and I just have to look into some automation utilities instead?
you can create a *.all module that public imports all modules in the package
then you only need to add/remove the module names from that module
You can override module name via module packagename.modulename; directive in the beginning of the module. It will need a help from the build system though as rdmd uses module names from import statements to form file system path to search for their sources. But if you will supply all source files project consists from by hand, it should resolve module names just fine.
It's better to define your entities before you start coding. You can use some modelling language to identify and write your entities. For example if you are using java to code your application then you can use UML to model this application.
Also, you have to separate buisness logic from data.
If you continue to do it like today you will lose a lot of time just dealing with filenames.
My application is to be written using wxWidgets, but the question may be related to using gettext in general.
For the application named app, some sources suggest I sould create <lang>/ subdirectory, create the app.po file inside with the translation, and convert it to the distributed app.mo file in the subdir.
Another approach is to create app.pot (i.e. the template from the sources via xgettext), and to msginit and msgmerge it to the <lang>.po for the language.
For the first approach, more .mo files can be put inside the <lang>/ subdirectory. Also the wxLocale::AddCatalog() gets the domain name (where the domain can naturally be app, wxstd, etc.). On the other hand, the <lang>.po file name is descriptive on itself -- wherever it is located.
What are the pros and cons of the two approaches? Is there any text that explains the path to be chosen?
Thanks for your time and experience,
Petr
The Unix convention is to use app.mo for binary catalogs, see the contents of /usr/share/locale directory. Sometimes lang.po is however used for the source ones, as done in wxWidgets itself (see its locale subdirectory), but they're still installed into language-specific subdirectory using the app-dependent name.
As I create more applications, my /code/shared/* increases.
this creates a problem: zipping and sending a project is no longer trivial. it looks like my options are:
in Xcode set shared files to use absolute path. Then every time I zip and send, I must also zip and send /code/shared/* and give instructions, and hope the recipient doesn't have anything already at that location.
this is really not practical; it makes the zip file too big
maintain a separate copy of my library files for each project
this is not really acceptable as a modification/improvements would have to be implemented everywhere separately. this makes maintenance unreasonably cumbersome.
some utility to go through every file in the Xcode project, figure out the lowest common folder, and create a zipped file structure that only contains the necessary files, but in their correct relative folder locations, so that the code will still build
(3) is what I'm looking for, but I have a feeling it doesn't as yet exist.
Anyone?
You should rethink your current process. The workflow you're describing in (3) is not normal. This all sounds very complicated and all basically handled with relative ease if you were using source control. (3) just doesn't exist and likely never will.
A properly configured SCM will allow you to manage multiple versions of multiple libraries (packages) and allow you to share projects (in branches) without ever requiring zipping up anything.