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
17  2661 
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
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
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
"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
> 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
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
"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
> 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
>
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
>>
>
>
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
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>
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
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>
> 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
>> >>>>>
>> >>>>
>> >>>>
>> >>>
>> >>>
>> >>
>> >>
>> >
>> >
>>
>>
>>
>
>
>
"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
>> >>>>>
>> >>>>
>> >>>>
>> >>>
>> >>>
>> >>
>> >>
>> >
>> >
>>
>>
>>
>
>
>
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
>> >>>>>
>> >>>>
>> >>>>
>> >>>
>> >>>
>> >>
>> >>
>> >
>> >
>>
>>
>>
>
>
>
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
>> >>>>>
>> >>>>
>> >>>>
>> >>>
>> >>>
>> >>
>> >>
>> >
>> >
>>
>>
>>
>
>
>
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
>> >> >>>>>
>> >> >>>>
>> >> >>>>
>> >> >>>
>> >> >>>
>> >> >>
>> >> >>
>> >> >
>> >> >
>> >>
>> >>
>> >>
>> >
>> >
>> >
>>
>>
>>
>
>
>
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
>> >> >>>>>
>> >> >>>>
>> >> >>>>
>> >> >>>
>> >> >>>
>> >> >>
>> >> >>
>> >> >
>> >> >
>> >>
>> >>
>> >>
>> >
>> >
>> >
>>
>>
>>
>
>
>
This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: Eric Veltman |
last post by:
Hello everyone,
I've posted this question before, but got no answer,
so I'll try to reformulate the question, maybe it helps :-)
By the way, this is not intended as the start of an ASP.NET...
|
by: Xenophobe |
last post by:
I'm having a brain freeze on how to go about creating the logic for
evenly distributing a group of items in rotation through multiple
iterations. I'm particularly looking for logic flow help and...
|
by: Houston |
last post by:
I am hosting a lake party based on the Survivor theme. Only its not really a
party, we actually play games like volly ball, egg toss, ratf race etc. I
have created an online signup form and so far...
|
by: Jacob Crossley |
last post by:
Please tell me there is a way to prevent this annoyance ; - )
I'm into writing perfectly indented html, but the .net dev environment is
being overzealous and messing up my html formatting.
for...
|
by: onyxring |
last post by:
I've been building custom web controls in C# with VS2005. Currently I'm
looking into adding design-time functionality and have reached a point where
I need to generate code in the page the custom...
|
by: Dunc |
last post by:
I'm pre-compiling and deploying my ASP.NET 2.0 project to a development
server (I've checked "Allow pre-compiled site to be updateable") where
a designer is modifying the aspx pages. Occasionally,...
|
by: Ronald S. Cook |
last post by:
We're designing a Windows application. On a given form (let's say edit
customer), there would be a list of all the (let's say cars) that the
customer owns. We want the user to be able to click on...
|
by: Pallav singh |
last post by:
Hi All
i am getting Error while writing following code for state design
Pattern
kindly let me know How to Correct this Error ??
Thanks
Pallav Singh
...
|
by: emmanuelkatto |
last post by:
Hi All, I am Emmanuel katto from Uganda. I want to ask what challenges you've faced while migrating a website to cloud.
Please let me know.
Thanks!
Emmanuel
|
by: BarryA |
last post by:
What are the essential steps and strategies outlined in the Data Structures and Algorithms (DSA) roadmap for aspiring data scientists? How can individuals effectively utilize this roadmap to progress...
|
by: nemocccc |
last post by:
hello, everyone, I want to develop a software for my android phone for daily needs, any suggestions?
|
by: Sonnysonu |
last post by:
This is the data of csv file
1 2 3
1 2 3
1 2 3
1 2 3
2 3
2 3
3
the lengths should be different i have to store the data by column-wise with in the specific length.
suppose the i have to...
|
by: Hystou |
last post by:
There are some requirements for setting up RAID:
1. The motherboard and BIOS support RAID configuration.
2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...
|
by: marktang |
last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However,...
|
by: jinu1996 |
last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven...
|
by: Hystou |
last post by:
Overview:
Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows...
|
by: tracyyun |
last post by:
Dear forum friends,
With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each...
| |
