Is it bad to have long names on _Partialviews?
Like _Header_detachable_nav, and that partial is gone have other partials _Header_detachable_nav_cart,
_Header_detachable_nav_navigation
is this bad practice, does it matter at all?
The underscore in the partial view helps to differentiate between full views and partial ones.
But more importantly, it prevents partial views from being loaded directly by their URL, which could provide some potentially ugly results! (Like no css, for starters.)
However It's not necessary to use an underscore.
And instead of having names like _Header_detachable_nav_cart instead you can use camelCase like for example _HeaderDetachableNavCart
Related
I want to make the editor experience better and more visually pleasing when filling in content on a page (In all properties view). Could be a simple divider or a heading..
I am already using tabs, whenever it makes sense. Also, I have been experimenting with using blocks as properties. This adds a nice separation with at clear heading, but it is so much more code to maintain and a bit of a mess to be honest when the properties truly belong to the page type.
Out-of-the-box, it is not possible to decorate properties with headlines, unless you use block-properties, as you mention yourself.
However, I thought your question was quite interesting, and I discovered that extending Episerver to accommodate this behavior is surprisingly easy. I have written an example solution, which you're free to use as you like: https://arlc.dk/grouping-properties-with-headlines-without-property-blocks.
If you dislike the solution, an alternative approach would be to introduce your own Property-type (Headline), and create a 1) a custom dojo-widget to simply display a headline, and 2) an EditorDescriptor to set the ClientEditingClass.
Linus wrote an excellent blog post on this here: https://world.episerver.com/blogs/Linus-Ekstrom/Dates/2012/7/Creating-a-custom-editor-for-a-property/.
EDIT:
I see, I have skipped too quickly over the overriding part.
You don't have to override any files by replacing them, and you won't have to extract Shell.zip (unless you're curious how Episerver has implemented their widgets). The part that overrides the specific component is define("epi/shell/form/Field". As long as your definition of this widget is loaded after shell, dojo will use your implementation, whenever something is requiring "epi/shell/form/Field". The thing that ensures your implementation is loaded after, is in module.config, under 'This injects our field-implementation [...]'.
The path ~/ClientResources/Scripts/Shell/Field/Field.js is simply the location I have chosen to put the overriden version of Field.js. You can put it wherever you like, as long as you update module.config accordingly, with the new path.
It works like this: First, Episerver defines widget A. Then you define a widget with the same name, A. When anything tries to fetch A, it returns your implementation, rather than Episerver's.
The question is in the title. It seems logical to use this tag helper for every image but if I am indeed supposed to why wasn't this the default?
Is there any performance hit with this? Are there cases when I shouldn't be decorating an image with this tag helper?
The main use of asp-append-version=true is to bypass the browser cache if the content item has changed. It is very useful for javascript that is likely to change.
Images don't get updated very often unless you have an unusual use case. If you have a use case where images do get updated and they keep the same file name then it would make sense to use it there but otherwise it would not.
I can't say how much performance hit would be involved, but it does create a hash of the file content to use for the version string that is appended. There is some impact for any extra code that is executed when it is not needed. It does not make sense for it to be a default behavior, it should be used by opting in to it if you really need it.
I will potentially have many Partial Views for my application which can be grouped in a folder structure. It seems I ought to do this otherwise I will a View Folder with loads of files. So I assume I should have something like:
Views ->
Group1 ->
PartialView1
PartialView2
What would the HTML.Partial call look like?
HTML.Partial("~/Views/Group1/MyPartialView.cshtml",Model)
Another idea I had was to have the one Partial View file with conditionals Code blocks, but I suspect this goes against everything that PartialViews are about.
Finally is there any difference in performance if one has many small Partial Views versus one large Partial View with multiple conditional components? I guess I am thinking that one file load into memory and compilation to code as opposed to multiple small file loads.
Thanks.
EDIT: More Info.
I have a generic controller that I am using to render different parts of a report, so all sections for an "introduction" chapter would be rendered using "Introduction" partials ie "Introduction.Section1", "Introduction.Section2". In my scenario I do not believe I have common sections across chapters, so I could go with the "file." idea, but the Views folder would be large, hence why I am considering the use of subfolders.
EDIT: Thanks all. Some tremendous ideas here. I went with the folder idea in the end since I use this approach elsewhere. However I do realise I need to use absolute pathing, but this is not an issue.
As long as they're in the Views directory somewhere, it shouldn't really matter. If you put it in a location other than Views/{controller} or Views/Shared, then you'll need the fully qualified location, including Views and the extension, so #Html.Partial("~/Views/Group1/PartialView1.cshtml").
Personally, if you have a lot of partials that are used in a single controller, I'd leave them in the {controller-name} directory (with a leading underscore as #IyaTaisho suggested). But if they're used by in multiple controllers, and you need to group them, I'd group them under Views/Shared/{groupName}.
Regarding one big vs. many small partials, I'd say go with many small ones. There might be a reason to do one big one now and then, but in general, I believe a partial should be as simple as possible. Remember you can always have nested partials, so if you have shared functionality or layout among many partials, you can break it into a parent partial and many child partials underneath.
You could use a parent child file naming convention like:
header.html
header.login.html
header.searchbar.html
You could even take it a step further:
contact.helpdesk.html
contact.office.html
Re-using partials is much less frequent than unique partials, so you could use a convention for re-usable partials like:
global.partial1.html
global.partial2.html
Limitations are a large file directory.
Benifits are easy to skim, easy to sort.
I usually add an _ in front of a partial. Example would be have a main View called Home.cshtml. The pieces (partials) on the page would have something like this: _header.cshtml, _footer.cshtml, etc.
I'm working on a project using CodeIgniter. Surely, it's very useful to have an helper like language as the string you're going to print can change depending on the language you loaded. So, instead of writing pure php code, you can use the helper.
However, it's not clear to me which is the sense of helper function like:
echo doctype();
that expands to:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
Of course, the first one it's easier to write, but that code has to be processed every time. You save few seconds of coding at the cost of infinite executions of the same code that has always the same output on each page (and there are many helper like that one, for example the Form Helper is plenty of valid examples where the functions produce static HTML code).
So, the question is: why should I use an helper if I don't have any dynamic code/variable to add?
For some things it might not make sense. Possible excuse for doctype() would be if you wanted to change your doctype for several pages, you could do it by changing the output of the function. Personally I use a single master template with the doctype, but different people will do things differently.
Same excuse applies to something like heading('My Title', 1), some day you might need to change the output from <h1>My Title</h1> to <h1><span>My Title</span></h1>, and if you had used the heading function throughout your application, it would be trivial. You could even add extra parameters to make it more flexible.
Of course as you surely know, do whatever works best for you for the given situation. Sometimes HTML helpers can save you time, other times they will just get in the way. I wouldn't worry too much about how long it takes to execute, because it is hardly significant.
Am wondering if the combination of trim(), strip_tags() and addslashes() is enough to filter values of variables from $_GET and $_POST
That depends what kind of validation you are wanting to perform.
Here are some basic examples:
If the data is going to be used in MySQL queries make sure to use mysql_real_escape_query() on the data instead of addslashes().
If it contains file paths be sure to remove the "../" parts and block access to sensitive filename.
If you are going to display the data on a web page, make sure to use htmlspecialchars() on it.
But the most important validation is only accepting the values you are expecting, in other words: only allow numeric values when you are expecting numbers, etc.
Short answer: no.
Long answer: it depends.
Basically you can't say that a certain amount of filtering is or isn't sufficient without considering what you want to do with it. For example, the above will allow through "javascript:dostuff();", which might be OK or it might not if you happen to use one of those GET or POST values in the href attribute of a link.
Likewise you might have a rich text area where users can edit so stripping tags out of that doesn't exactly make sense.
I guess what I'm trying to say is that there is simple set of steps to sanitizing your data such that you can cross it off and say "done". You always have to consider what that data is doing.
It highly depends where you are going to use it for.
If you are going to display things as HTML, make absolutely sure you are properly specifying the encoding (e.g.: UTF-8). As long as you strip all tags, you should be fine.
For use in SQL queries, addslashes is not enough! If you use the mysqli library for example, you want to look at mysql::real_escape_string. For other DB libraries, use the designated escape function!
If you are going to use the string in javascript, addslashes will not be enough.
If you are paranoid about browser bugs, check out the OWASP Reform library
If you use the data in another context than HTML, other escaping techniques apply.