I hope this is not the wrong place to ask this, but this is driving me crazy. I'm making a website with a friend.
He've structered everything. I took a look and the site and it said
http://site.com/account/
I thought to myself, good, he is using url rewriting.
So today I found out that there were no url rewriting, he had crated folders with index files. So the example above would work like this:
Our public_html would have like twelve folders, each containing an index file. When I saw this, I told him I found it very unprofessional and asked him to change it. He's telling me that it doesn't make a difference since the outcome is the same, visitor wise.
What disadvantages are the from using his method contra url rewriting?
One thing that comes to my mind is that i have to change the source of every css file, scripts etc. whenever I enter a folder.
Not sure about unprofessional part but this approach is definitely a maintenance nightmare. Today he has created 12 folders with their index.html, css, js files etc. Tomorrow your website may expand (who doesn't want to expand) and you will need more folders. You may need sub-sub URLs like:
http://site.com/category/books
http://site.com/category/books/fiction
http://site.com/category/electronics
http://site.com/category/food/organic
etc etc. How long he can keep creating folder and sub folders like this.
Let's say he's doesn't mind and is ready to do it hard way. But what are you guys going to do if some day you want to change look & feel of your website. How many index.html, css, js file are you going to change?
My 2 cents: Use some CMS.
Related
I'm working on a website with Github pages. My code has been reviewed and it said to be correct, but my images and video do not display when I look at the site on my browser. I've read a bunch of similar questions on this site, but the answer was always that the file path was case sensitive. My case is the same, it still doesn't work.
I've tried to use the "raw" url from github. Tried with a ./ and just a / no luck. My email is verified.
Any other suggestions? Thanks!!
https://jeanninejacobs.github.io/excursion/
The top level of your site is at https://jeanninejacobs.github.io/excursion/.
That means that an image located at resources/images/camp.jpg has a full path of https://jeanninejacobs.github.io/excursion/resources/images/camp.jpg.
However, you're using /resources/images/camp.jpg which is relative to the top of the domain, in other words relative to https://jeanninejacobs.github.io. That means /resources/images/camp.jpg references https://jeanninejacobs.github.io/resources/images/camp.jpg, which is wrong because it's missing the excursion subdirectory.
The easiest way to fix your problem is to just use /excursion/resources/images/camp.jpg instead of /resources/images/camp.jpg.
Or you could use a custom domain and get rid of the excursion subdirectory.
There are fancier options if you need something more specific, but hopefully this gets you going in the right direction.
I have also found that the file extension names are case sensitive. For Example, if the files are named *.JPG, the file path must also be in all caps.
I'm pretty new to laravel and so far I'm liking it. Due to some situations where I forgot to include my new js or css files into my layout, Im looking for a way to link all files from those folders.
Im totally willing to create this myself, but I'm not sure what is the best way to do this. So far I have registered some serviceproviders, like viewcomposers and helpers. I was thinking I can make another viewcomposer which collects the folders I want, and link it to the desired layout.
But I don't want to create unnecessary functions (which might already exist). I'm hoping you guys can give me some insight in what's possible in laravel, good/bad practice, useful classes to use etc.
I wouldn't do this.
I would use Elixir (depending on which version of Laravel you are using) to compile and version my assets. This will mean that you only need to include the references to one file CSS file and one JS file in your view.
https://laravel.com/docs/5.3/elixir
You then just need to maintain your gulpfile.
Versioning your assets also means that you never need to CTRL+F5 to refresh them.
I can't seem to figure out the most efficient way to do this.
For example, I have some js files that are needed in both projects(within the same solution), how do I include them without duplicating the actual physical files, which I would rather not do? Same goes for images and css files.
I would also like to know what's the best way to generalize this for including the js resources in other solutions/projects.
VS really seems to be lacking an easy intuitive solution in this retrospect.
Any ideas?
Why does it matter which project they are in? All you really care about is where they get deployed on your web site, and what the path to them from the root of your site is, right? So just pick a place to put them and have and code that refers to them use that path.
I am looking to clean up the file that we store in source control (SVN) for the Magento projects we are working on.
Which files/folder are have no purpose being in SVN, ie the ones are not necessary for the site to function, or are only transient?
So far I have identified
var\cache
var\session
media\temp
var\locks
downloader\pearlib\download
downloader\pearlib\cache
There are some I am unsure about:
var\report
downloader\pearlib\docs
media\catalog\product\cache\
Can anyone provide a definitive list?
http://activecodeline.com/git-ignore-gitignore-file-for-magento-project answers a larger question, but could be helpful none-the-less.
There's a whole bunch of stuff in Magento that doesn't need to be in source control, as it will remain constant (as long as you follow some sane development practices.) The above link goes through all the directories that need not be tracked by source control.
I typically ignore these folders for development, but you may choose to store images if you think it's appropriate:
/var: This is always temp data or data that can be regenerated
/media: These are images and uploads, not really source code, but keep if you want
/downloader: I don't like to use Magento Connect and prefer to install things manually. You can always get Magento Connect elsewhere, so no need to keep it in the repo.
/includes/src: This is compiled source code, you can regenerate if needed. Not really that usefull since we have SSD disks and APC.
We usually have something like:
/app/etc/local.xml
/downloader
/var
/media
Media usually contains images that are configured in admin, like product/category images, logos, CMS images, merged JS/CSS and import/export data I believe.
Some extensions also have files in media that should be versioned (ex. product feed templates)
There is also an htaccess file in var and media so you have to include those.
I am relatively new to Xcode and one thing that has bothered me is that when I add a resource it gets added to the top level directory of my project directory. So for example, at the moment, all of my images are at the top level directory and it makes things look messy. I rather would've liked, for example, to have an images/ folder and then sub-folders within that to store images for certain things, like tab-bar/ icons. Is this possible? Or is it convention to just keep everything in the top level directory?
Someone in the #iphonedev channel at freenode told me something about the build process rule or something, it just seemed too complicated I figured I shouldn't bother, and that most people just kept things at their root directory considering the complexity of the solution. Perhaps it isn't all that complicated though, I just felt it should be easier.
For example I would also like to have a sub-folder for my views, like views/ that stores all of my nib files; currently they are all in the top level directory. And the same goes for my property lists.
I would appreciate it if you could tell me what the convention is, I doubt it is to just store everything in the top level directory. And I'm referring to the actual file system, not simply creating 'virtual folders' in Xcode to organize things, because the top level directory of my project will still be a mess. And if it is possible to organize things better, I would appreciate any detailed help on how to accomplish it.
I think I have heard that in the final build, the entire file structure gets squashed to the root directory. I don't mind so much about that, I just want things to be organized while I am working on my project. I think this is where that 'build rule' thing comes in, but I'm not sure how or what to do.
Here's a little more explanation of Graham's suggestion:
Create an images directory
Create an images Group in Xcode
Right-click the group and Get Info
"Choose..." to set the group's directory to be your images directory
Now, anything you put in the images group will automatically go into the images directory. That's true if you drag/drop from within Xcode, from other other projects or from Finder, or if you Add New... by right-clicking on the images directory. (This assumes you leave the default setting of "relative to group" in the info pane.)
This will work for anything you put in that group (NIBs, etc).
For imageNamed:, you just give the base name.
My recommendation is to keep a small number of filesystem directories, and mostly organize with groups in Xcode. But I agree, a small number of filesystem directories are very helpful. I put all my source code in a Classes directory (just because Apple used that name; I would have picked "Sources" or something). I also have a Resources directory at the top level and generally create images and audio directories under that. But I don't generally create a lots of real directories beyond that. This keeps things a bit tidier, but makes it easier to grep and wildcard things with the shell.
Beyond shell tools, the big advantage of organizing by groups rather than directories is the impact on version control systems like subversion. When you suddenly realize that your "Views" group is way too big, you can reorganize it without taking the huge impact of moving files around.
The accepted answer didn't work for me in Xcode 4.3.2. Looks like they removed the "Get info" menu option. Instead I did this:
Created the directory on disk where I wanted it.
Went to the file menu
Right clicked on the group I wanted to add to
Selected "Add Files to PROJECTNAME"
Added the files from the directory I created in (1)
Life is hard for IDEs. They have to mediate between a filesystem world, where the compiler, with its source files live, and the UI world, where programmers work.
In the old times that formed the contemporary coding culture, everybody, compilers and people, used to live all togheter in the filesystem. So today we still have a tendency to think we want to control where sources and resources reside on the disk. That is good, because we may need to know exactly what compilers eat.
Anyway if you think your IDE just as a the frontend of a funny database system of source code and if you really have full confidence about its capabilities and features (which is seldom the case), you may get to the conclusion that if you just don't care about the filesystem you may have a better life, as a programmer (and as a human being).
You're right wondering, because Xcode is not very good nor friendly about filesystem code organization and people that is (correctly) picky on that will learn how to move files on their right folder on disk, and on their right Xcode group. That, if you use the "Create folder references for any added folders", have a 1:1 relation.
But you will see many people, and many project examples from Apple itsef, that use a simple flat filesystem tree with everything in the same folder.
My advice is that you at least group public headers and resources in different folders, something à la Java/Maven, but there is no universal convention.
It's actually really easy to get from where you are to where you want to be. Create the images/ folder and put all the images in it. Now in the project window in Xcode, the image files have gone red because they aren't in place any more. Get Info on them, and "Choose..." the new location.
Note that just because you've moved the file in the source file system (known as $SRCROOT), there's no change to the way the file is used in the product. If it got copied into Contents/Resources/ before you moved the file, that's where it gets copied to afterwards. No subfolder will be added at the destination.