Last post Dec 22, 2005 04:26 PM by Myster
Dec 20, 2005 10:27 PM|Myster|LINK
I'm pretty sure the answer will be no.
But is there the ability to skin 'inside' core modules, for example I want to change the links module to use <ul> list not tables
I'm guessing it's not possible with the current version, so my post therefore becomes a feature suggestion.
Perhaps if I had a "Desktop Modules/../.." folder structure under my skin folder, then any ascx files I specify that have the same name as a desktop module ascx file.... would take over ...
There's probably lots of flaws in that idea... thinking of some already ... oh well... we can dream.
Dec 21, 2005 01:33 AM|DeveloperMCDBA|LINK
Dec 21, 2005 12:08 PM|jjmartin|LINK
for the links module, you may want to check out dotnetnuke.dk - he has a links module with full source based in C#. I think it uses the datagrid like the DNN counterpart, but you may find it easier to work with and wouldn't mess with "Core".
Dec 22, 2005 11:32 AM|DeveloperMCDBA|LINK
I just implemented this feature. I had always wanted it and it didn't take much effort, so I said, what the heck. [:)]
I've also asked if I can contribute or at least implement this feature in the core module...so hopefully it will stay with it. [:)]
Dec 22, 2005 02:59 PM|thecrispy1|LINK
Skinning of modules is definately a very subjective topic. There is definately not a one fits all at this time and considering the performance hit a site can take on skinning, I am not so sure there will be one soon.
The forum has its own "themes" but I often hear complaints from the community about how it should be simple like dnn, but honestly I don't see another way for that too happen so we will continue the themes. The reason we call it themes is because it is
not skinning as it exists in dnn. This is because you cannot upload and have it parse and can only get a new theme by ftp'ing it to the site.
Dec 22, 2005 03:57 PM|xddg|LINK
Chris's interpretation to managing *themes* compared to *skinning* is correct, and if nececssary you can do some changes to the core that can reside quite happily, especially if you're using tokens, like the links that are displayed. EG the Tokens like
the Links are stored here - in the Admin Folder.
If you are comfortable with coding.. I have no idea if this is possible, you would work on a renamed files - instead of being Links.ascx, copy and rename to LinksNT.ascx or whatever and format it appropriately.. Then you would replace the Links.ascx below
to LinksNT.ascx in the skin file.
<%@ Register TagPrefix="dnn" TagName="Links" Src="~/admin/Skins/Links.ascx"%>
Sure this is a modification, but if you keep the same file there - you've got a fallback. Then you can work on your customised one and utilise that.
This does mean more maintenance, particularly with site upgrades, but the interesting thing now is that the modules themselves, being detached in the manner they are, now have their own projects so you can be kept informed on changes to them, and see how
they affect you.
And if you're running multi child portals, it could also help you maintain the integrity and have the option of experimenting on a particular module - like the links module without affecting anyone.
So while it's not an answer, it's a work around because Chris is right - the whole dynamics and behaviour of modules is not related to the skinning element, and you can see the even by how the tokens for skinning sites are in a totally different folder and
while intergrated, pertain the to the look and feel of the module, whereas the module pertains the functionality.
Why not give that a try and start experimenting - since if I'm right - you're on a mission to create CSS based management - and that's cool - I've just spent too long on it now and it wore me out, so I function on the what DNN has to offer these days and
it's great to see others take it a small step closer.
Dec 22, 2005 04:26 PM|Myster|LINK
Yep I've got no problem updating the ascx modules myself but I'm going to hand the site over to some other developers when I've finished. So mainly my wish is that they can upgrade whatever they like without it breaking. and it'd be nice If they can upgrade
to the next DNN version (especially since this is a 4."0h" version ;-) I can't upgragde to 4.1 yet cos the blog module isn't happy with 4.1
We'll have to give DeveloperMCDBA's module a look it'll probably do what we're after.
And yes CSS is the way we want to go! In this particular case it's not really a mission, just a side-quest. ;-)