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".
dj Bass said:
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.
message news:%
[email protected]...
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.
controls...
and up
the
