I have a habit of taking things to the extreme...
I also like the idea of wrapping structural sections of the site in custom semantic wrappers.
So when I started building web_ui components I ended up with something like this in my main entry page:
<x-container_fluid>
<x-header_fluid>
<x-site_header>
</x-site_header>
</x-header_fluid>
<x-old_browser>
</x-old_browser>
<x-home>
</x-home>
<x-footer_fluid>
<x-site_footer>
</x-site_footer>
</x-footer_fluid>
</x-container_fluid>
This works like a charm with the one exception being that on each page load the time lapse between 'Page Load' and 'Content Load' causes the browser to flash white until the controls render.
I 'think' my only option is to back off the dime a bit and move the structural bits back into the root page and instead add 'loading...' type placeholders anywhere there is a control that requires render/init cycles.
I'm wondering if there is any way (opt in?) to get the components to compile their templates into the hosting page at build time?
Any and all suggestions welcome!!
I'm wondering if there is any way (opt in?) to get the components to compile their templates into the hosting page at build time?
Not sure if this is going to give you exactly what you need but it is a very interesting lazy-loading technique that just may help:
http://googlecode.blogspot.co.uk/2009/09/gmail-for-mobile-html5-series-reducing.html
http://jsperf.com/stripoutcommentblock
Tom
Related
At the following link there is a cheatsheet for Adobe Experience Manager (AEM formerly CQ).
http://activecq.com/system/assets/46/original/quick-reference.html
There is a section on the page called "Component Organization"
At the bottom of the list are two sections: views and partials.
My first question is, what would the x and y represent and is there some built in mechanism that already exploits this convention?
If a page included content where this component was the resourceType and the appropriate selectors were in play then those x and y JSPs would also be in play. For instance,
/content/mysite/mypage.views.x.html
But that seems strange. A more likely scenario is that the component is targeted through a sling include that adds or replaces selectors.
<sling:include resourceType="/apps/myapp/components/sample"
replaceSelectors="views.x" />
So what is the intended usage of this feature?
I could be wrong, but I believe the partials folder is referring to this: https://github.com/Adobe-Consulting-Services/acs-aem-commons/issues/10
The idea seems to be to break up the component into inheritable sections for ease of use and development of siblings of the parent.
Is there a way to get a trace of what cshtml files are being used to construct a particular page load? For instance:
/Views/Shared/_LayoutUser.cshtml
/Views/Shared/_UserNavigation.cshtml
/Views/Shared/_BannerSelector.cshtml
RenderBody - /Views/Users/Index.cshtml
/Views/Users/DisplayTemplate/User.cshtml
Anything else used to construct view
/Views/Shared/_UserFooter.cshtml
Try Glimpse. It works much like Firebug does, except for MVC. It shows the execution tree of your views/partials/layout in a tree that looks pretty much the same as you described, including their execution times. It's very extensible as well, and there are plugins to trace Entity Framework, and JavaScript, etc.
Intro:
I'm trying out LESS in an asp.net mvc environment.
I use dotless for server side processing (and I wouldn't want to use client side processing especially afer publishing the complete project).
I have to apply a design where there are different color schemes depending on different things (e.g. time of the day).
Less felt very powerful in this case as designing a parameterized css and only changing like 10 variables at the beginning of the file for every theme was really uplifting.
Problem:
But I would need to somehow change the color themes from an outside parameter.
Ideas:
First I thought that an URL parameter like style.less?theme=fuschia would be good, but I found no way to parse something like this.
Then I thought that making a very short blue.less, green.less, orange.less consisting only declared color variables, and including the main.less in every one of them would be a solid solution.
I had no chance to try out the second solution, but I thought this would be a good time to ask for advice on the most robust way of doing this.
The problem again is: I want to control some things in my less file from the outside.
Yes you can (because I implemented that feature for exactly that reason).
Dotless supports parameters from the outside via the querystring parameter.
<link rel="stylesheet" href="style.less?foo=bar" />
Will let you use the following less:
#foo = bar;
The parameter injection code is very simple. it just prepends the variable declarations to your normal less file, so anything that comes as a querystring parameter will follow the above syntax.
The code in question is very simple: https://github.com/dotless/dotless/blob/master/src/dotless.Core/Engine/ParameterDecorator.cs
AFAIK, you cannot pass parameters for dotnetless to use to do the compile.
As a suggestion, why not just call different less files? This would be fairly easy to do by using a Viewbag property.
To make the different less ones, You first create a less file with each set of colors in them. Then you import your base css file. dotnetless will merge the color definations in the parent file with the usages in the base file. So you have something like -
#baseGray: #ddd;
#baseGrayDark: darken(#baseGray, 15%);
#baseGrayLight: lighten(#baseGray, 10%);
#import "baseCss.less";
I just tested this on and MVC3 project and it works.
anybody knows which ones works faster ?
The Embedded Resources of the Input Builders are servered through the WebFormView engine. When your application is set to debug=false in your webconfig the view engine caches the view, so it is only loaded from the assembly once. The real reason why the input builders would be a little bit slower is that they use a master page to reduce the HTML you maintain. The Editor Templates will produce an input for example. The equvilent Input Builder will produce a label, input, and the html 'chrome" around the two so that you can specify it once and have it applied to every form that uses the input builder. The input builders are really for applying a convention for how your forms markup is built and it does it in a way that gives you control but also keeps your html fragments "DRY" (dont repeat yourself).
Like everything there are tradeoffs. For the input builders, you trade off some runtime performance for developer productivity. At the end of the day if you needed to have a super performant form on a public website, your best option would be to server a static html file that posts to an MVC Action.
Your answer depends on where you load your views pages from.
Templated Helpers have a slight edge because without any view overrides they are manipulating strings behind the scenes to produce html output.
Input Builders load views through embedded resources or through the traditional file system which will always be slightly slower than hardcoded string manipulation.
The code for both is similar and do basically do the same amount of reflection and metadata processing. Without any file or resource loading complications they both run at < 1 ms.
With customized template sourcing via embedded resources or file system calls your performance loss will be the same for both.
Recently I created a spike of a view engine, in which views are plain classes, and the content is created by using funny using-scope blocks.
The code together with a simple sample site is available at http://code.google.com/p/sharp-view-engine/
Here I'd like to hear your opinions regarding such an idea. Is it completely weird or maybe someone likes it?
I would actually not like that.
I can agree with DSLs (such as a Parser-Combinator or for generating XML Nodes in a data-context), but in this case I think that too much is being put in code that. And, in the end, this just complicates boundaries and leads to hard-to-maintain code. (You can already do the same, but with more verbosity just using the "standard" Web Controls. You can always use {subblock} in C# to limit a variables scope.)
The approach I prefer to use is templates with bindings (but no "code in templates"). That makes it easy for the "designer" (hopefully not me, or the next person to come along and) edit the layout of the view how they see fit. However, the core logic (the available controls and bindings) are kept in the code -- uncluttered. (Another advantage with the templates is that if they externally housed they do not require a recompile for every little change.)
Simplicity and maintainability are like ... zen.
This is an interesting idea taken to the extreme I'd say. At my shop we're using html conventions for pretty much everything except our layout. The only real html we have in the project is our Spark master page. For generating the content itself we use a convention engine that that spits out a semantic html model. (We're using the HtmlTags library from FubuMVC to build the semantic model.)
An example convention for rendering a multiline text box looks like:
public static HtmlTag Build(ElementRequest req)
{
return Tags.TextArea
.Rows(6)
.Id(req.ElementId)
.Attr("name", req.ElementId)
.Text(req.StringValue());
}
These conventions get triggered from reflecting on the view model (or we can manually call them from a helper method). The output is rendered (via ToString()) into the content section of our master page. We're joking that pretty soon we won't even need a view engine.
ps here's how we handle nesting. (Your using blocks look cluttered!)
return Tags.Div.Nest(
Tags.Button("save").AddClass("positive"),
Tags.Span.Text(" or "),
Tags.Anchor.Text("cancel").AddClass("negative")
);
Nest() is an extension method that simply takes a params array of HtmlTag and appends them to the parent's children collection.