HTML Frames.....

Is HTML frame is an old technology? Will the modern web application are
developed using the HTML frames? Does all the browsers support them?
Thank you for your suggestion,
NishAll browsers support frames, not all support iframes. I have never liked
frames and have always considered them old technology. Frames will exist
for a long time, but people have many choices for segmenting their pages.
They can use master pages. Or SmartNavigation. Or scrollable divs.
Just like any technology, it is more important to learn when to use
something rather than assuming that it might be obsolete.
"Nish" <Nish1989@.hotmail.com> wrote in message
news:%23YD$RzmRGHA.4332@.TK2MSFTNGP10.phx.gbl...
> Is HTML frame is an old technology? Will the modern web application are
> developed using the HTML frames? Does all the browsers support them?
> Thank you for your suggestion,
> Nish
>
Hi,
Peter Rilling wrote:
> All browsers support frames
Actually, not all browsers support frames. Mobile devices often don't,
or support them partly only. If the OP's website might be displayed on
mobile devices (PDAs, mobile phones), then I would rather avoid using
frames.

>, not all support iframes. I have never liked
> frames and have always considered them old technology. Frames will exist
> for a long time, but people have many choices for segmenting their pages.
> They can use master pages. Or SmartNavigation. Or scrollable divs.
> Just like any technology, it is more important to learn when to use
> something rather than assuming that it might be obsolete.
Frames have however one advantage over master pages or div: only parts
of the loaded "page" (I mean here page as a whole, meaning the frameset
and all frames) can be refreshed separately. It *can* be an advantage
(stress on *can*) in some situation, for example if one of the frame
contains a very big HTML table (in which case one might consider a
paging solution better, but anyway...).
It's possible to achieve the same with DIVs too, for example with AJAX.
However, it's more complicated and requests a good understanding of web
services, DOM, etc... as well as of the compatibility problems between
browsers.
Frames have a few divantages: Client-side communication between
frames is awkward, especially because synchronization problems are
involved: It's relatively complex for one frame to know for sure what
another frame's current state is. It's possible, but it needs a good design.
Also, the displayed URL does not necessarily correspond to a unique
state (because it's the frameset's URL and not a URL corresponding to
each of the loaded frames). This sounds like a very philosophical
problem, but it has implications one should be aware of. Again, it's
possible to solve this (for example using query strings on the
frameset's URL), but it's awkward and complicated.
I try to avoid using frames if I can, but I agree that you cannot really
call them obsolete. There are situations where they make sense. It's
good to be aware of the problems and advantages mentioned here to be
able to make an informed decision.
HTH,
Laurent
> Is HTML frame is an old technology?
I wouldn't call it a technology really. Just part of HTML.

> Will the modern web application are
> developed using the HTML frames?
Probably, though I hope not, as frames are usually implemented by developers
rather poorly. There's usually a better way to accomplish something rather
than resorting to frames.
Of coruse, there times when frames are useful.

> Does all the browsers support them?
Not sure if text browsers can handle them, but the major visual browsers
should be OK.
-Darrel

HTML Frames.....

Is HTML frame is an old technology? Will the modern web application are
developed using the HTML frames? Does all the browsers support them?
Thank you for your suggestion,
NishAll browsers support frames, not all support iframes. I have never liked
frames and have always considered them old technology. Frames will exist
for a long time, but people have many choices for segmenting their pages.
They can use master pages. Or SmartNavigation. Or scrollable divs.

Just like any technology, it is more important to learn when to use
something rather than assuming that it might be obsolete.

"Nish" <Nish1989@.hotmail.com> wrote in message
news:%23YD$RzmRGHA.4332@.TK2MSFTNGP10.phx.gbl...
> Is HTML frame is an old technology? Will the modern web application are
> developed using the HTML frames? Does all the browsers support them?
> Thank you for your suggestion,
> Nish
Hi,

Peter Rilling wrote:
> All browsers support frames

Actually, not all browsers support frames. Mobile devices often don't,
or support them partly only. If the OP's website might be displayed on
mobile devices (PDAs, mobile phones), then I would rather avoid using
frames.

>, not all support iframes. I have never liked
> frames and have always considered them old technology. Frames will exist
> for a long time, but people have many choices for segmenting their pages.
> They can use master pages. Or SmartNavigation. Or scrollable divs.
> Just like any technology, it is more important to learn when to use
> something rather than assuming that it might be obsolete.

Frames have however one advantage over master pages or div: only parts
of the loaded "page" (I mean here page as a whole, meaning the frameset
and all frames) can be refreshed separately. It *can* be an advantage
(stress on *can*) in some situation, for example if one of the frame
contains a very big HTML table (in which case one might consider a
paging solution better, but anyway...).

It's possible to achieve the same with DIVs too, for example with AJAX.
However, it's more complicated and requests a good understanding of web
services, DOM, etc... as well as of the compatibility problems between
browsers.

Frames have a few disadvantages: Client-side communication between
frames is awkward, especially because synchronization problems are
involved: It's relatively complex for one frame to know for sure what
another frame's current state is. It's possible, but it needs a good design.

Also, the displayed URL does not necessarily correspond to a unique
state (because it's the frameset's URL and not a URL corresponding to
each of the loaded frames). This sounds like a very philosophical
problem, but it has implications one should be aware of. Again, it's
possible to solve this (for example using query strings on the
frameset's URL), but it's awkward and complicated.

I try to avoid using frames if I can, but I agree that you cannot really
call them obsolete. There are situations where they make sense. It's
good to be aware of the problems and advantages mentioned here to be
able to make an informed decision.

HTH,
Laurent
> Is HTML frame is an old technology?

I wouldn't call it a technology really. Just part of HTML.

> Will the modern web application are
> developed using the HTML frames?

Probably, though I hope not, as frames are usually implemented by developers
rather poorly. There's usually a better way to accomplish something rather
than resorting to frames.

Of coruse, there times when frames are useful.

> Does all the browsers support them?

Not sure if text browsers can handle them, but the major visual browsers
should be OK.

-Darrel

HTML file server side includes plus forms authentication

We've got a project going that involves moving an old web site with a
massive dll written in C++ that produces most of the output from a SQL 7.0
data base on NT4 onto IIS on Windows 2003 Server with SQL 2000. All new
code is being written in C# using ASP.NET and we are using forms
authentication to control access to particular directories/applications.
We are having a hard time figuring out how to configure the thing so that
existing html files both a) have access controlled through ASP.NET forms
authentication and b) render server side includes correctly. If we
configure the htm/html files for the application on IIS to be handled by
ssinc.dll the includes are rendered correctly, but access is not restricted
by forms authentication. If we configure them to be handled by
aspnet_isapi.dll we get forms authentication control, but the includes are
ignored.
Oddly, simply renaming a file from *.html to *.aspx with no other changes
results in aspnet_isapi.dll handling it correctly -- providing forms
authentication access control and also rendering includes correctly. But if
the file name is *.htm or *.html, aspnet_isapi.dll fails to include the
includes. It almost seems like this is a bug! I cannot, at any rate, see
any reason why it would do this by design.
So, in theory, we could solve the problem by just re-naming all our htm/html
files with an aspx extension instead. Unfortunately this is not so easily
done in practice since the old C++ .dll that creates most pages and fills
them with stuff from the data base has hyperlinks to the *.html files hard
coded into it all over the place. It is not impossible to change this, but
we'd like to find a simpler way.
Can anyone offer a suggestion for a way to resolve this problem? Is it
simply a bug that aspnet_isapi.dll renders includes for *.aspx files but
fails to do so for an otherwise identical files with a .htm or .html
extension?
All the best,
will
William F. Zachmann, President
Canopus Research Inc.
http://www.canopusresearch.comHi William!

> Is it
> simply a bug that aspnet_isapi.dll renders includes for *.aspx files but
> fails to do so for an otherwise identical files with a .htm or .html
> extension?
I don't think it's a bug. Probably your IIS is configured in way that
*.aspx files are handled by aspnet_isapi.dll, but .htm/.html are not. To
change this mapping (for IIS 6) go to "Application settings" (tab "Home
directory" or "Virtual directory")
"Application settings", click "Configuration". On the "Mapping" tab, have a
look at the "Application extension", especially the ".aspx" mapping. Create
a similar extension mapping for ".htm" and ".html".
Now IIS will handle your .htm files using aspnet_isapi.dll. If you still
need more control you will need a custom http handler.
Alex
http://www.DotNet42.com - The Answer to Your DotNet Question
"William F. Zachmann" wrote:

> We've got a project going that involves moving an old web site with a
> massive dll written in C++ that produces most of the output from a SQL 7.0
> data base on NT4 onto IIS on Windows 2003 Server with SQL 2000. All new
> code is being written in C# using ASP.NET and we are using forms
> authentication to control access to particular directories/applications.
> We are having a hard time figuring out how to configure the thing so that
> existing html files both a) have access controlled through ASP.NET forms
> authentication and b) render server side includes correctly. If we
> configure the htm/html files for the application on IIS to be handled by
> ssinc.dll the includes are rendered correctly, but access is not restricte
d
> by forms authentication. If we configure them to be handled by
> aspnet_isapi.dll we get forms authentication control, but the includes are
> ignored.
> Oddly, simply renaming a file from *.html to *.aspx with no other changes
> results in aspnet_isapi.dll handling it correctly -- providing forms
> authentication access control and also rendering includes correctly. But
if
> the file name is *.htm or *.html, aspnet_isapi.dll fails to include the
> includes. It almost seems like this is a bug! I cannot, at any rate, see
> any reason why it would do this by design.
> So, in theory, we could solve the problem by just re-naming all our htm/ht
ml
> files with an aspx extension instead. Unfortunately this is not so easily
> done in practice since the old C++ .dll that creates most pages and fills
> them with stuff from the data base has hyperlinks to the *.html files hard
> coded into it all over the place. It is not impossible to change this, bu
t
> we'd like to find a simpler way.
> Can anyone offer a suggestion for a way to resolve this problem? Is it
> simply a bug that aspnet_isapi.dll renders includes for *.aspx files but
> fails to do so for an otherwise identical files with a .htm or .html
> extension?
> All the best,
> will
> William F. Zachmann, President
> Canopus Research Inc.
> http://www.canopusresearch.com
>
>
Alex,
Apparently I was not clear enough. I had already done that. IIS is already
handling my htm/html files through aspnet_isapi.dll. That brings them under
forms control access, but the includes are not rendered correctly. If I
re-name them to *.aspx, then they are handled correctly. Named *.htm/html
(with those extensions mapped to aspnet_isapi.dll) forms control works, but
includes are not rendered. If I map them to ssinc.dll, then includes are
rendered but I get no forms based access control.
All the best,
will
"Alex" <Alex@.discussions.microsoft.com> wrote in message
news:F8316EA5-66A5-493A-BFE3-93334F741F13@.microsoft.com...
> Hi William!
>
> I don't think it's a bug. Probably your IIS is configured in way that
> *.aspx files are handled by aspnet_isapi.dll, but .htm/.html are not. To
> change this mapping (for IIS 6) go to "Application settings" (tab "Home
> directory" or "Virtual directory")
> "Application settings", click "Configuration". On the "Mapping" tab, have
> a
> look at the "Application extension", especially the ".aspx" mapping.
> Create
> a similar extension mapping for ".htm" and ".html".
> Now IIS will handle your .htm files using aspnet_isapi.dll. If you still
> need more control you will need a custom http handler.
> Alex
> http://www.DotNet42.com - The Answer to Your DotNet Question
>
>
>
> "William F. Zachmann" wrote:
>
Will,
how about this:
1. Rename your .html files to .aspx
2. For the .html hyperlinks generated by your DLL you write an HTTP Handler
that does an URL rewrite from .html to .aspx.
For example this is what happens when you click on
http://www.dotnet42.com/NG_microsof...drawing/A_605/T
hreadDetail.htm
Alex
http://www.DotNet42.com - The Answer to Your DotNet Question
"William F. Zachmann" wrote:

> We've got a project going that involves moving an old web site with a
> massive dll written in C++ that produces most of the output from a SQL 7.0
> data base on NT4 onto IIS on Windows 2003 Server with SQL 2000. All new
> code is being written in C# using ASP.NET and we are using forms
> authentication to control access to particular directories/applications.
> We are having a hard time figuring out how to configure the thing so that
> existing html files both a) have access controlled through ASP.NET forms
> authentication and b) render server side includes correctly. If we
> configure the htm/html files for the application on IIS to be handled by
> ssinc.dll the includes are rendered correctly, but access is not restricte
d
> by forms authentication. If we configure them to be handled by
> aspnet_isapi.dll we get forms authentication control, but the includes are
> ignored.
> Oddly, simply renaming a file from *.html to *.aspx with no other changes
> results in aspnet_isapi.dll handling it correctly -- providing forms
> authentication access control and also rendering includes correctly. But
if
> the file name is *.htm or *.html, aspnet_isapi.dll fails to include the
> includes. It almost seems like this is a bug! I cannot, at any rate, see
> any reason why it would do this by design.
> So, in theory, we could solve the problem by just re-naming all our htm/ht
ml
> files with an aspx extension instead. Unfortunately this is not so easily
> done in practice since the old C++ .dll that creates most pages and fills
> them with stuff from the data base has hyperlinks to the *.html files hard
> coded into it all over the place. It is not impossible to change this, bu
t
> we'd like to find a simpler way.
> Can anyone offer a suggestion for a way to resolve this problem? Is it
> simply a bug that aspnet_isapi.dll renders includes for *.aspx files but
> fails to do so for an otherwise identical files with a .htm or .html
> extension?
> All the best,
> will
> William F. Zachmann, President
> Canopus Research Inc.
> http://www.canopusresearch.com
>
>
asp.net processing is a two part
1) map file extension to asp.net dll - this enables form authenication
2) <@. page > directive is found, this causes the page to processed as an
asp.net page and implements the include logic.
you can just add the <@.page> directive to your html pages and you're good to
go.
-- bruce (sqlwork.com)
"William F. Zachmann" <wfz@.NOcanopusresearchSPAM.com> wrote in message
news:e9bNSyE2FHA.2540@.TK2MSFTNGP09.phx.gbl...
> We've got a project going that involves moving an old web site with a
> massive dll written in C++ that produces most of the output from a SQL 7.0
> data base on NT4 onto IIS on Windows 2003 Server with SQL 2000. All new
> code is being written in C# using ASP.NET and we are using forms
> authentication to control access to particular directories/applications.
> We are having a hard time figuring out how to configure the thing so that
> existing html files both a) have access controlled through ASP.NET forms
> authentication and b) render server side includes correctly. If we
> configure the htm/html files for the application on IIS to be handled by
> ssinc.dll the includes are rendered correctly, but access is not
> restricted by forms authentication. If we configure them to be handled by
> aspnet_isapi.dll we get forms authentication control, but the includes are
> ignored.
> Oddly, simply renaming a file from *.html to *.aspx with no other changes
> results in aspnet_isapi.dll handling it correctly -- providing forms
> authentication access control and also rendering includes correctly. But
> if the file name is *.htm or *.html, aspnet_isapi.dll fails to include the
> includes. It almost seems like this is a bug! I cannot, at any rate, see
> any reason why it would do this by design.
> So, in theory, we could solve the problem by just re-naming all our
> htm/html files with an aspx extension instead. Unfortunately this is not
> so easily done in practice since the old C++ .dll that creates most pages
> and fills them with stuff from the data base has hyperlinks to the *.html
> files hard coded into it all over the place. It is not impossible to
> change this, but we'd like to find a simpler way.
> Can anyone offer a suggestion for a way to resolve this problem? Is it
> simply a bug that aspnet_isapi.dll renders includes for *.aspx files but
> fails to do so for an otherwise identical files with a .htm or .html
> extension?
> All the best,
> will
> William F. Zachmann, President
> Canopus Research Inc.
> http://www.canopusresearch.com
>
Bruce,
Sounds like you have provided the specific information I needed. I will try
that out to confirm that it works. Thanks very much!
All the best,
will
"Bruce Barker" <brubar_nospamplease_@.safeco.com> wrote in message
news:%23CYQWpL2FHA.3568@.TK2MSFTNGP15.phx.gbl...
> asp.net processing is a two part
> 1) map file extension to asp.net dll - this enables form authenication
> 2) <@. page > directive is found, this causes the page to processed as an
> asp.net page and implements the include logic.
> you can just add the <@.page> directive to your html pages and you're good
> to go.
> -- bruce (sqlwork.com)
>
> "William F. Zachmann" <wfz@.NOcanopusresearchSPAM.com> wrote in message
> news:e9bNSyE2FHA.2540@.TK2MSFTNGP09.phx.gbl...
>
Alex,
Thanks for your intention to help however, if you read through my original
message, you will see that I have already considered the possibility of
simply re-naming the htm/html files with aspx extensions but that this is
not a very good option since the old (massive) C++ dll has many hard-coded
dependencies tied to the file (and, for that matter, directory) names. I
quite explicitly said that I was looking for another alternative.
All the best,
will
"Alex" <Alex@.discussions.microsoft.com> wrote in message
news:7CA1CE05-59A9-4107-BCAF-8675AB75E4BE@.microsoft.com...
> Will,
> how about this:
> 1. Rename your .html files to .aspx
> 2. For the .html hyperlinks generated by your DLL you write an HTTP
> Handler
> that does an URL rewrite from .html to .aspx.
> For example this is what happens when you click on
> http://www.dotnet42.com/NG_microsof...ww.DotNet42.com - The Answer to Your DotNet Question
>
> "William F. Zachmann" wrote:
>

HTML controls instead of .Net server controls

Another front end guy that I work with wants to use old HTML controls instead
of the new .NET server controls. Since he is a old HTML and classic asp
person and is familiar with this, he wants to the old HTML controls instead
of the new .Net controls on a .Net web page. Please give me some opinions on
this. What are disadvantages or advantages, if any?

PS - I only use the new .Net controls. Never have used the old control
except for the file upload.

--
Chris DavoliJeesh. Tell him to wake up and join the 21st century. Really, man.
Peter
--
Co-founder, Eggheadcafe.com developer portal:
http://www.eggheadcafe.com
UnBlog:
http://petesbloggerama.blogspot.com
"Chris Davoli" wrote:

Quote:

Originally Posted by

Another front end guy that I work with wants to use old HTML controls instead
of the new .NET server controls. Since he is a old HTML and classic asp
person and is familiar with this, he wants to the old HTML controls instead
of the new .Net controls on a .Net web page. Please give me some opinions on
this. What are disadvantages or advantages, if any?
>
PS - I only use the new .Net controls. Never have used the old control
except for the file upload.
>
--
Chris Davoli
>

Peter Bromberg [C# MVP] napisa?(a):

Quote:

Originally Posted by

Jeesh. Tell him to wake up and join the 21st century. Really, man.
Peter

Web server controls are not always the best choice. If you want to take
care of quality of your (x)html code (in terms of web standards) and
build modern, cross-browser websites, you often must forget about some
of web controls because they're generating ugly and old-fashioned
markup. Especially in ASP.NET 1.1 that was a big problem. In that cases
html server controls was good alternative because you had full control
(almost) of the code you generate. Of course it requires some more
knowledge and skills (properly use (x)html - to deliver content and not
presentation, css to deliver presentational informatons and
javascript(ecmascript) to add behaviors) than using web server controls,
but its definitely good idea if we talk about modern, accessible and
cross-browser websites.
Html server controls have one more advantage - lower performance cost
than most of server controls.
So it's not so easy decision to get rid of html server controls and
advance into 21th century:)

--
It was my opinion and i'm definitely agree with it:)
PP
I was once an old school HTML instead of .Net but with VS2005 they have come a
long, long way. There are just to many advantages to ignore the new controls. I
don't event think about it anymore - the performance hit on most web pages is
insignificant - use the new controls.

On Fri, 15 Sep 2006 18:46:01 -0700, Chris Davoli
<ChrisDavoli@.discussions.microsoft.comwrote:

Quote:

Originally Posted by

>Another front end guy that I work with wants to use old HTML controls instead
>of the new .NET server controls. Since he is a old HTML and classic asp
>person and is familiar with this, he wants to the old HTML controls instead
>of the new .Net controls on a .Net web page. Please give me some opinions on
>this. What are disadvantages or advantages, if any?
>
>PS - I only use the new .Net controls. Never have used the old control
>except for the file upload.