|
|
|
Joined: 3/31/2010
Posts: 19
|
|
|
The DNN Community has grrreat documentation / information about creating *basic* skins / containers with HTML / CSS. Everything works as documented, except all documentation departs HTML / CSS at the spot starting to deal with menus, sitemaps, and other important skin objects.
At that stage, information is available only for dealing with ASPX. While the majority of information about skinning details HTML / CSS, each look at customizing work in designs always leads to configuring the ASPX files.
I intend to learn ASP.NET asap, but right now I don't have more experience than HTML / CSS. So, I examined many solid, working ASPX based skins - including DarkKnight and many others - from the ASPX perspective.
I'm not claiming any successes yet, but the work on a ASPX file appears to be manageable. Any required code for the DNN functions can be found in documentation, will all code confirmed before commitments by examining many, many ASPX pages where the functions operate correctly. I might not understand exactly why everything works until the ASP.NET education progresses, but at least for now sites can proceed.
However, I'm still having a few problems:
- While there's plenty of documentation about dealing with pure HTML/CSS skins, I cannot seem to find any complete information about building skins starting with only ASPX pages. HTML/CSS skins need several files gathered and packaged in a specific method, but I do not know what's needs to be gathered and packaged for a complete ASCX group, and I'd rather not start guessing/experimenting. What needs to be packaged with ASPX files? Is there any documentation dealing with skins / containers using only ASPX?
- I've examined many solid ASPX pages. Everything, including the HTML, appears to make sense, except I cannot observe where to place a reference to CSS stylesheets dealing with the HTML in the ASCX page. Where are the CSS files referenced in the ASPX pages?
In advance I thank everybody for any help. As my knowledge grows over times ahead I look forward to helping the next generation of folks learning about the DotNetNuke platform.
|
|
|
|
| |
|
|
|
|
www.40fingers.net Joined: 2/9/2006
Posts: 4430
|
|
|
ASCX skins are not a lot more difficult to create then HTML skins.
You don't need al lot of .NET knowledge for it.
The ASCX file is the actual skin, an HTML skin is a template for the ASCX file and get's parsed by DNN.
The CSS files are included automatically based on their name (skin.css, "skinname.css", container.css, etc.)
No need to include them in the ascx skin as long as you stick to the naming conventions
Did you read this blog series by Joe Brinkman?
http://www.theaccidentalgeek.com/post/2010/06/28/DotNetNuke-Skinning-101-%28Part-1%29.aspx
Here's a part of something I wrote (not finished) on skins some time ago:
What’s in a skin?
Let’s look at actual content of a skin file.
We’ll look at a skin with only one skin object and one Content Pane.
The skin object is the Logo skin object, which renders the logo the site administrator has set.
The content of this very simple skin would be this:
<%@ Control language=“vb” AutoEventWireup=“false” Explicit=“True” Inherits=“DotNetNuke.UI.Skins.Skin” %>
<%@ Register TagPrefix=“dnn” TagName=“LOGO” Src=“~/Admin/Skins/Logo.ascx” %>
<div id=“s_container”>
<div id=“s_header”>
<dnn:LOGO runat=“server” id=“dnnLOGO” />
</div>
<div runat=“server” id=“ContentPane” class=“ContentPane” ></div>
</div>
The skin consists of 2 parts, declarations on top (<%@......%>) and the actual skin content
Declarations:
The first line tells DNN, this is a skin file.
The second one tells dotnetnuke where it can find the Logo skin object control.
The Skin content:
This is a mix of regular HTML and skin objects.
Everything that is not regular HTML will have an attribute runat=“server” to tell the system something has to be processed. In this case there are 2 controls in the skin; the logo skin object and a Contentpane.
The red part is the logo skin object and the sites logo will appear on the page on that spot.
There is also one ContentPane in the skin, it’s the blue line.
(it does not have a declaration on top and DNN will consider any element with runat=server without a declaration as a contenpane)
This is an element to which the site administrator can add modules from the control panelAn
The HTML file
So far it seems all quit easy, but creating an HTML skin is easier for non programmers.
The corresponding HTML file would look like this:
<!DOCTYPE html PUBLIC “-//W3C//DTD XHTML 1.0 Transitional//EN”
“http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd”>
<html xmlns=“http://www.w3.org/1999/xhtml”>
<head>
<link rel=“stylesheet” type=“text/css” href=“skin.css” />
<title></title>
</head>
<body>
<div id=“s_container”>
<div id=“s_header”>
<object id=“dnnLOGO” codetype=“dotnetnuke/server” codebase=“LOGO”>
</object>
</div>
<object id=“ContentPane” codetype=“dotnetnuke/server” codebase=“CONTENTPANE”>
<param name=“class” value=“ContentPane” />
</object>
</div>
</body>
As you can see this is a regular XHTML document, with some object tags added.
These object tags represent the skin objects.
You can also see that the HTML document has a doctype, head and body.
Since these are not needed in the ascx file (they are already present in the DNN base page) the skin parser removes them.
The link to skin.css is just there to check the HTML skin in a browser.
The object tags get replaced by their corresponding declarations and tags in the ascx file.
As you can see every skin object can have parameters, which will be converted to attributes in the ASCX file.
HTH
|
|
|
|
| |
|
|
Joined: 3/31/2010
Posts: 19
|
|
|
Thank you, Timo, for your thoughtful reply (also: thank you for all the other useful information you're responsible for in the DNN Community).
Yes, I did read Mr. Joel Brinkman's great series about creating skins (thank you, Mr. Brinkman).
The question about how a CSS and a ASCX file are managed together was something of a "missing link." Are you explaining that if the ASCX file is named "skin.ascx" DNN "knows" to locate a corresponding "skin.css" file?
Asking the same question with another example, if there's a file named 2-col_right_sidebar.ascx DNN would locate a CSS file named 2-col_right_sidebar.css?
Do these examples represent how CSS is managed working only with ASCX files?
These questions about using ASCX rather than HTML were inspired by some documentation explaining work in HTML, with other important documentation explaining work in *only* ASCX terms. Although all work can be accomplished in HTML, since not all documentation covers a total HTML approach working with ASCX exclusively seemed to make sense.
After posting the original message on this thread, I did solve those questions about how to get all work done in only HTML. Particularly, many important skin-objects had configurations documented only in ASCX, but with some investigation I figured-out how to deal with those configurations between HTML and the XML manifest. With some of these skin-objects some (not all) documentation was less-than clear about which skin-objects need attendant specifications included in an XML file within the skin or container package. I did not explain why working with ASCX rather than HTML seemed to make more sense, but the root of that inquiry had to do with more/less adequate documentation surrounding exactly the information required among the many various skin-objects in either HTML or XML.
Since some important skin-objects need different documentation, there were many questions in some instances about where specs belong. Many of what appeared to be the most dependable answers in the DNN community were presented as explanations dealing with *only* ASCX files ... some of the conclusions did not explain how to deal with the work using only HTML/XML. I eventually deduced all the required answers looking at many, many skin packages to figure-out how other folks managed each component.
I cannot afford the effort right now, but in a few weeks I intend to send the folks at DNN a detailed account of this experience. The suggestion will be these experiences might help other new DNN people more clearly understand the relationship between HTML and ASCX, and provide some guide to approaching ASP.NET from the perspective of examining DNN.
My work surrounds journalism and information-management, not computer programming. Still, I'm committed to learning ASP.NET and the fundamentals of programming for the purpose of information broadcast/distribution. DNN is an outstanding tool (thank you, DNN), but because DNN is deeply useful the reach can be extremely complex for people without a complete commitment to development.
Within weeks we'll be sending DNN money for the Enterprise Edition (they deserve every nickle, but first I gotta scare-it-up with biz). The Community Edition has been a super asset helping get work started. I will be happy to help with basic documentation helping more folks be involved with the DNN community (rather than Joomla, WordPress, Kentico, Umbraco, etc.). Some work toward helping Soccer Moms or local PTA's or small-businesses accept DNN might help expand the community larger than WordPress or some of the others. Nailing-down some of these explanations might help, and I'd be happy to help from the perspective of a new user.
|
|
|
|
| |
|
|
|
|
www.40fingers.net Joined: 2/9/2006
Posts: 4430
|
|
|
I started on Skinning documentation some time ago, but it's a lot of work.
When there are areas in the current documentation that are unclear to you, I would be great-full for your feedback.
When a skin.css file exists it gets loaded, independent of the skins name.
When a "skinname".css file exists (the name of the skins ascx file) it get's loaded too.
Same for Container.css and "Containername".css
This is true for HTML and ASCX skins, as HTML skins are not really skins.
A skin is always an ASCX file in DNN, the HTML skin is just a template that gets converted by DNN to an ASCX file.
HTML skins exist to make DNN skinning easier for non asp.net HTML developers.
Here's some more on Stylesheets:
DotNetNuke and Style sheets
In HTML development it's a good practice to separate content and design.
The CSS styles that make up the actual design are defined in separate files called stylesheets.
DotNetNuke loads several style sheets for a page.
For part that makes up a DotNetNuke page there is a style sheets that could be loaded / used.
The "parts" are: Framework, Portal, Skin, Container & Module style sheets.
The Framework stylesheet always gets loaded, the rest only get loaded if they actaully exist.
Framework CSS
Location of this file: /Portals/_Default/Default.css
This file that contains basic framework CSS, you could see it as the “Fallback: stylesheet.
It also contains some CSS from previous DNN versions.
This CSS is the only stylesheet that always gets loaded.
Further below I explain why you should not edit or delete this file.
Portal CSS
This is a CSS file that is specific to a portal. By default it does not contain any CSS, but it can be edited by a site admin from within DNN to overrule CSS in the skins. (Mostly used for small tweaks)
Location of this file: /Portals/”PortalFolder”/Portal.css
If you remove this file from the portal folder it does not get loaded.
There are two other kinds of CSS files that are only loaded if they exist;
Css Files belonging to Skins / Containers and Modules.
Skin package related css files
These are the CSS files that also only get loaded if they exist.
(if you don’t add them to the skin package, there won’t be a link in the head of the page)
For a Skin
A. Skin.css
A style sheet that contains CSS for all the skins in a package.
If a Skin.css file exists in the package it will load for every skin in the package.
Locations:
/Portals/_Default/Skins/"MySkin"/Skin.css
OR
/Portals/"PortalFolder"/Skins/"MySkin"/Skin.css
B. “SkinName”.css
A Stylesheet with the same name as a skin file (ASCX/HTML), it contains specific CSS for that skin.
It is generally used to overwrite styles from Skin.css for that specific skin variation.
Locations:
/Portals/_Default/Skins/"MySkin"/"SkinName".css
OR
/Portals/"PortalFolder"/Skins/"MySkin"/"SkinName".css
For a Container
Container.css
A style sheet that contains CSS for all the containers in a package.
If a Container.css file exists in the package it will load for every container in the package.
Locations:
/Portals/_Default/Containers/MyContainer/Container.css
OR
/Portals/"PortalFolder"/Containers/MyContainer/Container.css
“ContainerName”.css
A Stylesheet with the same name as a container file (ASCX/HTML), it contains specific CSS for that container.
It is generally used to overwrite styles from Container.css for that specific container variation.
Locations:
/Portals/_Default/Containers/ MyContainer /"ContainerName".css
OR
/Portals/"PortalFolder"/Containers/ MyContainer /"ContainerName".css
Note on Container Css files.
There is something fundamentally different between the CSS for a skin and a container.
A page can have only one skin, but because you can have different modules all with mutual or different containers on the same page there are 2 things you should take care of.
1. You cannot use Ids in the static HTML of your container.
The reason for this is that a container can appear more than once on the same page (if 2 modules have the same container). Using an ID would result in an XHTML error, since ID’s must be unique on the page.
2. You should try to use unique Css classes in your containers. If you don’t ,you risk two containers influencing each other. If two containers contain a mutual css class and some Css addressing this you can get strange results because the container that gets loaded last will overrule the one before it.
Modules CSS: Module.css
Some modules have a module.css file with some basic CSS to make sure the module renders ok.
If a module on the page has a module,css file available it will get loaded.
So only the CSS files of modules that are on the page get loaded.
Location of these files: /DestopModules/"ModuleName"/Module.css
Stylesheet load order
If you want to create DNN skin effectively it is important to understand the order in which the stylesheets get loaded. The order is; modules, framework, skin, container, portal.
Module.css
Default.css
Skin.css
Skinname.css
Container.css
Containername.css
Portal.css
This means an Admin can always overrule any CSS by editing Portal.css, because it is loaded last.
|
|
|
|
| |
|
|
Joined: 3/31/2010
Posts: 19
|
|
|
Thank you, Timo.
Thank you.
There're good reasons they call writing "work." Uhg.
Same with any art, 10,000 individuals always deliver 10,000 different impressions. The trick is nailing-down what everybody understands.
That target cannot arrive absent audience impressions. What folks don't hear is more important than what is understood.
All DNN documentation deserves applause. Thank you for all the super information.
Although I am not a "developer" Razor Shops manages full-blown development projects from the media/marketing/advertising perspective. Personally, I will learn ASP.NET without any intention of being a "programmer." My knowledge of ASP.NET has entirely to do with planning the business of media, communications, and journalism. One of the RA partners is a full-blown ASP.NET rock-star (truly) having spent nearly 8-years with Microsoft. So, although I never intend to be any "programmer," Razor Shops has perfectly professional development talent ready to manage teams of developers dealing with complex projects (incidentally - although my partner is a true ASP.NET rock-star, I learn more investigating work independently rather than taking the "easy route" asking him).
The point is, Timo, professionally Razor Shops must provide exact documentation detailing DNN and the technical side of our media, communications, advertising and marketing work. Providing excellent customer service Razor Shops needs to organize documentation as complete as DNN.
If you send direct contact information outside this forum I'll provide access to the private Razor Shops business portal where all the RA documentation is gathered. You're welcome to take it or leave it. Any RA documentation can be used by DNN in any way, including exact reproductions distributed freely. DNN is welcome to copy anything y'all think might be useful. The world is genuinely a better place because of DotNetNuke. Thank you.
|
|
|
|
| |