Jan
16
Posted by:
Steve Fabian
1/16/2012
The Gooddogs DotNetNuke Technology Template includes the Blueprint CSS Framework, and this blog post/video will show you how to use the framework to control the formatting of your module’s output.
NOTICE: This is a work in progress. The template is not complete, during the course of this series we will be enhancing and tweaking the template as we build a new DotNetNuke module using these advanced technologies. The template is being released as-is so that you can download it and follow along, or participate by helping with the development. You can certainly use the template in it’s current state to build a DotNetNuke module, however, you will have to do some things manually for now until the template is complete. If you have any question at all, do not hesitate to contact me directly
The “Let’s Build a Module” series
1. Project Introduction
2. Downloading, Installing and Using the Template
3. Output Formatting
The Blueprint CSS Framework is a ‘grid-based’ css stylesheet that you can apply to your module, or any html based web page to provide a relatively easy way to control output formatting.
The basic concept is that you create ‘divs’ for the ‘sections’ of your output, then apply classes to them which provide positioning and some visual UI elements like colors, borders, images, etc. The resuls of using a framework like Blueprint, is very clean markup in your view, with all of the positioning and visual attributes provided by the included blueprint stylesheet.
Getting Started:
The project template comes pre-configured with Blueprint installed. You can find the Blueprint resources under the “Content” folder of your solution
figure 1. Blueprint CSS Framework resources
The Gooddogs DotNetNuke Technology Template will load the necessary stylesheets via the “module.css” file, which is automatically included in your module controls by the DotNetNuke frameowkr, so you do not have to remember to add the “link” statements to your views. The Blueprint classes will automatically be available for you to use in any of your module controls.
I won’t go into a lot of detail about using Blueprint, you can read the Wiki and Tutorials on their web site for more information.
However, just understand that the basics are as follows:
1. add a “div” around your entire module’s output and give it a class named “container”
2. decide on the width of your overall container and add a “span-n” class to the div.
(NOTE: A future blog / video will show you how to use the Blueprint framework to create a ‘responsive’ design that will re-format the output depending upon the width of the pane in which it’s being displayed, but for now we’ll start simple and work with a fixed-width module design)
3. for each row of output, decide on the column layout for your content
4. for each column, add a “column” class to the div, and a “span-n” class to set it’s width.
5. on the last column of a row, add a “last” class. This tells Blueprint the row is done and to start the next column on the next row.
There are many other classes you can add to your divs to control formatting and visual attributes, see the Blueprint Wiki for more information.
Example:
So a module with 2 rows of output, 24 columns wide, with 2 columns equally divided on the first row, and 3 columns equally divided on the second would look like this
The Blueprint markup to achieve that layout would look like this…
<!-- overall module container -->
<div class="container span-24">
<!-- row 1 -->
<div class="column span-12" />
<div class="column span-12 last" />
<!-- row 2 -->
<div class="column span-8" />
<div class="column span-8" />
<div class="column span-8 last" />
</div>
Really clean markup, isn’t it? And easy to adjust complex layouts by changing the
span-n values to adjust column widths.
Specially formatted Message Boxes
The Gooddogs DotNetNuke Technology Template also includes a special stylesheet named “messages.css” which is located in the “Content” folder. It provides some specialized classes for user messages such as "info”, “error”, “warning”, etc.
You can see the different classes on the “Demonstration: page of a newly created module project using the template.
Demonstration Video
The following video demonstrates the Blueprint concepts and how to format the output of your module using the Blueprint classes.
Coming up next…
The next entry in this series will look at the Entity Framework and WCF Data Service components of the template, and how they are used to provide the data access layer for your module.
Thanks for reading …
9 comment(s) so far...
Re: Let’s Build a Module #3–Output Formatting
Thanks for new tutorial.
Question/Upgrade:
What if I already use Blueprint css in skin?
Is posible to detect this and use only skin css?
By Jernej Pirc on
1/17/2012
|
Re: Let’s Build a Module #3–Output Formatting
I have a concern about this. I am a big fan of BluePrint and I use it as the basis of all my custom skins.
But it seems like overkill for a module. A lot of BluePrint is generic in nature for defining page structure, and font styles, and such. I don't want my module.css to load CSS rules for H1, H2, etc elements that will now conflict with the rules that are defined in skin.css.
First, if the base skin (as in my case) already implements BluePrint, we are going to have to worry about collision and unnecessary bloat.
Second, one of the MOST important aspects of any module is the ability to seamlessly blend it into ANY website. If the module implements a stack of bloated CSS rules, that is just more CSS rules that will need to be overwritten during the implementation phase to get it to blend.
I am a firm believer that every module should use very specific CSS selectors to ONLY target the elements that exist within that module. At the very least, this means wrapping the entire module HTML in a named div like "" and then every CSS rule in the module.css should be preceded with ".myModule" like ".myModule H1".
I'm not saying it can't be done, but it sure seems like overkill. I think it would be more appropriate to do another exercise of building a custom DNN Skin that includes BluePrint instead of a custom DNN module.
By Jay Mathis on
1/17/2012
|
Re: Let’s Build a Module #3–Output Formatting
Regarding blueprint. I would actually really love to see DNN adopt it as a standard CSS framework and automatically include it just like jQuery. It would be great to standardize on one framework and get everyone on the same page.
By Jay Mathis on
1/17/2012
|
Re: Let’s Build a Module #3–Output Formatting
@Jernej @Jay thanks for the comments, I understand your concerns. I will be looking into a way to only include the blueprint css files if they are not already loaded. It's easy enough to comment out or remove the standard tag classes like h1, h2, etc, but since I'm loading the blueprint package via nuget, that level of customization is difficult. I hear your concerns and will see if I can come up with a better solution.
By Steve Fabian on
1/17/2012
|
Re: Let’s Build a Module #3–Output Formatting
Thanks Steve
I am looking forward to seeing what you come with.
One of my fears of going down this path is that you will find your module wont work with many skins simply because it won't fit. The grid system within BluePrint (in fact, all grid systems) needs a starting width definition to work. For example, start with 960px. If I want 24 columns, then 960/24 = 40px per column. Therefore "span-12" is defined in CSS as 40*12=480px. This of course make the extremely bold assumption that the skin pane I placing this module into actually has that much space available!
If you are developing a custom module for a specific skin, then the issue is not really a big deal as you likely know exactly what dimensions you are working with.. However, if you are developing a commercial or general module, you MUST be constantly aware that you don not have any control over where this module will be placed or what size dimensions are available to your module.
One thing I often notice is that module developers get too focused on the layout of the module and forget that layout is really the responsibility of the skin / panes.
For example, the diagram you show above is very suggestive of a skin pane layout. Why not just let the skin worry about that? That is what it is for. It might be better to break up up the single module control with multiple peices into multiple controls that are meant to be placed on the same page and function together (perhaps with inter-module communication if necessary).
Alternatively, if that is not feasible, please consider that the vision you have of how the module components should be laid out may not ideal for my skin. The piece that you envision being in the top left box, my client might want it placed in the top right box.
A nice module templating system would be a better solution. A lot of the Ventrian modules provide a nice templating method that allows the admin to define an HTMl template similar to creating a HTML skin with [TOKEN] replacement.
That might be a more elegant solution than trying to implement a CSS framework that really belongs at the skin level anyways.
By Jay Mathis on
1/18/2012
|
Re: Let’s Build a Module #3–Output Formatting
Steve, maybe it's a bit early to ask for this and you have already a plan, but how will this Blueprint.css framework work with the new DNN 6 Form pattern? Maybe it would be better if you just started using the very basics and keep the blueprint until a later step?
By Vicenç Masanas on
1/24/2012
|
Re: Let’s Build a Module #3–Output Formatting
Thanks for all the great feedback related to the Blueprint css framework. I am re-visiting the usage of blueprint css at the module level vs using it at the skin level.
By Steve Fabian on
1/24/2012
|
Re: Let’s Build a Module #3–Output Formatting
Any news / timeplan on tutorial?
Do you already chose module functionality?
DNN Web service security in c#?
By Jernej Pirc on
2/6/2012
|
Re: Let’s Build a Module #3–Output Formatting
@Jernej, the next entry, "Data Access with Entity Framework and a WCF Data Service" should be done within the next day or two, Tuesday at the latest
To your second question, No, first I will demonstrate the usage of each individual component, then a final video showing how to put it all together to build a module.
and to your last question, yes, DotNetNuke role based security will be implemented in the WCF Service component
By Steve Fabian on
1/29/2012
|