Is it possible to create a default theme for an ASP.NET Website?
For example, If I had a theme called "Default", and ive selected a theme called "NewTheme" and I referenced a file which doesn't exist in the "NewTheme" but does exist in the "Default" theme like:
<asp:image id="img" runat="server" ImageUrl="~/Images/image.jpg" />
Could that then be taken from "/App_Themes/Default/Images/image.jpg" if it does not exist at "/App_Themes/NewTheme/Images/image.jpg"?
Furthermore if a CSS class didn't exist in "NewTheme", but it did in "Default", then could it take the "Default"? In fact, I think it would be better if it first took all the default styles, and then overrides any that "NewTheme" have which clashes.
I know Global References work similar to this because if ive selected "es" localization, and a key doesn't exist in the webreference.resx.es file but it does in webreference.resx, then itll take the value from there.
I think this would be important functionality for ASP.NET Themes as I can imagine different themes only having certain images changed, and certain styles changed. I can't imagine every image and every style always being totally different for each Theme. And therefore without this functionality, its going to be a case of duplicating styles/images, which I'm not a fan of (for obvious reasons!).
Default themes as you describe aren't supported by ASP.NET. There are regular Themes and StyleSheetThemes, but changing them dynamically is more useful at the Page request level than for individual Controls or static files.
You can code up your own version of themes for static files using URL rewriting or routing -- but then it's not really Themes any more.
For controls like <asp:Image>, you could override them and modify properties such as ImageUrl based on which files exist in some hierarchy of "theme" folders. Then use tag mapping to replace all instances of that control with the new one, without requiring any markup changes.
FWIW, the BeginRequest event in Global.asax is only invoked for dynamic files in IIS (Cassini calls it for statics, too). To support statics in IIS, you'll need an HttpModule, and you'll also need to configure IIS to run in Integrated mode.
This functionality isn't built into ASP.NET. Nevertheless, you could implement it fairly easily:
Hook the HttpApplication.BeginRequest event in Global.asax or in a custom HTTP module.
Look for requests with URLs under "/App_Themes/NewTheme/".
Check whether the file at HttpRequest.PhysicalPath exists.
If the file doesn't exist, call HttpContext.RewritePath and replace "NewTheme" in the request URL with "Default".
Related
I would like to make a custom dark theme for a web client.
I tried everything but no matter what I changed I cannot get any changes to take effect. I found out this page in the documentation but I cannot get it to work:
https://afterlogic.com/docs/webmail-lite-8/developers-guide/creating-new-skin
Does anyone have some experience with this webmail client?
The recommended option for creating a new skin is to clone and rename one of the existing skins, and upon making changes to it, run gulp styles --themes YOUR_THEME_NAME command. Once this operation is performed, check static/styles/themes/YOUR_THEME_NAME and see if you get your changes reflected there. If the changes are in place, then it's probably browser cache causing it, try clearing it and see if that helps.
In fact, it's not required to deal with .less files, you can simply create a copy of an existing theme under static/styles/themes directory - but in either case, you need to make sure the new theme is listed in ThemeList section of data/settings/modules/CoreWebclient.config.json configuration file.
I am using Magnolia CMS 5.3.4, the STK, and freemarker (FTL) template scripts.
Some components I have defined relies on specific javascript files. Right now, what I do is that I include these javascript files in the main.ftl template script. I am looking for a way to get them included only if the specific component is present on the page.
I tried to use the jsFiles property in Template Definitions, but it seems it works only for page template definition.
The jsFiles property indeed works only for pages not for components. This is because Magnolia wants to include those files in header already, rather than loading them in middle of the body when component gets rendered.
As a general practice I would anyway recommend combining your js files into one (look at for example plugin loader in resources on how this is done) and set longer time for caching such file so that browser downloads all the script just once for the whole site rather then page by page. The bigger js file you are sending over the more overhead you are cutting off from requesting separate files and better the compression of content for transport will work.
HTH,
Jan
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.
I'm using jQuery plugins in an ASP.Net MVC site.
I've often to include CSS and JS files as required by the plugins I use in every page. So I want to centralize all those dependencies in a single place in my app. thus if a dependency for a given plug-in is changed or updated, I'll only have to modify a single place in my app.
I've thought in two possible solutions:
Extend the HTMLHelper with a partial method
like GetPlugin("jqgrid"); that
will print out all the script and
style tags needed.
Create a partial view for each
pluginlike jqGridDependencies.ascx
that will contain the script and
style tags needed.
Do you have any other idea? what do you think of both proposals?
Could http://combres.codeplex.com/ provide you with a framework for this.
My only personal objection to this method is that each individual pages will have a unique JavaScript/CSS file where as if you combined and compressed everything into one and simply used classes and events to trigger the JavaScript enhancements as and when needed your site would run a lot faster.
My project has multiple themes with different colors.
I need to skin certain textboxes with a specific font/size/etc.[no color difference]
Currently, I add <asp:TextBox SkinID="skinned" runat="server".../> to all .skin files under each theme.
Is there a way to put this textbox skin in one place, like a master skin?
The lack of inheritance or cascading in the ASP.NET Themes implementation is an unfortunate limitation that doesn't receive a lot of attention. In scenarios where you wish to have a global skin available to all themes (without changing the control definition itself), you have two options:
Option #1: Use a VirtualPathProvider
(The downside of this is that you can't use it on precompiled websites without a reflection-based workaround.)
You can define a Global.skin file under a special Global theme where shared skins are kept; you will also create a placeholder Global.skin file under all other themes as well:
App_Themes
- Global
\Global.skin (primary)
- ThemeA
\Global.skin (empty placeholder)
- ThemeB
\Global.skin (empty placeholder)
In the VirtualPathProvider you would then re-route all requests for App_Themes\*\Global.skin to App_Themes\Global\Global.skin.
Option #2: Use a Post-Build Task
This is an amendment to the above solution that avoids the precompiled websites limitation; instead of doing the re-route at runtime, you can apply it post-build via an ms-build task that simply propagates Global\Global.skin to all other theme folders.
I've used both options successfully.
You will need to list it under each theme, but you only need to list one control definition per theme. If you want a skin to be the default behavior for a control, specify the definition without a SkinID property.