Common ASPX to Virtual Folder?

[J Smithers]

I have several ASPX pages (with code-behind logic) that I reuse amongst many
Web sites on the same production server. Currently each Web site has its own
copy of these aspx pages. I was thinking that it might be a good idea to
move these common aspx pages to a new folder and then make them accessible
via a new virtual directory in each Web site. Is this a good idea? Bad idea?
Thoughts, opinions?

Thanks!

 

[Steve C. Orr [MVP, MCSD]]

If they are extremely basic pages (pretty much static html) then this could
work.
Otherwise it might be better to make them into custom controls.

 

[J Smithers]

If I make them into custom controls, then wouldn't I then have to place them
on other ASPX pages (pages I don't have now) in order for them to be
accessed? FWIW: these aren't just small HTML snippets that could go into
user controls. These are full-blown pages that hook into a middle tier, etc.

I really want to understand this. Lets take my first reused page -
Foo.aspx - and we convert it into a custom control. How would we open
Foo.aspx (as a custom control) from the menuing system or from other links?
Wouldn't I have to place it in a new page FooHoster.aspx - and load it in
the page_load event of FooHoster.aspx - or am I totally missing something
here? Or am I understanding this correctly and it is a standard and
recommended practice?

Thanks!!!!

 

[Steve C. Orr [MVP, MCSD]]

Yes, you would have to drag a control onto a page. Is that difficult?
Seems like a small price to pay for efficient, object oriented code reuse.

Coversely, pages use code behinds, which compile into DLLs that are project
specific and tend to reference other files that are project specific... it
can get messy trying to share complex pages.

 

[IPGrunt]

If I make them into custom controls, then wouldn't I then have to place them
on other ASPX pages (pages I don't have now) in order for them to be
accessed? FWIW: these aren't just small HTML snippets that could go into
user controls. These are full-blown pages that hook into a middle tier, etc.

I really want to understand this. Lets take my first reused page -
Foo.aspx - and we convert it into a custom control. How would we open

P> Foo.aspx (as a custom control) from the menuing system or from other
links?

Wouldn't I have to place it in a new page FooHoster.aspx - and load it in
the page_load event of FooHoster.aspx - or am I totally missing something
here? Or am I understanding this correctly and it is a standard and
recommended practice?

Thanks!!!!

Perhaps you are still thinking in the old ASP code model, where one
includes script on a page in a linear fashion? I've written lots of code
like this, in the ASP days.

It took me a while to get used to implementing my middle tier as classes,
and then using them in the codebehind of my view tier.

Is this what you're lookign for?

-- ipgrunt

 

[J Smithers]

<< Is that difficult? >>
Nope, but of course it can often be easy to do the wrong thing or create
complexity in one area while trying to reduce it in another (thus your
second paragraph, I believe). Thanks for confirming what I thought was the
case - I'm now just a bit further up the learning curve.

- JS

 

[J Smithers]

<<Is this what you're lookign for?>>
Thanks, but not really. I've already separated everything out into tiers
(starting in the design phase) and I never really worked with classic ASP
beyond a "Hello World" page. New to the Web, but not OOP.
So, what I have is some non-trivial aspx pages (calling middle-tier for
everything but UI-specific functionality) using a home-grown templating
strategy (couldn't wait for 2.0 Master pages). Of course scope creep is
happening and now I have to duplicate this thing on one server. I was just
going through the app and looking for things (like common jpgs and css
files) to move out into a common folder structure accessible via virtual
directories (read-only) from each "copy" of this Web application. It
occurred to me that I could perhaps move some of the aspx pages off as
well - with Execute/script only permissions on the virtual directory. Thus
my OP. Just wondering if it makes sense.

Thanks again!

 

[IPGrunt]

<<Is this what you're lookign for?>>
Thanks, but not really. I've already separated everything out into tiers
(starting in the design phase) and I never really worked with classic ASP
beyond a "Hello World" page. New to the Web, but not OOP.
So, what I have is some non-trivial aspx pages (calling middle-tier for
everything but UI-specific functionality) using a home-grown templating
strategy (couldn't wait for 2.0 Master pages). Of course scope creep is
happening and now I have to duplicate this thing on one server. I was just
going through the app and looking for things (like common jpgs and css
files) to move out into a common folder structure accessible via virtual
directories (read-only) from each "copy" of this Web application. It
occurred to me that I could perhaps move some of the aspx pages off as
well - with Execute/script only permissions on the virtual directory. Thus
my OP. Just wondering if it makes sense.

Thanks again!

Very Good, Mr. Smithers,

I too have wanted 'master pages' from the moment I realized they were
missing! I tried a simple solution with my own website that involves
extending the Page class. It works, but I still have unworkable issues and
besides, it's a real pain to have to create HTML bit by bit using
LiteralControl calls.

The other day I saw a solution that uses a clever search routine to parse
structures behind the page, looking for things like the header area, and
then has delegate interfaces to add specific items (to insert the same call
to a .css file, for instance). Clever, but clumsy workarounds for a feature
that at first, I couldn't believe were not there. UserControls just don't
hack it most of the time!

So, what I do is keep a library of template pages, and copy and paste what
I need with each new page I create. It is very labor intensive, but it is
simple and works. I'm just glad I'm not managing development groups right
now. That's where the real problems lie in standardizing code.

Good luck.

--ipgrunt

<Snip>
--