Multiple *.ascx files with a single *.ascx.cs in VS.NET 2003

[Holger (David) Wagner]

Hi all,

I'd like to have several "skins" for an application that are
"structurally different" (i.e. controls at different locations, some
controls visible only in a particular "skin"). The application is
implemented with a single default.aspx which loads a couple of
ascx-Controls (navigation, contents depending on parameter and so on).

Now, an obvious approach is simply duplicating the ascx-Files into an
own directory structure which resembles the original directory
structure, but keeping the codebehind files (*.ascx.cs) at the original
location (and only once, as the functionality should remain the same and
I don't uselessly duplicate code).

I can then "switch skins" by simply changing the path in the default.aspx.

This approach works fine for the running application, but VS.NET 2003
doesn't like it very much - at least not for the designer. I've tried
changing the path to the code behind file so that it is correct, but
still it says it cannot load the code behind file (it does work for the
original ascx-file, with a path like ../../../<pathback> which would be
the same in the "other skin directory").

Is there any way to go with this approach and still use the designer?
Would be using an alternative tool (e.g. Dreamweaver) solve this problem?

Is there a different, possible more elegant approach to this? I'd do
this with different CSS style sheets if the structure wasn't so different...

kind regards and thanks a lot for any help,
david

 

[Cowboy \(Gregory A. Beamer\) [MVP]]

Option 1:
Create a class file that has the actual code. Create the click events, et
al, in each skin. The code is still in one place, except event handlers.

Option 2:
Look at .NET Nuke, which has a skinning engine. Not as easy to use as
clicking each page, but much quicker.

Option 3:
Wait for themes in .NET 2.0.

Option 4:
?

--
Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA

************************************************
Think Outside the Box!
************************************************

 

[Holger (David) Wagner]

Hi Greg,

Option 1:
Create a class file that has the actual code. Create the click events, et
al, in each skin. The code is still in one place, except event handlers.

So would that class file be the superclass of the code-behind
file/class? In that case, I'd still have to push up the members of the
"original code behind file" up on level. If not, I'd still need some way
of accessing the widgets which again would mean duplicated code (even
though that duplicated code would be rather simple)...

Option 2:
Look at .NET Nuke, which has a skinning engine. Not as easy to use as
clicking each page, but much quicker.

I haven't really looked deep into this, but it seems that dot net nuke
is something to be used right from the start of a project. We already
have an existing application that shall still work when we add a similar
application for a different client with different look (and a few added
functionalities).

Option 3:
Wait for themes in .NET 2.0.

We have actually considered trying .NET 2.0 - but as this is a system
that goes to production in August (2004), we'd rather use stable
technology...

kind regards,
david