I am doing a small audit of a fairly robust ASP app and CMS for a client (does a good bit more than a regular CMS) and started looking into the code. (edit: This is for a quick overview prior to engaging a full fledge ASP shop.)
I am coming from a background mainly in PHP, Node.js, and Ruby but when I look at the layout of the directories and files it looks horrible. It reminds me of old PHP 4 apps with files all over the place.
My question is, is this still good coding practice in ASP? I expected to find a much cleaner/easier to understand structure with a more custom app like this. Much like the Rails/Zend/etc of the other languages. Here is a screenshot of a few of the files from the webroot.
A side question would be, are there better ways to organize files in ASP? I have not coded with ASP in 6-8 years, and it was still not very much I used it for.
This isn't ASP, it's ASP.NET; I also note it's WebForms, not MVC, which has very different layout.
Anyway, the directory structure is a mess, it's horrible. Here's what's wrong with it:
Unholy mishmash between static HTML files and ASP.NET webforms files
Code files (e.g. contact.aspx.cs) are present on the server when the application looks to be compiled (because it has a bin directory), so they shouldn't be there at all.
There is no consistency in folder and filename casing. Some are all lowercase, others are TitleCase.
You appear to have duplicate folders, what is the difference between "Images" and "img"?
What on earth is "missing" and "layouts" for?
Duplicate, disorganised files index.html, index1.html, etc.
Then there are a few other concerns, but those are down to developer preference:
Generally, projects only have one or two MasterPage files, so it doesn't make sense for them to be outside of the root folder. I put my *.master files directly in the root of the application.
Images related to a stylesheet should be placed in the same directory as the stylesheet rather than in a sibling folder (I'm assuming the images referenced by the stylesheet in the "css" folder are actually located in "img"). This is bad because it complicates the CSS file (as it has relative paths inside it) and makes your application more brittle.
Fonts seems to contain font files, again, referenced by your stylesheets. They should all go under a single "styles" folder.
Any image "content" (i.e. <img src="" /> elements), not images used in stylesheets, should be kept separate from stylesheet images, I'm assuming this why you have the confusing "img" vs "Images" folders.
As for the correct way to do it, ASP.NET WebForms does not lead itself to tidy, well-organised applications. Because each (non-rewritten) URI corresponds directly to an *.aspx file it means the filesystem layout has to match the website layout. I'm afraid there isn't much you can do about it unless you implement ASP.NET Routing.
I also suggest eliminating all of your HTML files and converting them into ASPX files that make full use of UserControls and MasterPages as appropriate.
Related
I'm Building a website, and It has a lot of pages approximately like 30 pages, and I linked these pages with one CSS file (the main css files) not to mention the other files such as bootstrap.min.css and other plugins that requires their own css files.
My point is that in all of these I'm using like the same css files, but in some pages I don't need all of the properties and styles in main.css file, so I'm thinking that I split that css file into multiple files, and create file called (global.css) and type in the properties that I'll need in all pages, and make another css file for each individual page.
My question is:-
Is it going to be helpful for the website speed if I split that main css into multiple css files and include only the necessary things for each page?
Ideally you want to abstracts your CSS files into many different SCSS files and then compiles them into one minified master file. One file for the header styling, one for links, one for typography. I was afraid of SCSS but now love it... Nothing changes in production, you are still running off CSS bit in development you are just making your life that little bit more organised.
NO,
you better dont want to do that if your code is small like less that 50kb or even 100kb
also if you provide seperate css for each page browser has to download each css file when user visit that page that will cost you one additional request for every single page this will slow down your page and affect your performace
instead I would suggest when your code goes live compress your code or minified it so youll get the more smaller version of your code
I also suggest to leverage browser caching (using .htaccess if you are using linux server)
above are the things which comes under front end performance improvement
When I creare stylesheets for my ASP.NET MVC 4 web site everything works great when in debug/development mode.
As soon as I deploy the web site on IIS, in release config, some parts of the css are not being applied to the elements since they are not present at all in a single minified .css file that is being added to the page.
Making my declaration more specific - e.g. including id > class or stuff like that ususally solves the problem, but what are the general rules for writing css styles so that they are served to the client and are not filtered out by ASP.NET minification?
If you're talking about ASP.NET bundling, it will bundle the CSS files in alphabetic order by default. One simple way to make sure the files are always rendered in the correct order is to use a prefix on the filename, e.g.:
01.first-file.css
02.second-file.css
03.third-file.css
04.fourth-file.css
Having said that, making your declarations more specific and therefore less dependent on the ordering of files is probably a good idea.
After a little research it turns out that themable custom css in sharepoint should be placed either in the styles library or in the layouts folder but always in a language dependant folder structure like /<LCID>/Styles/Themable
I would like to replace the target folder of the css files in the package with the primary language of the server where the solution is deployed.
For Example, I want to change
<TemplateFile Location="Layouts\1031\Styles\mygrid.css" /> to
<TemplateFile Location="Layouts\1033\Styles\mygrid.css" /> when the solution is deployed.
A solution to this problem would also help for other files which have to be put in the Layouts\LCID directory such as theme xmls themselves.
Thanks for your help!
I understand you have only one version of css file (language independent) and you need to put it into the right folder during deployment.
The solution can be to get rid of the language specific folder schema and put your css file into Layouts\YourProject folder and then register the css file via CssRegistration control on your master page, web part or control.
See also my related question.
I am building up a website using MVC architecture. It takes a lot of css with it. I require atleast 20 css files to store within it each associated with some unique views. I want to know where can I store the css files? Either in a single root css directory or shall I store it with a particular view. Also linking these files within the common template file would be tedious enough. I mean it would show up 20 different tags. Is there any alternative way to do this? Please help. I am using codeigniter framework by the way.
What I do is store it all in a css folder inside the public folder (the one that houses your index.php file). I also have a helper method that generates the actual link tags, so in the template files, I just have something like:
<?= stylesheet('sheet1','sheet2','sheet3') ?>
The helper method that calls would then make the links (and assumes that they're in the public/css directory).
That cleans up the raw template files, though it does still make multiple tags in the files themselves. I use partial views, so there's a master view that has the main CSS file(s) that are used on every page (or almost every page), then add in on each template the ones that are unique to the view.
If you have 20 CSS files, you might want to go through and see what you can tidy up and make more generic. Any place where you have more than one of the same styles (even across files) is up for the chopping block. Any extra files should be relatively small and provide only overrides for the exception pages (and if you can genericize those more, so you use a file for more than one page, then that's even better).
I would recommend you to combine all the CSS files in a single file. Its easier to maintain and you will have only one request to the server. Having so many css files will only increase the loading time of your page. Also gzip the css files to increase the page speed.
My work has recently deployed Sharepoint and I'm currently trying to get to grips with it.
I'd like to be able to completely customise the way my blog looks but I have no idea where to start. I had a look through Microsoft's developer site and it does look like they have a lot of stuff there but it all seems to be pitched at a much higher level than I'm at.
I'd consider myself pretty experienced with CSS and web development, does any of this translate into sharepoint? Can I make a new CSS file and upload a bunch of images into a store and change the look of my 'site' that way, or is it a lot more complicated?
I realise this is a little vague, but I'd really appreciate some pointers to a "getting started with making sharepoint not look sucky" guide or an example of the sort of thing I can actually hope to achieve. Hopefully my question isn't too high-level.
Thanks
Use SharePoint Themes, their installation is tricky at first but once you get a good development environment you'll be able to test modifications in the traditional "save css file, press F5".
Themes have these pros:
Do not need sharepoint designer
Do not need to change masterpages and deal with (un)ghosting (the sum of all fears)
Can be applied to one subsite and have other subsites with different themes (see gl-applytheme in google for mass application of themes thru many subsites)
and these cons:
You have no access to HTML changes, for that you need masterpage love (I dont think thats a con, its a limitation that usually exists in different scenarios and also makes you improve your css skills so much in the css-zen-garden way)
Themes once applied, go to the server memory -- meaning that if you change your theme folder you need to recycle the application pool, apply a different theme and apply your theme back to see that one pixel border you forgot to put in the footer. But for that specific problem I have a solution below:
After you do your "theme setup" you'll be able to only work with CSS and images and be free to overwrite any class in SharePoint using your favorite Developer Toolbar/Firebug addon to find what you want to change.
In the folder c:\Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE\THEMES create a folder named THEMEDEV
Inside the new folder, create a file called theme.css and another called THEMEDEV.INF
Inside the .INF file, paste this:
[info]
title=THEMEDEV
codepage=65001
version=3.00
format=3.00
readonly=true
refcount=0
[titles]
1033=THEMEDEV
now open the c:\Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE\LAYOUTS\1033 folder (1033 is your language code, thats the default for english installations)
edit the SPTHEMES.XML file
below <SPThemes ...> insert:
<Templates>
<TemplateID>THEMEDEV</TemplateID>
<DisplayName>Development Theme</DisplayName>
<Description>Development Theme.</Description>
<Thumbnail>images/thnone.gif</Thumbnail>
<Preview>images/thnone.gif</Preview>
</Templates>
now edit your theme.css file, add an import to your favorite CSS development folder:
#import url('file:///C:/SharepointThemes/Theme1/theme.css');
Save everything, open your sharepoint: Site Actions => Site Settings => Look and Feel => Site theme => choose your Development Theme and hit Apply
If everything worked, you can now edit your C:\SharepointThemes\Theme1\theme.css in your favorite editor, save it with something like
* { color: red !important }
and see the changes on your site.
Something also important when developing themes: do not create folders to store, say, your images, use everything in the same folder and in the code itself use a relative fashion, like background: url('image.png')
ps1: Only you can see changes you are making to your sharepoint site due to the file://c:/ folder, if you need more people to see the changes during development, setup a network path that they all have access, the rest is the same.
ps2: Keep in mind this is a development environment, to make your theme a live theme you need to create another one to store all the content used to change your site's visuals.
The process is similar to the one creating the THEMEDEV one, just put a pretty and consistent name across all configurations (Folder name, .INF name, .INF contents, SPThemes.xml node contents), paste all your images in the Theme's folder and replace the theme.css file with your content.
Edit1: Reading your comment above, now you have a "editing + uploading to FTP" type of setup :) this works for MOSS and WSS by the way (even if you don't know the difference). For more info on customizing sharepoint, I made a post yesterday about more options:
Sharepoint: How to remove default core.css reference?
I like to always use this post as a starting point for SP branding: http://erikswenson.blogspot.com/2008/10/functional-sharepoint-branding-style.html
It depends on whether you're talking about a WSS 3.0 site or a MOSS site. WSS 3.0 sites can be customized using themes. Customizing MOSS sites is a little trickier, although you can add a SINGLE custom CSS style sheet via Central Admin - in this case, your custom files, images, etc., would be deployed as a Feature.
The best explanation of how this works that I have come across is the six part series on the cleverworkarounds.com site.