Generally designers design static cshtml files after slicing PSDs before developers can use them to create dynamic pages. How these static html files should be structured in an application, such that:
They have their repository versions
Can share common JQuery/CSS/Images in solution used by other actual coded pages
Doesn't goes to production upon deployments
One good approach is:
Project
|_Area
|_Design
|_Controllers
|_ ModuleA Controller (Has 1 controller with viewname argument and renders it)
|_ ModuleB Controller (Has 1 controller with viewname argument and renders it)
|_Views
|_ModuleA
|_StaticScreen1.cshtml
|_StaticScreen2.cshtml
|_StaticScreen3.cshtml
|_ModuleB
|_StaticScreenA.cshtml
This approach works good for 1st 2 points and is easy for designer too as they just need to keep adding screens in respective view folder. On a downside, this gets deployed to production too. Please suggest a better approach.
Click on each file you don't want and look at the Properties.
Change 'Build Action' to 'None'
When you Publish, the items with Build Action:None will not be included.
Related
Microsoft provides a fantastic template for developing Angular (not AngularJS) in ASP.NET Core as outlined in their article "Building Single Page Applications on ASP.NET Core with JavaScriptServices".
While it's very straightforward, there is one portion of the template that caught me off guard: instead of there simply being an app.module.ts file, there are both an app.module.client.ts and an app.module.server.ts.
I failed to find anything that explains this on the web. Does anyone have any idea why there are these two separate files for the app module, what their specific uses are, how to use them, etc.?
If it helps at all, here is what the full template looks like:
I should note that ClientApp/app/models and ClientApp/app/services are two folders I added for my own purposes; they are not part of the template. Also, app.module.shared.ts is actually very straight-forward and just prevents having to write some code twice, so don't worry about it.
Here is what the two files look like:
Let me start by prefacing that I'm not 100% on the accuracy of this statement, but since nobody else seems to have answered, I'll give it a shot.
Microsoft SPA with Angular 2 utilized Angular Universal to do the AOT rendering. It has now been upgraded to use Angular 4, which doesn't use Angular Universal. My thought is that it instead broke up the app.module.ts into a client and server file to help with AOT rendering.
The app.module.shared.ts file is actually just a global constant that is used by app.module.client.ts and app.module.server.ts. Because it all gets rendered into a couple js files during publication, it doesn't really matter that they split up the app.module file.
I have a JSF 1.2 based Java web-application that is packaged as an EAR. It contains several JARs and one WAR that provides a web-UI as frontend. The WAR contains JSF pages (XHTML), CSS files and other web-resources like images. The build-system in use is maven 2 (multi-module project).
The goal is now to provide different "flavours" of the web-UI. Every flavour could have different style-sheets and different images but same functionality.
The question is, how could I do this without much code duplication/overhead. I guess I have to create several WAR modules (one for every flavour) and several EARs that depend on the different WARs. Disadvantage of this is that two more modules with all it's configuration have to be added for every flavour. All the JSF pages would have to be duplicated, which is really not nice (ok, providing the XHTMLs via a separate archive and using Maven's remote resources plugin to share remote resources could possibly help here).
Is the described setup the best solution to my problem or are there better ways?
Is there a way to change the style at runtime? I.e. provide the CSS-files and images as external resources?
Thanks in advance,
- martin
First of all, all your css should be externalized into file.
Have different set of css pages for each theme. Lets say you have 2 pages in your app, home page and search page, and you want to have 2 themes red and blue, then you should have homeRed.css,searchRed.css and homeBlue.css and searchBlue.css.
Now about switching your themes at runtime, in dynamic web pages like JSPs, you can generate webpage depending on paramater value. Let's say colorStyle is your param name, then you can have JSP like
<% if(colorStyle.equals("RED")){ %>
<link rel="stylesheet" href="path/to/homeRed.css">
<% } else { %>
<link rel="stylesheet" href="path/to/homeBlue.css">
<% } %>
You can read value of colorStyle from user or hardcode it in your app depending on your requirement.
Please note that above mentioned is very crude way of doing things in JSP which is not recommended these days, but as you are using JSF there must be provision for doing this in sophisticated manner.
*EDIT Update *
In that case, what you want to do is doable by only 2 ways. Either maven configuration of source files or stanalone utility program to copy wanted files into folder of which you will create war. For maven configuration approach, you can select which set of files to include or exclude. for ref What's the "right" way to (temporarily) exclude sources from a maven build, and is there an easy way to do it from Eclipse?
I'm starting to develop an application using ASP.NET MVC 4 framework with Razor syntax. I want to know where (folder location) I should create my HTML Helper class. Best practice.
For example:
VisualStudioSolution
Controlles
Html
HtmlHelperClass.vb
Models
Views
use this.To use the "#helper" feature in Razor you need to place the CSHTML file in the App_Code folder of your app. There is no "Views/Helpers" folder in ASP.NET MVC 3. ScottGu's blog post was written before the feature was fully implemented, and some of the notes there are not entirely accurate anymore.
To call the "#helper" that you wrote you have to include both the filename as well as the name of the helper inside it. For example, if you have this helper:
~/App_Code/MyHelper.cshtml
And this content:
#helper ShowStuff(string stuff) {
<p>#stuff</p>
}
Then you call it like so:
#MyHelper.ShowStuff("some stuff!")
You have a good structure.
I would change the Html folder with a utility folder.
You can add all kinda helpers there.
Controllers
Models
Views
Utility
Framework (this may be usefull for the bootstrapping of your app)
And there actually no fix "best practice". Just make sure you can find your classes in the obvious places. If not remodel.
I am starting a new project using Symfony2. I am adding some basic twig templates like my CSS template (with assetic to trigger sass -- nifty) and my header/footer template. My question is, should this sort of thing go into app/Resources or into Acme/MainBundle/Resources?
I am sure I can do either if I really wanted to, but I'd like to know what the correct way to do it is.
app
Resources
<A. here?>
src
Acme
MainBundle
Resources
<or B. here?>
It's really a matter of preference. I tend to keep global views in app/Resources. Does your MainBundle contain anything else besides views? If not, I think that's more reason to use app/Resources and avoid unnecessary bundle pollution.
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.