To be clear, I'm not looking for opinions but rather facts based on actual in-the-field usage of different file structure types.
In researching, before asking this questions, I've seen many posts about what the right folder structure is for a web application. For example, I'll see someone list where the following should go: css, js, html, images, php. But, I haven't seen anyone go into much deptch about what the static directory structure should look like.
I have a lot of images in form of static/images/mustang_2017_front.jpg using Ford vehicles for example. Is it best to keep them in this flat file format or use a hierarchical folder structure such as static/images/mustang/2017/front.jpg. All the images are the same type for each car (e.g front, side, rear, top). Also, though I'm asking about images, I think the naming conventions standards apply to static files in general.
Option 1- flat
static/images/mustang_2017_front.jpg
static/images/mustang_2017_side.jpg
static/images/mustang_2017_rear.jpg
static/images/fusion_2017_front.jpg
static/images/fusion_2017_side.jpg
static/images/fusion_2017_rear.jpg
Option 2- hierarchical
static/images/mustang/2017/front.jpg
static/images/mustang/2017/side.jpg
static/images/mustang/2017/rear.jpg
static/images/fusion/2017/front.jpg
static/images/fusion/2017/side.jpg
static/images/fusion/2017/rear.jpg
Here are some of the benefits I can think of for each approach, but they're from a human perspective. Is one of the options easier to work with in code? Does it matter much? I just don't want to be setting myself up for something that's not scalable in the future.
Option 1- flat Benefits
all files have all information in the name
Option 2- hierarchical Benefits
from a human perspective it's easier to manually navigate and find what you're looking for using a hierarchical folder system instead of having a large number of files all in the same folder
To be clear, I'm not looking for opinions but rather facts based on actual in-the-field usage of different file structure types.
It is very much A. a matter of opinion and B. it depends on the actual implementation.
How are the files going to be used and by who. If your visitors are going to be downloading images from your site, they might end up with 10x front.jpg in their download folder. So for me that is not great. Also whoever is processing the files (e.g. a designer) could have the same name open in e.g. Photoshop and this won't make it clear. So I would say that option 2 isn't great in most cases I can imagine.
Option 1 however can result in a massive single folder with thousands of files.
I like stuff being descriptive and clear, to suit most cases. There is an Option 3 also; static/images/mustang/2017/mustang_2017_front.jpg. In my opinion this has the best of both worlds. The file name itself is descriptive and your folders are organised. You could easily delete e.g. 2015 when it's not used anymore.
Also think about if it should be mustang/2017/ or 2017/mustang/ for your case
Related
Though there are lot of similar questions already asked here, I didn't find the answer i was looking for..
What's the best way to develop multi-language application, It should be very fast.. and i don't know how much text i will translate.
Method 1: create and keep all the text in an array for every language i want to support and include that file everywhere.
Method 2: Use gettext (.MO, .PO files)
Method 3: Store all the translations in a text file and write a function to go through all the text and when matched display its value
Method 4: Store all the text and its translations in database, But i don't think it will be faster than storage in Filesystem.
Method 5: Same as method 1 but i will create multiple files per language just to keep everything structured.
Though all of these will work, Which do you guys think will be the fastest method and do let me know if i missed any method.
This is a complicated problem and its not always as obvious as you might think. You may in some cases, with right to left languages or particular cultural reasons, need to develop separate layouts for a particular region.
Regardless of which method you choose, you will want to cache all of or parts of your pages and use a cached version if available before regenerating the page again.
I would probably avoid 3 and 4. You don't want to be reading from the disk more than you have to. If you can cache translation arrays in memcached, you can save yourself disk access in loading translation tables.
As a person managing localization projects for developers, I have to say that both sides (translators and developers) have been very happy with Gettext (.po files). It's relatively simple to implement in your code (basically a wrapper around any text you want localized), it's seamlessly fast, and most importantly: it scales and updates flawlessly.
The main advantage is that lots of tools exist for creating, updating, managing, and translating .po/.pot files, including the cross-platform PoEdit. When you have dozens of languages to do, it's as easy as extracting the latest .pot file and sending that to the translation team. They'll return individual files for each language. I haven't seen many systems that can scan and locate new strings as easily or present them to translators for use as simply.
I would recommend looking at PHP Frameworks which support multiple languages. Investigate the most popular first, Zend, Symphony and Yii. I have used Yii before and this has multi language support.
http://www.yiiframework.com/extension/yii-multilanguage/
More and more I find websites that show this kind of links:
website.com/page/
and testing if there's in index.php inside the folder like
website.com/page/index.php
I found always true.
So my question:
Is it a common way to put all your pages in subfolders even if it's a single file that you could also easily put in the root folder (in this case page.php) or is there a "common" rewrite for it?
If yes, I'd like to know how a typical folder structure for this case would look like.
I just got a bit confused and don't want to do it "wrong" on future projects.
And beside: Does this technique effect SEO?
If it's a static site then yes it's quite common to have just one page in a subfolder and having that page named as index.html or index.php because most servers are configured to pick that up without showing the filename.
One reason for doing this is so that if future pages are created that would naturally come under that subfolder then it keeps your site structure and site map neat and tidy.
These days many CMS systems replicate this sort of structure on the fly.
For SEO purposes it's good to have descriptive directory names and/or page names i.e.
news/the-title-of-my-news-article.php
Hope that helps.
URIs more often than not have nothing to do with the actual structure of the files. Take Stack Overflow for example: This page's URL is
http://stackoverflow.com/questions/12090658/is-it-typical-to-put-all-pages-in-subfolders-even-if-its-a-single-page
If we follow your logic, it means that stackoverflow has a questions folder for all questions, then a specific ID folder for every single (over 2 million) question, then another folder, with it's complete name, and inside of it an index file.
No, that's not the case. URLs are often rewritten to allow for increased complexity of application.
As for your specific question, perhaps there's a special meaning, perhaps there is none, it's up to the webmaster to decide that.
Even if you get some results when you hit website.com/page/index.php instead of website.com/page, doesn't mean there's a file there. In fact, it doesn't mean there's even a folder named 'page': the power of mod_rewrite may easily transform the URL
http://example.com/page/index.php
... into
http://example.com/index.php?controller=page
... so there's a single file executed each time someone queries this application (Single Front-End Controller design). Following this approach makes it not necessary to create a slew of folders for each and every possible user story.
But it's quite true that you should organize your web application into modules (which, in turn, are usually organized as sub-sub-folders of /modules application sub-folder). There's a very popular paradigm - MVC; it's quite commonly used by PHP frameworks and CMS built on this language, but it's not necessary to use one of these to follow it. Perhaps this tutorial might be useful for introducing MVC in PHP to you?
Using PHP i want to create a picture gallery, i need a few suggestion on what would be the best logical solution for this.
a) create a directory for an album and move all the related pictures into the directory and henceforth follow the same way for other albums
b) keep a record or the path using the database(MySQL) and use the relational table (album).
for the method a . is there any way to deal the picture gallery without actually having the need to use the database or XML or whatsoever(database).?
what is your take on this?
thank you.
IMO the database route is the one to take, as it will be much more extensible and easier to maintain.
If you decide to add in a rating/description/review/[whatever] at a later date you will have the foundations in place.
you can still create a directory for each album - WordPress adopts this kind of practice (/uploads/2010/10) for instance - (directories for each month)
you could do it without a database, through some means of directory traversal and an imaginative naming scheme - if you wanted to sort or search the images some common naming format would be needed. Plus you are very restricted on meta data.
+1 for database from me. You ~can~ even store the images in the DB. but I prefer to keep them as images and just link to the path.
my $0.02
Personally, I would do a combination of both. You will want to move the pictures into a folder structure that makes sense. Whether or not that is by user or by album or what, that is up to you.
You could potentially use method A and ditch the database by keeping each gallery in a properly named folder and then just open that folder and loop through the contents every time you wanted to display the gallery, but it would make your life much more difficult and it wouldn't make much sense.
By using a database, you have all the benefits of a relational data structure... photos can be linked to galleries and tags can be applied to photos.. you can store permissions by photo or by gallery... you have way more options when going with the database.
Sorry for the confusing title....
We are developing an application to be used by multiple companies. For the most part, the application is the same, your standard sort of database manipulation pages (search pages, edit pages, etc.) customized for the data that it is designed for.
However, each company has a slightly different process, and we will be dealing directly with each company so we'd like to use some sort of system that would allow us to tweak pages depending on which company is viewing the page. For example, one company might want a couple extra fields on a data input page, or another company might want to view a different piece of data on a search results screen, and so on.
I understand this is all hypothetical and I wish I had a concrete example to give you, but honestly the companies haven't even given us very good examples. We just want to be ready.
So my basic question is, what is the most flexible way to allow for these tweaks and customizations on a per-company basis? Obviously, the most flexible but least programmer-friendly way would be to make a complete copy of the app for each company. This obviously isn't an option because we'd need to manage updating code on all the sites, trying to keep them all running and tested and having issues resulting from the customized code.
What are your thoughts on Smarty being a solution to this? Perhaps if we have a master set of templates, but then each company can have a different subfolder with any replacement template files... Of course we'd still need to update a bunch of different template files whenever we change one of them, but it would be a little more localized anyway.
Is there a better way? Some sort of differencing template engine maybe, so that we can still edit the original files and the changes will adapt on top of the originals (kind of like a patch)? Or perhaps we should use the object-oriented features of PHP5 and then use polymorphism? What is your best suggestion, and especially if you've had experience with this sort of thing, what are the options and which have you used and why?
I think the template method pattern will help you out a lot. It's really a great pattern for factoring stuff that is mostly the same but differs in a few places. I'm actually working out a template method hierarchy for my own project right now.
I would suggest you try to create the application either using an mvc framework or using your own implementation of mvc.
In this manner you could create models that could be reused (and also views) for other companies.
I just wonder what is best practice to store template files? In CMS I have using templates and some of parameters are stored in database... But there are some issues then i need to change something in templates or change one of parameter in many pages. Site has 100K unique visits every day... and I don't really want to make experiments with site. Just whant to know what is best for performance, to store templates and parameters in database or in file?
Database access will on the whole be quicker (for many concurrent reads) than disks (unless highly mirrored). And it is more scalable but this depends on configuration making this highly subjective.
extended
Because your files will be quite small, memcache+SQL backend is still better than JBOD or sync of directories between nodes. Unless you want a SAN/NAS but that will work out more expensive if you just want to serve a bunch of small text segments. This is based on the fact you are probably already using an RDBMS of some kind.
Really, it depends on too many factors to go into.