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

Design flow for Code-behind

P: n/a
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
Nov 19 '05 #1
Share this Question
Share on Google+
17 Replies


P: n/a
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.

"tshad" <ts**********@ftsolutions.com> wrote in message
news:eY**************@TK2MSFTNGP12.phx.gbl...
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

Nov 19 '05 #2

P: n/a
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

--
Jeff Davis
..NET Application Developer
re*******************@hotmail.com
---------------------------------------------------------------
Life is 90% what happens to you and 10% how you react.
"tshad" <ts**********@ftsolutions.com> wrote in message
news:eY**************@TK2MSFTNGP12.phx.gbl...
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

Nov 19 '05 #3

P: n/a
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).

"Jeff Davis" <je************@hotmail.com> wrote in message
news:%2****************@TK2MSFTNGP12.phx.gbl...
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

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

HTH

--
Jeff Davis
.NET Application Developer
remove_je************@hotmail.com
---------------------------------------------------------------
Life is 90% what happens to you and 10% how you react.
"tshad" <ts**********@ftsolutions.com> wrote in message
news:eY**************@TK2MSFTNGP12.phx.gbl...
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


Nov 19 '05 #4

P: n/a
"Kevin Spencer" <ke***@DIESPAMMERSDIEtakempis.com> wrote in message
news:%2****************@TK2MSFTNGP14.phx.gbl...
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
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.

"tshad" <ts**********@ftsolutions.com> wrote in message
news:eY**************@TK2MSFTNGP12.phx.gbl...
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


Nov 19 '05 #5

P: n/a
> 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.
I have also worked with a different system where we used controls that
were skinned.


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
--
Jeff Davis
..NET Application Developer
re*******************@hotmail.com
---------------------------------------------------------------
Life is 90% what happens to you and 10% how you react.

"tshad" <ts**********@ftsolutions.com> wrote in message
news:%2****************@TK2MSFTNGP10.phx.gbl... 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).

"Jeff Davis" <je************@hotmail.com> wrote in message
news:%2****************@TK2MSFTNGP12.phx.gbl...
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

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

HTH

--
Jeff Davis
.NET Application Developer
re*******************@hotmail.com
---------------------------------------------------------------
Life is 90% what happens to you and 10% how you react.
"tshad" <ts**********@ftsolutions.com> wrote in message
news:eY**************@TK2MSFTNGP12.phx.gbl...
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



Nov 19 '05 #6

P: n/a
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.

"tshad" <ts**********@ftsolutions.com> wrote in message
news:%2****************@TK2MSFTNGP10.phx.gbl... "Kevin Spencer" <ke***@DIESPAMMERSDIEtakempis.com> wrote in message
news:%2****************@TK2MSFTNGP14.phx.gbl...
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
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.

"tshad" <ts**********@ftsolutions.com> wrote in message
news:eY**************@TK2MSFTNGP12.phx.gbl...
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



Nov 19 '05 #7

P: n/a

"Kevin Spencer" <ke***@DIESPAMMERSDIEtakempis.com> wrote in message
news:u8**************@tk2msftngp13.phx.gbl...
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.


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
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.

"tshad" <ts**********@ftsolutions.com> wrote in message
news:%2****************@TK2MSFTNGP10.phx.gbl...
"Kevin Spencer" <ke***@DIESPAMMERSDIEtakempis.com> wrote in message
news:%2****************@TK2MSFTNGP14.phx.gbl...
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
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.

"tshad" <ts**********@ftsolutions.com> wrote in message
news:eY**************@TK2MSFTNGP12.phx.gbl...
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



Nov 19 '05 #8

P: n/a
> 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.

"tshad" <ts**********@ftsolutions.com> wrote in message
news:Or**************@TK2MSFTNGP14.phx.gbl...
"Kevin Spencer" <ke***@DIESPAMMERSDIEtakempis.com> wrote in message
news:u8**************@tk2msftngp13.phx.gbl...
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.


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
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.

"tshad" <ts**********@ftsolutions.com> wrote in message
news:%2****************@TK2MSFTNGP10.phx.gbl...
"Kevin Spencer" <ke***@DIESPAMMERSDIEtakempis.com> wrote in message
news:%2****************@TK2MSFTNGP14.phx.gbl...
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

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.

"tshad" <ts**********@ftsolutions.com> wrote in message
news:eY**************@TK2MSFTNGP12.phx.gbl...
> 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
>



Nov 19 '05 #9

P: n/a
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" <ke***@DIESPAMMERSDIEtakempis.com> wrote in message
news:OF**************@tk2msftngp13.phx.gbl...
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.

"tshad" <ts**********@ftsolutions.com> wrote in message
news:Or**************@TK2MSFTNGP14.phx.gbl...

"Kevin Spencer" <ke***@DIESPAMMERSDIEtakempis.com> wrote in message
news:u8**************@tk2msftngp13.phx.gbl...
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.

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

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.

"tshad" <ts**********@ftsolutions.com> wrote in message
news:%2****************@TK2MSFTNGP10.phx.gbl...
"Kevin Spencer" <ke***@DIESPAMMERSDIEtakempis.com> wrote in message
news:%2****************@TK2MSFTNGP14.phx.gbl...
> 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

> 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.
>
> "tshad" <ts**********@ftsolutions.com> wrote in message
> news:eY**************@TK2MSFTNGP12.phx.gbl...
>> 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
>>
>
>




Nov 19 '05 #10

P: n/a
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" <sh*******@grkjashdjkf.com> wrote in message
news:uu****************@TK2MSFTNGP12.phx.gbl... 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" <ke***@DIESPAMMERSDIEtakempis.com> wrote in message
news:OF**************@tk2msftngp13.phx.gbl...
> 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.

"tshad" <ts**********@ftsolutions.com> wrote in message
news:Or**************@TK2MSFTNGP14.phx.gbl...
>
> "Kevin Spencer" <ke***@DIESPAMMERSDIEtakempis.com> wrote in message
> news:u8**************@tk2msftngp13.phx.gbl...
>> 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. >
> 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
>>
>>> 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.
>>
>> "tshad" <ts**********@ftsolutions.com> wrote in message
>> news:%2****************@TK2MSFTNGP10.phx.gbl...
>>> "Kevin Spencer" <ke***@DIESPAMMERSDIEtakempis.com> wrote in message
>>> news:%2****************@TK2MSFTNGP14.phx.gbl...
>>>> 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
>>>
>>>> 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.
>>>>
>>>> "tshad" <ts**********@ftsolutions.com> wrote in message
>>>> news:eY**************@TK2MSFTNGP12.phx.gbl...
>>>>> 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
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>



Nov 19 '05 #11

P: n/a
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" <ke***@DIESPAMMERSDIEtakempis.com> wrote in message
news:e%******************@TK2MSFTNGP14.phx.gbl...
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" <sh*******@grkjashdjkf.com> wrote in message
news:uu****************@TK2MSFTNGP12.phx.gbl...
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" <ke***@DIESPAMMERSDIEtakempis.com> wrote in message
news:OF**************@tk2msftngp13.phx.gbl...
> 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.

"tshad" <ts**********@ftsolutions.com> wrote in message
news:Or**************@TK2MSFTNGP14.phx.gbl...
>
> "Kevin Spencer" <ke***@DIESPAMMERSDIEtakempis.com> wrote in message
> news:u8**************@tk2msftngp13.phx.gbl...
>> 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.
>
> 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
>>
>>> 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.
>>
>> "tshad" <ts**********@ftsolutions.com> wrote in message
>> news:%2****************@TK2MSFTNGP10.phx.gbl...
>>> "Kevin Spencer" <ke***@DIESPAMMERSDIEtakempis.com> wrote in message
>>> news:%2****************@TK2MSFTNGP14.phx.gbl...
>>>> 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
>>>
>>>> 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.
>>>>
>>>> "tshad" <ts**********@ftsolutions.com> wrote in message
>>>> news:eY**************@TK2MSFTNGP12.phx.gbl...
>>>>> 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
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>




Nov 19 '05 #12

P: n/a
> 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.
"Showjumper" <sh*******@grkjashdjkf.com> wrote in message
news:ul**************@tk2msftngp13.phx.gbl... 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" <ke***@DIESPAMMERSDIEtakempis.com> wrote in message
news:e%******************@TK2MSFTNGP14.phx.gbl...
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" <sh*******@grkjashdjkf.com> wrote in message
news:uu****************@TK2MSFTNGP12.phx.gbl...
> 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" <ke***@DIESPAMMERSDIEtakempis.com> wrote in message
> news:OF**************@tk2msftngp13.phx.gbl...
>> > 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.
>>
>> "tshad" <ts**********@ftsolutions.com> wrote in message
>> news:Or**************@TK2MSFTNGP14.phx.gbl...
>> >
>> > "Kevin Spencer" <ke***@DIESPAMMERSDIEtakempis.com> wrote in message
>> > news:u8**************@tk2msftngp13.phx.gbl...
>> >> 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.
>> >
>> > 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
>> >>
>> >>> 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.
>> >>
>> >> "tshad" <ts**********@ftsolutions.com> wrote in message
>> >> news:%2****************@TK2MSFTNGP10.phx.gbl...
>> >>> "Kevin Spencer" <ke***@DIESPAMMERSDIEtakempis.com> wrote in
>> >>> message
>> >>> news:%2****************@TK2MSFTNGP14.phx.gbl...
>> >>>> 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
>> >>>
>> >>>> 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.
>> >>>>
>> >>>> "tshad" <ts**********@ftsolutions.com> wrote in message
>> >>>> news:eY**************@TK2MSFTNGP12.phx.gbl...
>> >>>>> 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
>> >>>>>
>> >>>>
>> >>>>
>> >>>
>> >>>
>> >>
>> >>
>> >
>> >
>>
>>
>>
>
>
>



Nov 19 '05 #13

P: n/a
"Kevin Spencer" <ke***@DIESPAMMERSDIEtakempis.com> wrote in message
news:eD**************@TK2MSFTNGP15.phx.gbl...
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.


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
--
HTH,

Kevin Spencer
Microsoft MVP
.Net Developer
Neither a follower nor a lender be.
"Showjumper" <sh*******@grkjashdjkf.com> wrote in message
news:ul**************@tk2msftngp13.phx.gbl...
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" <ke***@DIESPAMMERSDIEtakempis.com> wrote in message
news:e%******************@TK2MSFTNGP14.phx.gbl...
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" <sh*******@grkjashdjkf.com> wrote in message
news:uu****************@TK2MSFTNGP12.phx.gbl...
> 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" <ke***@DIESPAMMERSDIEtakempis.com> wrote in message
> news:OF**************@tk2msftngp13.phx.gbl...
>> > 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.
>>
>> "tshad" <ts**********@ftsolutions.com> wrote in message
>> news:Or**************@TK2MSFTNGP14.phx.gbl...
>> >
>> > "Kevin Spencer" <ke***@DIESPAMMERSDIEtakempis.com> wrote in message
>> > news:u8**************@tk2msftngp13.phx.gbl...
>> >> 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.
>> >
>> > 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
>> >>
>> >>> 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.
>> >>
>> >> "tshad" <ts**********@ftsolutions.com> wrote in message
>> >> news:%2****************@TK2MSFTNGP10.phx.gbl...
>> >>> "Kevin Spencer" <ke***@DIESPAMMERSDIEtakempis.com> wrote in
>> >>> message
>> >>> news:%2****************@TK2MSFTNGP14.phx.gbl...
>> >>>> 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
>> >>>
>> >>>> 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.
>> >>>>
>> >>>> "tshad" <ts**********@ftsolutions.com> wrote in message
>> >>>> news:eY**************@TK2MSFTNGP12.phx.gbl...
>> >>>>> 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
>> >>>>>
>> >>>>
>> >>>>
>> >>>
>> >>>
>> >>
>> >>
>> >
>> >
>>
>>
>>
>
>
>



Nov 19 '05 #14

P: n/a
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" <ke***@DIESPAMMERSDIEtakempis.com> wrote in message
news:eD**************@TK2MSFTNGP15.phx.gbl...
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.
"Showjumper" <sh*******@grkjashdjkf.com> wrote in message
news:ul**************@tk2msftngp13.phx.gbl...
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" <ke***@DIESPAMMERSDIEtakempis.com> wrote in message
news:e%******************@TK2MSFTNGP14.phx.gbl...
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" <sh*******@grkjashdjkf.com> wrote in message
news:uu****************@TK2MSFTNGP12.phx.gbl...
> 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" <ke***@DIESPAMMERSDIEtakempis.com> wrote in message
> news:OF**************@tk2msftngp13.phx.gbl...
>> > 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.
>>
>> "tshad" <ts**********@ftsolutions.com> wrote in message
>> news:Or**************@TK2MSFTNGP14.phx.gbl...
>> >
>> > "Kevin Spencer" <ke***@DIESPAMMERSDIEtakempis.com> wrote in message >> > news:u8**************@tk2msftngp13.phx.gbl...
>> >> 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.
>> >
>> > 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
>> >>
>> >>> 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.
>> >>
>> >> "tshad" <ts**********@ftsolutions.com> wrote in message
>> >> news:%2****************@TK2MSFTNGP10.phx.gbl...
>> >>> "Kevin Spencer" <ke***@DIESPAMMERSDIEtakempis.com> wrote in
>> >>> message
>> >>> news:%2****************@TK2MSFTNGP14.phx.gbl...
>> >>>> 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
>> >>>
>> >>>> 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.
>> >>>>
>> >>>> "tshad" <ts**********@ftsolutions.com> wrote in message
>> >>>> news:eY**************@TK2MSFTNGP12.phx.gbl...
>> >>>>> 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
>> >>>>>
>> >>>>
>> >>>>
>> >>>
>> >>>
>> >>
>> >>
>> >
>> >
>>
>>
>>
>
>
>




Nov 19 '05 #15

P: n/a
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.
"tshad" <ts**********@ftsolutions.com> wrote in message
news:%2***************@TK2MSFTNGP10.phx.gbl... "Kevin Spencer" <ke***@DIESPAMMERSDIEtakempis.com> wrote in message
news:eD**************@TK2MSFTNGP15.phx.gbl...
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.


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

--
HTH,

Kevin Spencer
Microsoft MVP
.Net Developer
Neither a follower nor a lender be.
"Showjumper" <sh*******@grkjashdjkf.com> wrote in message
news:ul**************@tk2msftngp13.phx.gbl...
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" <ke***@DIESPAMMERSDIEtakempis.com> wrote in message
news:e%******************@TK2MSFTNGP14.phx.gbl...
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" <sh*******@grkjashdjkf.com> wrote in message
news:uu****************@TK2MSFTNGP12.phx.gbl...
> 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" <ke***@DIESPAMMERSDIEtakempis.com> wrote in message
> news:OF**************@tk2msftngp13.phx.gbl...
>> > 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.
>>
>> "tshad" <ts**********@ftsolutions.com> wrote in message
>> news:Or**************@TK2MSFTNGP14.phx.gbl...
>> >
>> > "Kevin Spencer" <ke***@DIESPAMMERSDIEtakempis.com> wrote in
>> > message
>> > news:u8**************@tk2msftngp13.phx.gbl...
>> >> 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.
>> >
>> > 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
>> >>
>> >>> 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.
>> >>
>> >> "tshad" <ts**********@ftsolutions.com> wrote in message
>> >> news:%2****************@TK2MSFTNGP10.phx.gbl...
>> >>> "Kevin Spencer" <ke***@DIESPAMMERSDIEtakempis.com> wrote in
>> >>> message
>> >>> news:%2****************@TK2MSFTNGP14.phx.gbl...
>> >>>> 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
>> >>>
>> >>>> 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.
>> >>>>
>> >>>> "tshad" <ts**********@ftsolutions.com> wrote in message
>> >>>> news:eY**************@TK2MSFTNGP12.phx.gbl...
>> >>>>> 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
>> >>>>>
>> >>>>
>> >>>>
>> >>>
>> >>>
>> >>
>> >>
>> >
>> >
>>
>>
>>
>
>
>




Nov 19 '05 #16

P: n/a
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" <sh*******@grkjashdjkf.com> wrote in message
news:ON*************@TK2MSFTNGP15.phx.gbl... 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" <ke***@DIESPAMMERSDIEtakempis.com> wrote in message
news:eD**************@TK2MSFTNGP15.phx.gbl...
> 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.
"Showjumper" <sh*******@grkjashdjkf.com> wrote in message
news:ul**************@tk2msftngp13.phx.gbl...
> 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" <ke***@DIESPAMMERSDIEtakempis.com> wrote in message
> news:e%******************@TK2MSFTNGP14.phx.gbl...
>> 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" <sh*******@grkjashdjkf.com> wrote in message
>> news:uu****************@TK2MSFTNGP12.phx.gbl...
>> > 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" <ke***@DIESPAMMERSDIEtakempis.com> wrote in message
>> > news:OF**************@tk2msftngp13.phx.gbl...
>> >> > 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.
>> >>
>> >> "tshad" <ts**********@ftsolutions.com> wrote in message
>> >> news:Or**************@TK2MSFTNGP14.phx.gbl...
>> >> >
>> >> > "Kevin Spencer" <ke***@DIESPAMMERSDIEtakempis.com> wrote in message >> >> > news:u8**************@tk2msftngp13.phx.gbl...
>> >> >> 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.
>> >> >
>> >> > 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
>> >> >>
>> >> >>> 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.
>> >> >>
>> >> >> "tshad" <ts**********@ftsolutions.com> wrote in message
>> >> >> news:%2****************@TK2MSFTNGP10.phx.gbl...
>> >> >>> "Kevin Spencer" <ke***@DIESPAMMERSDIEtakempis.com> wrote in
>> >> >>> message
>> >> >>> news:%2****************@TK2MSFTNGP14.phx.gbl...
>> >> >>>> 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
>> >> >>>
>> >> >>>> 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.
>> >> >>>>
>> >> >>>> "tshad" <ts**********@ftsolutions.com> wrote in message
>> >> >>>> news:eY**************@TK2MSFTNGP12.phx.gbl...
>> >> >>>>> 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
>> >> >>>>>
>> >> >>>>
>> >> >>>>
>> >> >>>
>> >> >>>
>> >> >>
>> >> >>
>> >> >
>> >> >
>> >>
>> >>
>> >>
>> >
>> >
>> >
>>
>>
>>
>
>
>



Nov 19 '05 #17

P: n/a
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
"Kevin Spencer" <ke***@DIESPAMMERSDIEtakempis.com> wrote in message
news:%2****************@TK2MSFTNGP14.phx.gbl...
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" <sh*******@grkjashdjkf.com> wrote in message
news:ON*************@TK2MSFTNGP15.phx.gbl...
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" <ke***@DIESPAMMERSDIEtakempis.com> wrote in message
news:eD**************@TK2MSFTNGP15.phx.gbl...
> 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.
"Showjumper" <sh*******@grkjashdjkf.com> wrote in message
news:ul**************@tk2msftngp13.phx.gbl...
> 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" <ke***@DIESPAMMERSDIEtakempis.com> wrote in message
> news:e%******************@TK2MSFTNGP14.phx.gbl...
>> 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" <sh*******@grkjashdjkf.com> wrote in message
>> news:uu****************@TK2MSFTNGP12.phx.gbl...
>> > 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" <ke***@DIESPAMMERSDIEtakempis.com> wrote in message >> > news:OF**************@tk2msftngp13.phx.gbl...
>> >> > 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.
>> >>
>> >> "tshad" <ts**********@ftsolutions.com> wrote in message
>> >> news:Or**************@TK2MSFTNGP14.phx.gbl...
>> >> >
>> >> > "Kevin Spencer" <ke***@DIESPAMMERSDIEtakempis.com> wrote in

message
>> >> > news:u8**************@tk2msftngp13.phx.gbl...
>> >> >> 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.
>> >> >
>> >> > 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
>> >> >>
>> >> >>> 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.
>> >> >>
>> >> >> "tshad" <ts**********@ftsolutions.com> wrote in message
>> >> >> news:%2****************@TK2MSFTNGP10.phx.gbl...
>> >> >>> "Kevin Spencer" <ke***@DIESPAMMERSDIEtakempis.com> wrote in
>> >> >>> message
>> >> >>> news:%2****************@TK2MSFTNGP14.phx.gbl...
>> >> >>>> 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
>> >> >>>
>> >> >>>> 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.
>> >> >>>>
>> >> >>>> "tshad" <ts**********@ftsolutions.com> wrote in message
>> >> >>>> news:eY**************@TK2MSFTNGP12.phx.gbl...
>> >> >>>>> 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
>> >> >>>>>
>> >> >>>>
>> >> >>>>
>> >> >>>
>> >> >>>
>> >> >>
>> >> >>
>> >> >
>> >> >
>> >>
>> >>
>> >>
>> >
>> >
>> >
>>
>>
>>
>
>
>




Nov 19 '05 #18

This discussion thread is closed

Replies have been disabled for this discussion.