Design flow for Code-behind

[tshad]

Many (if not most) have said that code-behind is best if working in teams -
which does seem logical.

How do you deal with the flow of the work?

I have someone who is good at designing, but know nothing about ASP. He can
build the design of the pages in HTML with tables, labels, textboxes etc.

But then I would need to change them to ASP.net objects and write the code
to make the page work (normally I do this as I go - can't do this if I work
in a team environment).

Do you typically let the designer build the page first (aspx file) with the
html objects? Then later come along and change the ones you need to asp
objects and then build the code-behind page?

At this point, I assume you would work with both files and the designer
can't be working with the aspx page while you are working with the
code-behind. As you change html objects to asp objects you would need to
work with both files to add the references to the object in the code behind
page.

Also, how would the designer work with the design page while you are making
changes to the code-behind page as the page would probably fail while you
are making changes to the code-behind since the aspx file would refer to it.

Just trying to understand the logistics to this.

Thanks,

Tom

 

[Kevin Spencer]

Hi Tom,

Good question. The way we work it is, we use custom Server Controls for our
interface. Each Server Control renders a Div or a Table, with the active
elements inside. The Server Control also has a CSS class. The Server Control
itself contains HTML elements with no attributes or styles. Only the parent
container (div or table) has a CSS class.

Our designer can then work on an external CSS style sheet to provide the
layout and style of the Server Control. The CSS class determines how each
HTML element IN the Server Control will be rendered on the client, as each
HTML element in the Server Control is a child of the parent div or table.
You can do a heck of a lot with CSS besides style. You can use CSS
positoning to position the element anywhere in the page, regardless of its
physical location in the HTML. You can also define event behaviors (in terms
of style) with it. For example, a hyperlink could be underlined except when
the mouse os over it. A button could have 2 different background images, one
for onmouseout, and one for onmouseover.

This way, I don't have to think too much about how it's going to look, and
our designer doesn't have to know how it works on the back end.
Encapsulation is a beautiful thing!

We can also mix and match these Server Controls in various pages and
applications, and the CSS makes it look the way it should in whatever
environment it's in.

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
Neither a follower nor a lender be.

 

[Jeff Davis]

I have worked in situations where the designer created the UI first and then
passed the html on to the coder. This works ok, but can cause the coder to
wait on the designer.

I have also worked with a different system where we used controls that were
skinned. This approach requires a solid roadmap for each UI via written
requirements, but it allows the coder to create the code behind and the
controls while the designer works on the html that will be placed in the
skin control. The designer passes the html to the coder when it's complete
and the coder replaces the html control tags with the aspnet control tags in
the html when it gets put together. The custom control that loads up the
skin control simply uses the page.findcontrol("blah") function.

I don't think one is better than the other, but this is how I've dealt with
these challenges in the past.

HTH

 

[tshad]

Now I am confused.

I thought the main reason for code behind was to separate the design from
that and they could be worked on by different people at the same time.

But the styles here seems like one works on the page and then the other.

If that is the case, why could it not be done on the same page. You still
have the separation of code and design (code on top and design on the
bottom).

I have worked in situations where the designer created the UI first and
then passed the html on to the coder. This works ok, but can cause the
coder to wait on the designer.

This seems the most logical (but maybe not) way to do it. Without the
design, how does the coder test it?

I have also worked with a different system where we used controls that
were skinned.

What is that?

This approach requires a solid roadmap for each UI via written
requirements, but it allows the coder to create the code behind and the
controls while the designer works on the html that will be placed in the
skin control.

Again, wouldn't this be tough to test?

The designer passes the html to the coder when it's complete and the coder
replaces the html control tags with the aspnet control tags in the html
when it gets put together. The custom control that loads up the skin
control simply uses the page.findcontrol("blah") function.

This sounds similar to what I was talking about doing where the designer
just creates the page using standard HTML elements and then the coder
replaces the ones he wants with asp.net controls.

Tom

 

[tshad]

Hi Tom,

Good question. The way we work it is, we use custom Server Controls for
our interface. Each Server Control renders a Div or a Table, with the
active elements inside. The Server Control also has a CSS class. The
Server Control itself contains HTML elements with no attributes or styles.
Only the parent container (div or table) has a CSS class.

Do you have separate controls for each asp.net control?

Our designer can then work on an external CSS style sheet to provide the
layout and style of the Server Control. The CSS class determines how each
HTML element IN the Server Control will be rendered on the client, as each
HTML element in the Server Control is a child of the parent div or table.
You can do a heck of a lot with CSS besides style. You can use CSS
positoning to position the element anywhere in the page, regardless of its
physical location in the HTML. You can also define event behaviors (in
terms of style) with it. For example, a hyperlink could be underlined
except when the mouse os over it. A button could have 2 different
background images, one for onmouseout, and one for onmouseover.

Sounds complicated

 

[Kevin Spencer]

Hi Tom,

Do you have separate controls for each asp.net control?

I don't understand the question. Some of our Server Controls are Composite
Controls. Some are simply Controls that render their own HTML.

Sounds complicated

Using CSS? Not complicated for a good HTML designer. I couldn't do it, but
he can! From my point of view as a developer, it's not at all complicated.
It's easy, because I have less HTML to work with. It actually simplifies the
presentation layer quite a bit.

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
Neither a follower nor a lender be.

 

[Jeff Davis]

This seems the most logical (but maybe not) way to do it. Without the

design, how does the coder test it?

The coder creates a simplet interface in the skin with the controls defined.
These allow him to test his custom controls. He simply replaces the test
interface with the HTML the designer gives him and makes his changes.

What is that?

It's a system that loads up the look of the application (a skin). Basically
you dynamically load a control based on the path to another .ascx file. You
can search the web for examples of how to skin controls.

Again, wouldn't this be tough to test?

It's not hard to test because the coder will be working with test html in
the skin control.

This sounds similar to what I was talking about doing where the designer
just creates the page using standard HTML elements and then the coder
replaces the ones he wants with asp.net controls.

It is the same. I think for simplicity sake I would suggest working this
way. You just have to make sure the designer stays ahead of the coder in
order to keep you both busy.

HTH

 

[tshad]

Hi Tom,


I don't understand the question. Some of our Server Controls are Composite
Controls. Some are simply Controls that render their own HTML.

Well, if you are going to use a asp:datagrid or asp:datalist, how would you
do that with a custom control? Or asp:textbox?

If you don't have the actual asp control, how would you test the code?

Tom

 

[Kevin Spencer]

Well, if you are going to use a asp:datagrid or asp:datalist, how would

you do that with a custom control? Or asp:textbox?

Composite Control.

I should mention that almost none of our Custom Controls render a single
HTML element. Usually, for example, with a form, the form fields are all
part of the same form, and therefore, are created as a single Control. In
cases like this, I often build the Control as a single unit, rendering its
own HTML, as this is more efficient on the server side than incorporating a
bunch of ASP.Net Controls that include a lot of code that will never be used
in the context of the Control we're building. Occasionally, we use ASP.Net
Controls in a Composite Control, but not often.

Microsoft was kind enough to create a number of individual HTML elements as
separate Controls, but they were also wise enough to allow and encourage the
developer to create his/her own. I believe that Microsoft intended for
developers (who have the necessary skill) to create their own. I find it
hard to believe that Microsoft intended these small Controls for use in
large-scale applications. Too much overhead. Creating a custom Server
Control is not difficult. The nicest thing about it is reusability.

I often think of programming in the same way as carpentry. Microsoft has
provided a nice set of raw components - 2X4s, bricks, nails, plywood, etc.
But if you had entire walls pre-built that you could use instead of building
them from scratch, wouldn't you? An ASP.Net Server Control is like a 2X4. A
wall is a bunch of 2X4s with nails and plywood all assembled as a unit. I
build walls, and then put them together. Later, if I need a wall of
dimensions that I've already created, I just use it. No need to "build it
from scratch" again. And if you design the walls with reusability in mind,
that is a frequent occurrence.

If you don't have the actual asp control, how would you test the code?

I don't understand the question. The only difference between the Controls I
create an Microsoft's is the prefix used in the template. You can even
create custom Designers so that you can see the Controls visually in the
VS.Net IDE.

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
Neither a follower nor a lender be.

 

[Showjumper]

Very interesting approach Kevin. I like this idea - something to try next
time. I have a question about your from server control. This control for
example renders all the textboxes and button neeedd for a form. Since you
are rendering the html directly and not making a composite control, i assume
implement all the postback handling features too? But doesnt doing it this
slow development at all since you have to spend perhaps mpre time on a
control instead of just dropping controls onto a page?

Ashok

 

[Kevin Spencer]

Hi Ashok,

Since you
are rendering the html directly and not making a composite control, i
assume
implement all the postback handling features too?

In cases where it is needed, yes.

But doesnt doing it this
slow development at all since you have to spend perhaps mpre time on a
control instead of just dropping controls onto a page?

Good question. Actually, that is part of the OOP paradigm. The OOP paradigm
concentrates on more work in the short run developing classes, and less time
in the long run, if you develop those classes properly. Once a class is
properly developed, it is re-usable. If you design your apps well, spend
some time on architecture issues, you end up designing less and less classes
as you proceed. In a sense, you are creating a custom "class library" of
reusable objects. Design your classes with the maximum benefits available
from Encapsulation, Abstraction, Inheritance, and Polymorphism, and you're
all set.

This is actually why the ASP.Net Server Controls are so small. Since they
can be used in any situation, they are in the smallest HTML units that can
be created - individual HTML form elements and objects. But again, Microsoft
developed these controls with no restrictions on their use, so that they
could be used in ANY type of ASP.Net app. . In a real-life situation, one
would have certain parameters for most of one's apps. One finds similarities
between different functionality, and even groups of HTML objects, such as
form fields. For example, one might need a login page in several apps. By
developing a generic login procedure, and a fairly simple Server Control
with 1 text box and one password box, one now has a Login Control. This
Control can now be re-used in your current project, and used in any app that
requires a User Name and Password login.

It's important to keep in mind the requirements for what one builds. In this
case, keeping in mind Microsoft's requirements for their product helps.
Microsoft's requirements for the Server Controls they created is that they
must be small and extensible enough to be mixed and matched in virtually ANY
situation. But unless you develop development tools for a wide variety of
developers, you can narrow down your own requirements to what your apps are
going to need, and design with that in mind.

The real time-killer is when you find that you need similar functionality in
a web app, and you go into another project and have to translate all the
complexity of these separate Controls interacting into the new app. Instead,
I just grab a previously-developed Server Control and drop it into my
project. I design all my Server Controls with no external Control
dependencies (that is, they may connect to a DB, or some server-side data
source, but are not dependent upon any other UI elements). This way they can
easily be dropped into another project, or another part of the same project.

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
Neither a follower nor a lender be.

 

[Showjumper]

As for the header, footer elements of a page, are you using server controls
to handle this too? And then maybe jsut setting some image paths etc to
render the header.

Thanks
Ashok

 

[Kevin Spencer]

As for the header, footer elements of a page, are you using server

controls
to handle this too? And then maybe jsut setting some image paths etc to
render the header.

If by "header" you are referring to visible content at the top of the page
(versus HTTP headers), yes, we sure do. We have one Server Control for the
top, one ServerControl that goes at the left (Menu), and one for the bottom.
They are all styled and positioned using CSS.

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
Neither a follower nor a lender be.

 

[tshad]

If by "header" you are referring to visible content at the top of the page
(versus HTTP headers), yes, we sure do. We have one Server Control for the
top, one ServerControl that goes at the left (Menu), and one for the
bottom. They are all styled and positioned using CSS.

What do you mean positioned using CSS? No tables - absolute positioning?

I set up controls for headers and footers that have part of a table
definition in the headers control and the bottom part of the footer control.
Not sure if that is a good way to set it up, but I was told by others that
that was a better way than include files. Not really sure why. The only
difference (other than sytax) seems to be the fact that I have to register
them on each page:

<%@ Register TagPrefix="fts" TAgName="header"
src="..\includes\defaultHeaders.ascx" %>
<%@ Register TagPrefix="fts" TAgName="footer"
src="..\includes\staffingFooters.ascx" %>

then I put:

<fts:header id=ctl1 runat="Server" />

after the <body> tag and another one for the footer at the bottom of the
page.

I am not really sure why that is better that just doing:

<!-- #include file="..\includes\defaultHeaders.inc" -->

Tom

 

[Showjumper]

Are you using absolute pos via top and left or positioning via margins and
paddings and floats? Up till now i have encapulsated headers, footers, and
menus in user controls and my programming logic (db stuff etc) into classes
in the project but havent made things reusable across multiple applications
before. I think this will be next approach. Also one other question, since
you are using this server control approach, are you using base pages classes
at all? And do you use a control to handle the contentthat varies from page
to page or is that just a regukar div and not a server control?

Thanks very much for the info on your approach. I appreciate it very much.

Ashok

 

[Kevin Spencer]

Hi Tom,

What do you mean positioned using CSS? No tables - absolute positioning?

Sure do. Positioning is one aspect of presentation/layout. Now, you could do
positioning using tables, but that adds a layer of complexity to the HTML
code in the template. So, we just put the Server Control in the page and let
the HTML designer position it.

I am not really sure why that is better that just doing:

<!-- #include file="..\includes\defaultHeaders.inc" -->

The most important reason: Server-side includes for UI elements is not OOP.
OTOH, I don't want to get involved with your controversy with Alan about the
virtues of using OOP technique in an OOP application, but that's how I do
it! ;-)

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
Neither a follower nor a lender be.

 

[Kevin Spencer]

Hi Showjumper,

Are you using absolute pos via top and left or positioning via margins and
paddings and floats?

I'm just the developer. I did ask our HTML designer, David Stiller, and he
replied:

"I know why he's asking it, too. This is one of the hot topics in the webdev
community lately, due to all the hacks required to get true absolute
positioning to work successfully in all the relevant browsers.

If I read between the lines, I believe the person is asking what our overall
layout procedure is -- what CSS mechanism we use to position the masthead in
relation to the navigation, etc. The answer to that hypothetical scenario
depends on the site's visual design. Floats tend to present the greatest
flexibility, but in IE they obscure certain onMouseOver triggers. Either
approach would be fine (note the brilliance of CSSZenGarden.com) and I have
successfully laid out many sites with either."

Also one other question, since
you are using this server control approach, are you using base pages
classes
at all? And do you use a control to handle the contentthat varies from
page
to page or is that just a regukar div and not a server control?

Sound like 2 questions to me! ;-)

Yes, we use a base Page class and inherit it in all of our Pages. It handles
background tasks that are common throughout the app, such as identifying the
page (for the menu), setting no-cache headers, etc.

The second "part" of the question is not clear to me. Any content that is
not dynamic is not a Server Control, if I understand correctly.

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
Neither a follower nor a lender be.

 

[Showjumper]

Thank you so much Kevin. The "Second question" - i was wondering if maybe
you use a content control perhaps that get its content from an external
source like an xml file - thats what i was thinking when i typed. But you
answered al my questions and gave me some stuff to think on and a new
approach to try. Appreciate it very much.
Ashok