By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
443,313 Members | 1,240 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 443,313 IT Pros & Developers. It's quick & easy.

why Microsoft don't like frames...

P: n/a
simple, they don't like things that restrict the server-side controls... and
when it comes to frames, you need client side stuff and that stuff's up the
asp.net strategy.
right or wrong?
Nov 17 '05 #1
Share this Question
Share on Google+
7 Replies


P: n/a
Actually, the reasoning against frames is more complex:

1. Many users hate frames (mostly due to bad implementations that have
surfaced over the past few years0
2. You cannot bookmark an individual page with frames

I use client side script regularly in .NET. I do not normally use frames,
but I do have some apps where they make sense, and I utilize frames in those
apps.

The .NET server side controls simplify your life, where they make sense
(which is many, if not most, applications). If you chose not to use them,
you write a lot of extra code. This is not necessarily bad; it is just
another way at approaching your development problem.

--
Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA
Author: ADO.NET and XML: ASP.NET on the Edge

************************************************** **************************
****
Think Outside the Box!
************************************************** **************************
****
"dj Bass" <sp******@hotmail.com> wrote in message
news:uV*************@tk2msftngp13.phx.gbl...
simple, they don't like things that restrict the server-side controls... and when it comes to frames, you need client side stuff and that stuff's up the asp.net strategy.
right or wrong?

Nov 17 '05 #2

P: n/a
And yet, if you go to the starter kits at www.asp.net, they have all
these report demos that use frames. Probably so you can see the
header and scroll the detail.
"dj Bass" <sp******@hotmail.com> wrote in message news:<uV*************@tk2msftngp13.phx.gbl>...
simple, they don't like things that restrict the server-side controls... and
when it comes to frames, you need client side stuff and that stuff's up the
asp.net strategy.
right or wrong?

Nov 17 '05 #3

P: n/a
My situation is that I've been called to port asp pages to asp.net... with
port being defined as rewriting the code the .net way, rather than getting
it working in VS.net.

A lot of the work relies on a tree section down the left hand side, and
through your selection, the differing screens have a control panel, then an
overview analyzing a database table, then a drill down into this table,
which currently is another frame.
+--------------------------------------------------------+
| tree | main
|
| | ooooooooooooooooooooooooooooooooo |
| | o control panel
o |
| | o
o |
| | ooooooooooooooooooooooooooooooooo |
| | o over view
o |
| | o
o |
| | o
o |
| | ooooooooooooooooooooooooooooooooo |
| | o detailed drill down o
|
| | o
o |
| | o
o |
| | ooooooooooooooooooooooooooooooooo |
+--------------------------------------------------------+
there's no reason why tree and main cause problems since a button click
simply launches another screen, but when you get a situation where a load of
records [overview] on a datagrid have selection, and you click on a button
on the [control panel], it's not possible to determine what records are
currently selected (i use a template column with check boxes to simulate
multiple selection), and therefore not posssible to do anything with those
selected columns.

Frames still are advantageous over DIV tags because frames are resizable,
catering for different resolutions and sizes that IE could be run at, where
the DIV is a set value, whether absolute or relative, it's still fixed.

Is it worth migrating to a DIV style main page where the drill downs and
datagrid objects are all written within DIV tags, rather than frames and
hence, other objects?

Thanks for your input.
Daniel.

"Cowboy (Gregory A. Beamer)" <No************@comcast.netRemuvThis> wrote in
message news:%2****************@TK2MSFTNGP12.phx.gbl...
Actually, the reasoning against frames is more complex:

1. Many users hate frames (mostly due to bad implementations that have
surfaced over the past few years0
2. You cannot bookmark an individual page with frames

I use client side script regularly in .NET. I do not normally use frames,
but I do have some apps where they make sense, and I utilize frames in those apps.

The .NET server side controls simplify your life, where they make sense
(which is many, if not most, applications). If you chose not to use them,
you write a lot of extra code. This is not necessarily bad; it is just
another way at approaching your development problem.

--
Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA
Author: ADO.NET and XML: ASP.NET on the Edge

************************************************** ************************** ****
Think Outside the Box!
************************************************** ************************** ****
"dj Bass" <sp******@hotmail.com> wrote in message
news:uV*************@tk2msftngp13.phx.gbl...
simple, they don't like things that restrict the server-side controls...

and
when it comes to frames, you need client side stuff and that stuff's up

the
asp.net strategy.
right or wrong?


Nov 17 '05 #4

P: n/a
> Wrong. Frames have always been problematic.

problematic because they are client side? or is it in an ideal world we'd
like everything to work in the server side, which sucks, because everytime a
refresh on anything occurs, the whole page has to be loaded rather than
individual sections.

Frames can be resized, by the user, or by the client side script, which
DIV's etc can't do.

i'd say they're not used properly, not problematic.
Nov 17 '05 #5

P: n/a
In a web site with static HTML pages they are no problem at all. Using them
properly is problematic in any kind of web application. If you don't believe
me, just try to build a web application with frames. Use ASP, ASP.Net, PHP,
or whatever flavor of server-side technology you want. It can be done, but
it is problematic.

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
http://www.takempis.com
Big things are made up of
lots of little things.

"dj Bass" <sp******@hotmail.com> wrote in message
news:e5**************@TK2MSFTNGP12.phx.gbl...
Wrong. Frames have always been problematic.
problematic because they are client side? or is it in an ideal world we'd
like everything to work in the server side, which sucks, because everytime

a refresh on anything occurs, the whole page has to be loaded rather than
individual sections.

Frames can be resized, by the user, or by the client side script, which
DIV's etc can't do.

i'd say they're not used properly, not problematic.

Nov 17 '05 #6

P: n/a
Daniel:

You have two issues here:

How do I layout my data?
How do I display individual data elements?

To the first (data layout), I would most likely lay out one after another
and allow the page to scroll. This will require "retraining" users, as the
info will not necessarily be contained on one screen (with scrolling
portions, of course - the frames). I do not see a lot of difference between
scrolling the whole page and scrolling single elements. You will need to
prototype the "new" way if you head that direction and ensure you do not
have an end user mutiny. If you continue with frames, take the time to fully
encapsulate each page. ASP is notorious for spaghetti code and pages that
are dependent on each other. .NET gives you the ability to straighten this
out, and separate the code and UI elements, as well. You can still have
client side script talk to individual frames and pass information (either
through some form of persistence (session variables or static (Shared
VB.NET) routines (careful with static, as users can bump into each other))
or through the querystring. You only seem to be more limited than ASP, as
you are not as familiar with it. I currently use querystring to set page
variables, although primarily for popup dialogs instead of frames.

Display is the method of getting the data on the page. DIV tag is an option,
but .NET has a bunch of great server controls, like the DataGrid, DataList
and Repeater, that allow you to layout your data. Unlike ASP, you simply
bind a DataTable or DataReader to the server control. You can also extend
many of these controls, as Dino Esposito does with the DataGrid in his ASP
..NET/ADO .NET book. The Repeater is the most flexible, as any HTML output is
legal.

What I am saying is the question of separating the Control Panel, Overview
and Drilldown into separate pages, or just separate elements on a single
page is a separate decision from the actual display of the data.

The .NET way
Here is one possibility: If your Control Panel, Overview and Drilldown are
elements that always behave the same, and have potential use in a variety of
applications, I would take the time (if you have it) to write them out as a
server control. You can then determine if it is best to slap the controls in
one page or have them in multiple page, with frames. You can even make it so
a user can choose which way they prefer to look at data, as creating the
frames version will simply be conquering the postback write of client side
JavaScript.

The main concern, in .NET, is making sure your UI and code are separate, and
that you are sticking to good software practices (encapsulation of code, et
al). While you can kludge ASP .NET by writing it like updated ASP, you will
end up with an unmanageable application.

Don't worry, we all went through the shock. I ended up moving to C#, from
VB, to make sure I was not confusing syntax with paradigm. When I first
started VB .NET, I was just trying to learn the new object model, not the
new methodology. If you are more into a C style language, learning .NET
concepts may be easier with VB .NET. I now can move back and forth between
VB .NET and C# with ease. I mess up the syntax every once in awhile, but VS
..NET is great at yelling at my "typos".

--
Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA
Author: ADO.NET and XML: ASP.NET on the Edge

************************************************** **************************
****
Think Outside the Box!
************************************************** **************************
****
"dj Bass" <sp******@hotmail.com> wrote in message
news:u8**************@tk2msftngp13.phx.gbl...
My situation is that I've been called to port asp pages to asp.net... with
port being defined as rewriting the code the .net way, rather than getting
it working in VS.net.

A lot of the work relies on a tree section down the left hand side, and
through your selection, the differing screens have a control panel, then an overview analyzing a database table, then a drill down into this table,
which currently is another frame.
+--------------------------------------------------------+
| tree | main
|
| | ooooooooooooooooooooooooooooooooo |
| | o control panel
o |
| | o
o |
| | ooooooooooooooooooooooooooooooooo |
| | o over view
o |
| | o
o |
| | o
o |
| | ooooooooooooooooooooooooooooooooo |
| | o detailed drill down o |
| | o
o |
| | o
o |
| | ooooooooooooooooooooooooooooooooo |
+--------------------------------------------------------+
there's no reason why tree and main cause problems since a button click
simply launches another screen, but when you get a situation where a load of records [overview] on a datagrid have selection, and you click on a button
on the [control panel], it's not possible to determine what records are
currently selected (i use a template column with check boxes to simulate
multiple selection), and therefore not posssible to do anything with those
selected columns.

Frames still are advantageous over DIV tags because frames are resizable,
catering for different resolutions and sizes that IE could be run at, where the DIV is a set value, whether absolute or relative, it's still fixed.

Is it worth migrating to a DIV style main page where the drill downs and
datagrid objects are all written within DIV tags, rather than frames and
hence, other objects?

Thanks for your input.
Daniel.

"Cowboy (Gregory A. Beamer)" <No************@comcast.netRemuvThis> wrote in message news:%2****************@TK2MSFTNGP12.phx.gbl...
Actually, the reasoning against frames is more complex:

1. Many users hate frames (mostly due to bad implementations that have
surfaced over the past few years0
2. You cannot bookmark an individual page with frames

I use client side script regularly in .NET. I do not normally use frames, but I do have some apps where they make sense, and I utilize frames in

those
apps.

The .NET server side controls simplify your life, where they make sense
(which is many, if not most, applications). If you chose not to use them, you write a lot of extra code. This is not necessarily bad; it is just
another way at approaching your development problem.

--
Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA
Author: ADO.NET and XML: ASP.NET on the Edge

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

************************************************** **************************
****
"dj Bass" <sp******@hotmail.com> wrote in message
news:uV*************@tk2msftngp13.phx.gbl...
simple, they don't like things that restrict the server-side
controls... and
when it comes to frames, you need client side stuff and that stuff's
up the
asp.net strategy.
right or wrong?



Nov 17 '05 #7

P: n/a
The Starter Kits are great tools. I am not sure reporting will work 100% for
this user, but it would be a nice way to spice up the app.

--
Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA
Author: ADO.NET and XML: ASP.NET on the Edge

************************************************** **************************
****
Think Outside the Box!
************************************************** **************************
****
"jim corey" <jh*****@yahoo.com> wrote in message
news:1c**************************@posting.google.c om...
And yet, if you go to the starter kits at www.asp.net, they have all
these report demos that use frames. Probably so you can see the
header and scroll the detail.
"dj Bass" <sp******@hotmail.com> wrote in message

news:<uV*************@tk2msftngp13.phx.gbl>...
simple, they don't like things that restrict the server-side controls... and when it comes to frames, you need client side stuff and that stuff's up the asp.net strategy.
right or wrong?

Nov 17 '05 #8

This discussion thread is closed

Replies have been disabled for this discussion.