472,378 Members | 1,334 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 472,378 software developers and data experts.

ASP.NET/OOP and adding specific logic to controls in overriden methods

I have an odd business requirement and I think that the implementation
is not correct in the terms of OOP development. Any help on the
concepts would be very appreciated!

We currently have a custom Page object which is derived from the base
Page object. We also have custom controls that derive from a base
class that performs custom drawing and inherits from our own
IOurControl interface. There is also a special caching layer in the
mix that retrieves object information from a database/application
cache based on a control id (this is a simplified explanation).

What would be ideal in the eyes of my boss would be that each of our
custom objects retrieves data from the cache on its OnInit event and
draws the content on its OnRender event so our custom page doesn't
have to iterate the custom controls and fire methods accordingly.

Although I understand his reasoning for wanting to do so, I believe
that the methods for getting data and setting content should be added
to the controls IOurControl interface and that our custom page object
should be responsible for looping its child controls and invoking
those methods as needed. His way requires the developers of new
controls to have to know ahead of time where to place specific code or
the controls won't function properly when used in context with our
Page. I also entertained using abstract methods in the control's base
class but since the implementation would be different for each
control, it seemed pointless.

Is my boss' way the best way to implement the solution as far as OOP
concepts go, is my suggestion the best way or is there a better way of
doing so?

Feb 27 '07 #1
12 1494
Howdy,

I have just one question ;-) What's the company name so i would know where
not to apply ;-)
--
Milosz

"Bob Jones" wrote:
I have an odd business requirement and I think that the implementation
is not correct in the terms of OOP development. Any help on the
concepts would be very appreciated!

We currently have a custom Page object which is derived from the base
Page object. We also have custom controls that derive from a base
class that performs custom drawing and inherits from our own
IOurControl interface. There is also a special caching layer in the
mix that retrieves object information from a database/application
cache based on a control id (this is a simplified explanation).

What would be ideal in the eyes of my boss would be that each of our
custom objects retrieves data from the cache on its OnInit event and
draws the content on its OnRender event so our custom page doesn't
have to iterate the custom controls and fire methods accordingly.

Although I understand his reasoning for wanting to do so, I believe
that the methods for getting data and setting content should be added
to the controls IOurControl interface and that our custom page object
should be responsible for looping its child controls and invoking
those methods as needed. His way requires the developers of new
controls to have to know ahead of time where to place specific code or
the controls won't function properly when used in context with our
Page. I also entertained using abstract methods in the control's base
class but since the implementation would be different for each
control, it seemed pointless.

Is my boss' way the best way to implement the solution as far as OOP
concepts go, is my suggestion the best way or is there a better way of
doing so?

Feb 27 '07 #2
On Feb 27, 10:08 am, Milosz Skalecki [MCAD]
<mily...@DONTLIKESPAMwp.plwrote:
Howdy,

I have just one question ;-) What's the company name so i would know where
not to apply ;-)
--
Milosz

"Bob Jones" wrote:
I have an odd business requirement and I think that the implementation
is not correct in the terms of OOP development. Any help on the
concepts would be very appreciated!
We currently have a custom Page object which is derived from the base
Page object. We also have custom controls that derive from a base
class that performs custom drawing and inherits from our own
IOurControl interface. There is also a special caching layer in the
mix that retrieves object information from a database/application
cache based on a control id (this is a simplified explanation).
What would be ideal in the eyes of my boss would be that each of our
custom objects retrieves data from the cache on its OnInit event and
draws the content on its OnRender event so our custom page doesn't
have to iterate the custom controls and fire methods accordingly.
Although I understand his reasoning for wanting to do so, I believe
that the methods for getting data and setting content should be added
to the controls IOurControl interface and that our custom page object
should be responsible for looping its child controls and invoking
those methods as needed. His way requires the developers of new
controls to have to know ahead of time where to place specific code or
the controls won't function properly when used in context with our
Page. I also entertained using abstract methods in the control's base
class but since the implementation would be different for each
control, it seemed pointless.
Is my boss' way the best way to implement the solution as far as OOP
concepts go, is my suggestion the best way or is there a better way of
doing so?- Hide quoted text -

- Show quoted text -
Milosz,

Trust me, I can appreciate the humor, but can you or anyone else
provide a meaningful answer to the question? I would like to have an
outside opinion on the matter.

=o)

Feb 27 '07 #3
On Feb 27, 9:31 am, "Bob Jones" <goodold...@gmail.comwrote:
I have an odd business requirement and I think that the implementation
is not correct in the terms of OOP development. Any help on the
concepts would be very appreciated!

We currently have a custom Page object which is derived from the base
Page object. We also have custom controls that derive from a base
class that performs custom drawing and inherits from our own
IOurControl interface. There is also a special caching layer in the
mix that retrieves object information from a database/application
cache based on a control id (this is a simplified explanation).

What would be ideal in the eyes of my boss would be that each of our
custom objects retrieves data from the cache on its OnInit event and
draws the content on its OnRender event so our custom page doesn't
have to iterate the custom controls and fire methods accordingly.

Although I understand his reasoning for wanting to do so, I believe
that the methods for getting data and setting content should be added
to the controls IOurControl interface and that our custom page object
should be responsible for looping its child controls and invoking
those methods as needed. His way requires the developers of new
controls to have to know ahead of time where to place specific code or
the controls won't function properly when used in context with our
Page. I also entertained using abstract methods in the control's base
class but since the implementation would be different for each
control, it seemed pointless.

Is my boss' way the best way to implement the solution as far as OOP
concepts go, is my suggestion the best way or is there a better way of
doing so?
Just cross-posting this message

Feb 27 '07 #4
I have an odd business requirement and I think that the implementation
is not correct in the terms of OOP development. Any help on the
concepts would be very appreciated!
We currently have a custom Page object which is derived from the base
Page object. We also have custom controls that derive from a base
class that performs custom drawing and inherits from our own
IOurControl interface. There is also a special caching layer in the
mix that retrieves object information from a database/application
cache based on a control id (this is a simplified explanation).
What would be ideal in the eyes of my boss would be that each of our
custom objects retrieves data from the cache on its OnInit event and
draws the content on its OnRender event so our custom page doesn't
have to iterate the custom controls and fire methods accordingly.
Although I understand his reasoning for wanting to do so, I believe
that the methods for getting data and setting content should be added
to the controls IOurControl interface and that our custom page object
should be responsible for looping its child controls and invoking
those methods as needed. His way requires the developers of new
controls to have to know ahead of time where to place specific code or
the controls won't function properly when used in context with our
Page. I also entertained using abstract methods in the control's base
class but since the implementation would be different for each
control, it seemed pointless.
Is my boss' way the best way to implement the solution as far as OOP
concepts go, is my suggestion the best way or is there a better way of
doing so?
Feb 27 '07 #5
I have an odd business requirement and I think that the implementation
is not correct in the terms of OOP development. Any help on the
concepts would be very appreciated!

We currently have a custom Page object which is derived from the base
Page object. We also have custom controls that derive from a base
class that performs custom drawing and inherits from our own
IOurControl interface. There is also a special caching layer in the
mix that retrieves object information from a database/application
cache based on a control id (this is a simplified explanation).

What would be ideal in the eyes of my boss would be that each of our
custom objects retrieves data from the cache on its OnInit event and
draws the content on its OnRender event so our custom page doesn't
have to iterate the custom controls and fire methods accordingly.

Although I understand his reasoning for wanting to do so, I believe
that the methods for getting data and setting content should be added
to the controls IOurControl interface and that our custom page object
should be responsible for looping its child controls and invoking
those methods as needed. His way requires the developers of new
controls to have to know ahead of time where to place specific code or
the controls won't function properly when used in context with our
Page. I also entertained using abstract methods in the control's base
class but since the implementation would be different for each
control, it seemed pointless.

Is my boss' way the best way to implement the solution as far as OOP
concepts go, is my suggestion the best way or is there a better way of
doing so?

Feb 27 '07 #6
Hi Bob,

Sorry to say that, but I’m unable to help you, (to be honest) my point of
view at web architecture is completely different. I’m a big fan of making
things easier and clear. I always try to design controls as a separate
presentation blocks that have nothing to do with database or data retrieval
(meaning I’m usually focused on reusability and performance). This is because
in large scale web applications (I usually work on) performance is very
important, data itself is quite big and dynamic (so it’s not possible to
cache everything), so it’s vital to collect required information as quick and
efficient as it gets, usually in one or maximum few database roundtrips, plus
usage of cache, viewstate, application and session states. Therefore when I
see controls that make calls to database I’m really horrified. Let me explain
why:
• Try to reuse control elsewhere (meaning with different database schema you
simply can’t or it’s a big task
• Performance, every time you embed such control, it is responsible for
retrieving the data, meaning using these controls in conjunction with
datalist, gridview is expensive. In addition, it’s not possible to reuse
information you have already have (you usually end up with copying bits to
another data table and binding it to a list)
• There are many dependencies, therefore every single developer involved
must know everything or almost everything, it’s difficult to split tasks
between teams (have in mind all of source control issues related to that), or
delegate simple tasks to less experienced team members or junior developers
• You mentioned about database logic based on control id - it’s just
ridiculous (or I’m really missing something)

From my experience I know it’s easy to develop reusable controls that are
independent on data, you can alsywas go the same path as MST went with field
mapping (i.e. DataTextField, DataValueField, DataValueFormatString, mapping
interface or any similar generic approach.). I know everyone of us developers
has to be open on suggestions and make sure things have been done before
deadline ;) I‘m really serious about the company name :-) Could you pass it
to me so next time I look for a job I would not apply *accidentally* ;-)

Regards

Milosz

"Bob Jones" wrote:
On Feb 27, 10:08 am, Milosz Skalecki [MCAD]
<mily...@DONTLIKESPAMwp.plwrote:
Howdy,

I have just one question ;-) What's the company name so i would know where
not to apply ;-)
--
Milosz

"Bob Jones" wrote:
I have an odd business requirement and I think that the implementation
is not correct in the terms of OOP development. Any help on the
concepts would be very appreciated!
We currently have a custom Page object which is derived from the base
Page object. We also have custom controls that derive from a base
class that performs custom drawing and inherits from our own
IOurControl interface. There is also a special caching layer in the
mix that retrieves object information from a database/application
cache based on a control id (this is a simplified explanation).
What would be ideal in the eyes of my boss would be that each of our
custom objects retrieves data from the cache on its OnInit event and
draws the content on its OnRender event so our custom page doesn't
have to iterate the custom controls and fire methods accordingly.
Although I understand his reasoning for wanting to do so, I believe
that the methods for getting data and setting content should be added
to the controls IOurControl interface and that our custom page object
should be responsible for looping its child controls and invoking
those methods as needed. His way requires the developers of new
controls to have to know ahead of time where to place specific code or
the controls won't function properly when used in context with our
Page. I also entertained using abstract methods in the control's base
class but since the implementation would be different for each
control, it seemed pointless.
Is my boss' way the best way to implement the solution as far as OOP
concepts go, is my suggestion the best way or is there a better way of
doing so?- Hide quoted text -
- Show quoted text -

Milosz,

Trust me, I can appreciate the humor, but can you or anyone else
provide a meaningful answer to the question? I would like to have an
outside opinion on the matter.

=o)

Feb 27 '07 #7
On Feb 27, 11:52 am, Milosz Skalecki [MCAD]
<mily...@DONTLIKESPAMwp.plwrote:
Hi Bob,

Sorry to say that, but I'm unable to help you, (to be honest) my point of
view at web architecture is completely different. I'm a big fan of making
things easier and clear. I always try to design controls as a separate
presentation blocks that have nothing to do with database or data retrieval
(meaning I'm usually focused on reusability and performance). This is because
in large scale web applications (I usually work on) performance is very
important, data itself is quite big and dynamic (so it's not possible to
cache everything), so it's vital to collect required information as quickand
efficient as it gets, usually in one or maximum few database roundtrips, plus
usage of cache, viewstate, application and session states. Therefore whenI
see controls that make calls to database I'm really horrified. Let me explain
why:
Try to reuse control elsewhere (meaning with different database schema you
simply can't or it's a big task
Performance, every time you embed such control, it is responsiblefor
retrieving the data, meaning using these controls in conjunction with
datalist, gridview is expensive. In addition, it's not possible to reuse
information you have already have (you usually end up with copying bits to
another data table and binding it to a list)
There are many dependencies, therefore every single developer involved
must know everything or almost everything, it's difficult to split tasks
between teams (have in mind all of source control issues related to that), or
delegate simple tasks to less experienced team members or junior developers
You mentioned about database logic based on control id - it's just
ridiculous (or I'm really missing something)

From my experience I know it's easy to develop reusable controls that are
independent on data, you can alsywas go the same path as MST went with field
mapping (i.e. DataTextField, DataValueField, DataValueFormatString, mapping
interface or any similar generic approach.). I know everyone of us developers
has to be open on suggestions and make sure things have been done before
deadline ;) I'm really serious about the company name :-) Could you pass it
to me so next time I look for a job I would not apply *accidentally* ;-)

Regards

Milosz

"Bob Jones" wrote:
On Feb 27, 10:08 am, Milosz Skalecki [MCAD]
<mily...@DONTLIKESPAMwp.plwrote:
Howdy,
I have just one question ;-) What's the company name so i would know where
not to apply ;-)
--
Milosz
"Bob Jones" wrote:
I have an odd business requirement and I think that the implementation
is not correct in the terms of OOP development. Any help on the
concepts would be very appreciated!
We currently have a custom Page object which is derived from the base
Page object. We also have custom controls that derive from a base
class that performs custom drawing and inherits from our own
IOurControl interface. There is also a special caching layer in the
mix that retrieves object information from a database/application
cache based on a control id (this is a simplified explanation).
What would be ideal in the eyes of my boss would be that each of our
custom objects retrieves data from the cache on its OnInit event and
draws the content on its OnRender event so our custom page doesn't
have to iterate the custom controls and fire methods accordingly.
Although I understand his reasoning for wanting to do so, I believe
that the methods for getting data and setting content should be added
to the controls IOurControl interface and that our custom page object
should be responsible for looping its child controls and invoking
those methods as needed. His way requires the developers of new
controls to have to know ahead of time where to place specific codeor
the controls won't function properly when used in context with our
Page. I also entertained using abstract methods in the control's base
class but since the implementation would be different for each
control, it seemed pointless.
Is my boss' way the best way to implement the solution as far as OOP
concepts go, is my suggestion the best way or is there a better wayof
doing so?- Hide quoted text -
- Show quoted text -
Milosz,
Trust me, I can appreciate the humor, but can you or anyone else
provide a meaningful answer to the question? I would like to have an
outside opinion on the matter.
=o)- Hide quoted text -

- Show quoted text -
Milosz,

I agree with everything you said and if I were to design this
application from scratch I would def. take a different approach.

The controls, however, are NOT databound but get information from a
caching sytem. But that was just information I gave out to give a
bigger picture. My question is basically the last part of my post.
Would it be better to make our custom Page object loop it's child
controls and call the appropiate methods (MyInit, MyRender) while
passing in needed data or would it be better to force the developers
to hard code methods in each control's OnInit and OnRender functions?

Obviously my take is the former so I can code against an Interface and
not rely on having junior level developers or contracts have to have a
manual next to them in order to write custom controls.

I cannot tell you the company name in the forums but if you would
like, send me an e-mail I can reply to and I will send you the name
(if you respond backto this post w/ your opinion). =o)

Regards,
Bob

Feb 27 '07 #8
I know i know there is nothing you can do :-)

Another resolution would be to register every control that implements
IOurControl interface in base page as it can access containing page instance
via Page property (inside controls' oninit virtual method).

-- begin base page class --
.....
private System.Collections.Generic.List<IOurControlourCont rols = new
System.Collections.Generic.List<IOurControl>();

public System.Collections.Generic.List<IOurControlOurCont rols
{
get
{
return this.ourControls;
}
}

protected override void OnPreRenderComplete(EventArgs e)
{
base.OnPreRenderComplete(e);

foreach (IOurControl control in ourControls)
{
control.OurInterfaceMethod();
}
}
-- end base page class --
-- control that implement IOurInterface --

protected override OnInit(object sender, EventArgs e)
{
base.OnInit(sender, e);

if (this.Page != null)
{
BasePageClassName basePage = (BasePageClassName) this.Page;
basePage.OurControls.Add((IOurInterface) this);
}
}
--
Milosz
"Bob Jones" wrote:
On Feb 27, 11:52 am, Milosz Skalecki [MCAD]
<mily...@DONTLIKESPAMwp.plwrote:
Hi Bob,

Sorry to say that, but I'm unable to help you, (to be honest) my point of
view at web architecture is completely different. I'm a big fan of making
things easier and clear. I always try to design controls as a separate
presentation blocks that have nothing to do with database or data retrieval
(meaning I'm usually focused on reusability and performance). This is because
in large scale web applications (I usually work on) performance is very
important, data itself is quite big and dynamic (so it's not possible to
cache everything), so it's vital to collect required information as quick and
efficient as it gets, usually in one or maximum few database roundtrips, plus
usage of cache, viewstate, application and session states. Therefore when I
see controls that make calls to database I'm really horrified. Let me explain
why:
· Try to reuse control elsewhere (meaning with different database schema you
simply can't or it's a big task
· Performance, every time you embed such control, it is responsible for
retrieving the data, meaning using these controls in conjunction with
datalist, gridview is expensive. In addition, it's not possible to reuse
information you have already have (you usually end up with copying bits to
another data table and binding it to a list)
· There are many dependencies, therefore every single developer involved
must know everything or almost everything, it's difficult to split tasks
between teams (have in mind all of source control issues related to that), or
delegate simple tasks to less experienced team members or junior developers
· You mentioned about database logic based on control id - it's just
ridiculous (or I'm really missing something)

From my experience I know it's easy to develop reusable controls that are
independent on data, you can alsywas go the same path as MST went with field
mapping (i.e. DataTextField, DataValueField, DataValueFormatString, mapping
interface or any similar generic approach.). I know everyone of us developers
has to be open on suggestions and make sure things have been done before
deadline ;) I'm really serious about the company name :-) Could you pass it
to me so next time I look for a job I would not apply *accidentally* ;-)

Regards

Milosz

"Bob Jones" wrote:
On Feb 27, 10:08 am, Milosz Skalecki [MCAD]
<mily...@DONTLIKESPAMwp.plwrote:
Howdy,
I have just one question ;-) What's the company name so i would know where
not to apply ;-)
--
Milosz
"Bob Jones" wrote:
I have an odd business requirement and I think that the implementation
is not correct in the terms of OOP development. Any help on the
concepts would be very appreciated!
We currently have a custom Page object which is derived from the base
Page object. We also have custom controls that derive from a base
class that performs custom drawing and inherits from our own
IOurControl interface. There is also a special caching layer in the
mix that retrieves object information from a database/application
cache based on a control id (this is a simplified explanation).
What would be ideal in the eyes of my boss would be that each of our
custom objects retrieves data from the cache on its OnInit event and
draws the content on its OnRender event so our custom page doesn't
have to iterate the custom controls and fire methods accordingly.
Although I understand his reasoning for wanting to do so, I believe
that the methods for getting data and setting content should be added
to the controls IOurControl interface and that our custom page object
should be responsible for looping its child controls and invoking
those methods as needed. His way requires the developers of new
controls to have to know ahead of time where to place specific code or
the controls won't function properly when used in context with our
Page. I also entertained using abstract methods in the control's base
class but since the implementation would be different for each
control, it seemed pointless.
Is my boss' way the best way to implement the solution as far as OOP
concepts go, is my suggestion the best way or is there a better way of
doing so?- Hide quoted text -
- Show quoted text -
Milosz,
Trust me, I can appreciate the humor, but can you or anyone else
provide a meaningful answer to the question? I would like to have an
outside opinion on the matter.
=o)- Hide quoted text -
- Show quoted text -

Milosz,

I agree with everything you said and if I were to design this
application from scratch I would def. take a different approach.

The controls, however, are NOT databound but get information from a
caching sytem. But that was just information I gave out to give a
bigger picture. My question is basically the last part of my post.
Would it be better to make our custom Page object loop it's child
controls and call the appropiate methods (MyInit, MyRender) while
passing in needed data or would it be better to force the developers
to hard code methods in each control's OnInit and OnRender functions?

Obviously my take is the former so I can code against an Interface and
not rely on having junior level developers or contracts have to have a
manual next to them in order to write custom controls.

I cannot tell you the company name in the forums but if you would
like, send me an e-mail I can reply to and I will send you the name
(if you respond backto this post w/ your opinion). =o)

Regards,
Bob

Feb 27 '07 #9
On Feb 27, 2:48 pm, Milosz Skalecki [MCAD] <mily...@DONTLIKESPAMwp.pl>
wrote:
I know i know there is nothing you can do :-)

Another resolution would be to register every control that implements
IOurControl interface in base page as it can access containing page instance
via Page property (inside controls' oninit virtual method).

-- begin base page class --
....
private System.Collections.Generic.List<IOurControlourCont rols = new
System.Collections.Generic.List<IOurControl>();

public System.Collections.Generic.List<IOurControlOurCont rols
{
get
{
return this.ourControls;
}

}

protected override void OnPreRenderComplete(EventArgs e)
{
base.OnPreRenderComplete(e);

foreach (IOurControl control in ourControls)
{
control.OurInterfaceMethod();
}}

-- end base page class --

-- control that implement IOurInterface --

protected override OnInit(object sender, EventArgs e)
{
base.OnInit(sender, e);

if (this.Page != null)
{
BasePageClassName basePage = (BasePageClassName) this.Page;
basePage.OurControls.Add((IOurInterface) this);
}

}

--
Milosz

"Bob Jones" wrote:
On Feb 27, 11:52 am, Milosz Skalecki [MCAD]
<mily...@DONTLIKESPAMwp.plwrote:
Hi Bob,
Sorry to say that, but I'm unable to help you, (to be honest) my point of
view at web architecture is completely different. I'm a big fan of making
things easier and clear. I always try to design controls as a separate
presentation blocks that have nothing to do with database or data retrieval
(meaning I'm usually focused on reusability and performance). This isbecause
in large scale web applications (I usually work on) performance is very
important, data itself is quite big and dynamic (so it's not possibleto
cache everything), so it's vital to collect required information as quick and
efficient as it gets, usually in one or maximum few database roundtrips, plus
usage of cache, viewstate, application and session states. Therefore when I
see controls that make calls to database I'm really horrified. Let meexplain
why:
Try to reuse control elsewhere (meaning with different database schema you
simply can't or it's a big task
Performance, every time you embed such control, it is responsible for
retrieving the data, meaning using these controls in conjunction with
datalist, gridview is expensive. In addition, it's not possible to reuse
information you have already have (you usually end up with copying bits to
another data table and binding it to a list)
There are many dependencies, therefore every single developerinvolved
must know everything or almost everything, it's difficult to split tasks
between teams (have in mind all of source control issues related to that), or
delegate simple tasks to less experienced team members or junior developers
You mentioned about database logic based on control id - it'sjust
ridiculous (or I'm really missing something)
From my experience I know it's easy to develop reusable controls thatare
independent on data, you can alsywas go the same path as MST went with field
mapping (i.e. DataTextField, DataValueField, DataValueFormatString, mapping
interface or any similar generic approach.). I know everyone of us developers
has to be open on suggestions and make sure things have been done before
deadline ;) I'm really serious about the company name :-) Could you pass it
to me so next time I look for a job I would not apply *accidentally* ;-)
Regards
Milosz
"Bob Jones" wrote:
On Feb 27, 10:08 am, Milosz Skalecki [MCAD]
<mily...@DONTLIKESPAMwp.plwrote:
Howdy,
I have just one question ;-) What's the company name so i would know where
not to apply ;-)
--
Milosz
"Bob Jones" wrote:
I have an odd business requirement and I think that the implementation
is not correct in the terms of OOP development. Any help on the
concepts would be very appreciated!
We currently have a custom Page object which is derived from the base
Page object. We also have custom controls that derive from a base
class that performs custom drawing and inherits from our own
IOurControl interface. There is also a special caching layer inthe
mix that retrieves object information from a database/application
cache based on a control id (this is a simplified explanation).
What would be ideal in the eyes of my boss would be that each of our
custom objects retrieves data from the cache on its OnInit event and
draws the content on its OnRender event so our custom page doesn't
have to iterate the custom controls and fire methods accordingly.
Although I understand his reasoning for wanting to do so, I believe
that the methods for getting data and setting content should beadded
to the controls IOurControl interface and that our custom page object
should be responsible for looping its child controls and invoking
those methods as needed. His way requires the developers of new
controls to have to know ahead of time where to place specific code or
the controls won't function properly when used in context with our
Page. I also entertained using abstract methods in the control's base
class but since the implementation would be different for each
control, it seemed pointless.
Is my boss' way the best way to implement the solution as far as OOP
concepts go, is my suggestion the best way or is there a betterway of
doing so?- Hide quoted text -
- Show quoted text -
Milosz,
Trust me, I can appreciate the humor, but can you or anyone else
provide a meaningful answer to the question? I would like to have an
outside opinion on the matter.
=o)- Hide quoted text -
- Show quoted text -
Milosz,
I agree with everything you said and if I were to design this
application from scratch I would def. take a different approach.
The controls, however, are NOT databound but get information from a
caching sytem. But that was just information I gave out to give a
bigger picture. My question is basically the last part of my post.
Would it be better to make our custom Page object loop it's child
controls and call the appropiate methods (MyInit, MyRender) while
passing in needed data or would it be better to force the developers
to hard code methods in each control's OnInit and OnRender functions?
Obviously my take is the former so I can code against an Interface and
not rely on having junior level developers or contracts have to have a
manual next to them in order to write custom controls.
I cannot tell you the company name in the forums but if you would
like, send me an e-mail I can reply to and I will send you the name
(if you respond backto this post w/ your opinion). =o)
Regards,
Bob- Hide quoted text -

- Show quoted text -
Milosz,

Thanks for the code sample, so you do agree that having the page
control interate the child controls and calling the proper methods IS
the more proper way to go?

Bob

Feb 27 '07 #10
Yes, but not enumertating all the controls in tree, just those that are
registered. Have you checked email box ? ;-)
--
Milosz
"Bob Jones" wrote:
On Feb 27, 2:48 pm, Milosz Skalecki [MCAD] <mily...@DONTLIKESPAMwp.pl>
wrote:
I know i know there is nothing you can do :-)

Another resolution would be to register every control that implements
IOurControl interface in base page as it can access containing page instance
via Page property (inside controls' oninit virtual method).

-- begin base page class --
....
private System.Collections.Generic.List<IOurControlourCont rols = new
System.Collections.Generic.List<IOurControl>();

public System.Collections.Generic.List<IOurControlOurCont rols
{
get
{
return this.ourControls;
}

}

protected override void OnPreRenderComplete(EventArgs e)
{
base.OnPreRenderComplete(e);

foreach (IOurControl control in ourControls)
{
control.OurInterfaceMethod();
}}

-- end base page class --

-- control that implement IOurInterface --

protected override OnInit(object sender, EventArgs e)
{
base.OnInit(sender, e);

if (this.Page != null)
{
BasePageClassName basePage = (BasePageClassName) this.Page;
basePage.OurControls.Add((IOurInterface) this);
}

}

--
Milosz

"Bob Jones" wrote:
On Feb 27, 11:52 am, Milosz Skalecki [MCAD]
<mily...@DONTLIKESPAMwp.plwrote:
Hi Bob,
Sorry to say that, but I'm unable to help you, (to be honest) my point of
view at web architecture is completely different. I'm a big fan of making
things easier and clear. I always try to design controls as a separate
presentation blocks that have nothing to do with database or data retrieval
(meaning I'm usually focused on reusability and performance). This is because
in large scale web applications (I usually work on) performance is very
important, data itself is quite big and dynamic (so it's not possible to
cache everything), so it's vital to collect required information as quick and
efficient as it gets, usually in one or maximum few database roundtrips, plus
usage of cache, viewstate, application and session states. Therefore when I
see controls that make calls to database I'm really horrified. Let me explain
why:
· Try to reuse control elsewhere (meaning with different database schema you
simply can't or it's a big task
· Performance, every time you embed such control, it is responsible for
retrieving the data, meaning using these controls in conjunction with
datalist, gridview is expensive. In addition, it's not possible to reuse
information you have already have (you usually end up with copying bits to
another data table and binding it to a list)
· There are many dependencies, therefore every single developer involved
must know everything or almost everything, it's difficult to split tasks
between teams (have in mind all of source control issues related to that), or
delegate simple tasks to less experienced team members or junior developers
· You mentioned about database logic based on control id - it's just
ridiculous (or I'm really missing something)
From my experience I know it's easy to develop reusable controls that are
independent on data, you can alsywas go the same path as MST went with field
mapping (i.e. DataTextField, DataValueField, DataValueFormatString, mapping
interface or any similar generic approach.). I know everyone of us developers
has to be open on suggestions and make sure things have been done before
deadline ;) I'm really serious about the company name :-) Could you pass it
to me so next time I look for a job I would not apply *accidentally* ;-)
Regards
Milosz
"Bob Jones" wrote:
On Feb 27, 10:08 am, Milosz Skalecki [MCAD]
<mily...@DONTLIKESPAMwp.plwrote:
Howdy,
I have just one question ;-) What's the company name so i would know where
not to apply ;-)
--
Milosz
"Bob Jones" wrote:
I have an odd business requirement and I think that the implementation
is not correct in the terms of OOP development. Any help on the
concepts would be very appreciated!
We currently have a custom Page object which is derived from the base
Page object. We also have custom controls that derive from a base
class that performs custom drawing and inherits from our own
IOurControl interface. There is also a special caching layer in the
mix that retrieves object information from a database/application
cache based on a control id (this is a simplified explanation).
What would be ideal in the eyes of my boss would be that each of our
custom objects retrieves data from the cache on its OnInit event and
draws the content on its OnRender event so our custom page doesn't
have to iterate the custom controls and fire methods accordingly.
Although I understand his reasoning for wanting to do so, I believe
that the methods for getting data and setting content should be added
to the controls IOurControl interface and that our custom page object
should be responsible for looping its child controls and invoking
those methods as needed. His way requires the developers of new
controls to have to know ahead of time where to place specific code or
the controls won't function properly when used in context with our
Page. I also entertained using abstract methods in the control's base
class but since the implementation would be different for each
control, it seemed pointless.
Is my boss' way the best way to implement the solution as far as OOP
concepts go, is my suggestion the best way or is there a better way of
doing so?- Hide quoted text -
- Show quoted text -
Milosz,
Trust me, I can appreciate the humor, but can you or anyone else
provide a meaningful answer to the question? I would like to have an
outside opinion on the matter.
=o)- Hide quoted text -
- Show quoted text -
Milosz,
I agree with everything you said and if I were to design this
application from scratch I would def. take a different approach.
The controls, however, are NOT databound but get information from a
caching sytem. But that was just information I gave out to give a
bigger picture. My question is basically the last part of my post.
Would it be better to make our custom Page object loop it's child
controls and call the appropiate methods (MyInit, MyRender) while
passing in needed data or would it be better to force the developers
to hard code methods in each control's OnInit and OnRender functions?
Obviously my take is the former so I can code against an Interface and
not rely on having junior level developers or contracts have to have a
manual next to them in order to write custom controls.
I cannot tell you the company name in the forums but if you would
like, send me an e-mail I can reply to and I will send you the name
(if you respond backto this post w/ your opinion). =o)
Regards,
Bob- Hide quoted text -
- Show quoted text -

Milosz,

Thanks for the code sample, so you do agree that having the page
control interate the child controls and calling the proper methods IS
the more proper way to go?

Bob

Feb 27 '07 #11
On Feb 27, 3:11 pm, Milosz Skalecki [MCAD] <mily...@DONTLIKESPAMwp.pl>
wrote:
Yes, but not enumertating all the controls in tree, just those that are
registered. Have you checked email box ? ;-)
--
Milosz

"Bob Jones" wrote:
On Feb 27, 2:48 pm, Milosz Skalecki [MCAD] <mily...@DONTLIKESPAMwp.pl>
wrote:
I know i know there is nothing you can do :-)
Another resolution would be to register every control that implements
IOurControl interface in base page as it can access containing page instance
via Page property (inside controls' oninit virtual method).
-- begin base page class --
....
private System.Collections.Generic.List<IOurControlourCont rols = new
System.Collections.Generic.List<IOurControl>();
public System.Collections.Generic.List<IOurControlOurCont rols
{
get
{
return this.ourControls;
}
}
protected override void OnPreRenderComplete(EventArgs e)
{
base.OnPreRenderComplete(e);
foreach (IOurControl control in ourControls)
{
control.OurInterfaceMethod();
}}
-- end base page class --
-- control that implement IOurInterface --
protected override OnInit(object sender, EventArgs e)
{
base.OnInit(sender, e);
if (this.Page != null)
{
BasePageClassName basePage = (BasePageClassName) this.Page;
basePage.OurControls.Add((IOurInterface) this);
}
}
--
Milosz
"Bob Jones" wrote:
On Feb 27, 11:52 am, Milosz Skalecki [MCAD]
<mily...@DONTLIKESPAMwp.plwrote:
Hi Bob,
Sorry to say that, but I'm unable to help you, (to be honest) my point of
view at web architecture is completely different. I'm a big fan of making
things easier and clear. I always try to design controls as a separate
presentation blocks that have nothing to do with database or dataretrieval
(meaning I'm usually focused on reusability and performance). This is because
in large scale web applications (I usually work on) performance is very
important, data itself is quite big and dynamic (so it's not possible to
cache everything), so it's vital to collect required information as quick and
efficient as it gets, usually in one or maximum few database roundtrips, plus
usage of cache, viewstate, application and session states. Therefore when I
see controls that make calls to database I'm really horrified. Let me explain
why:
Try to reuse control elsewhere (meaning with different database schema you
simply can't or it's a big task
Performance, every time you embed such control, it is responsible for
retrieving the data, meaning using these controls in conjunction with
datalist, gridview is expensive. In addition, it's not possible to reuse
information you have already have (you usually end up with copying bits to
another data table and binding it to a list)
There are many dependencies, therefore every single developer involved
must know everything or almost everything, it's difficult to split tasks
between teams (have in mind all of source control issues related to that), or
delegate simple tasks to less experienced team members or junior developers
You mentioned about database logic based on control id - it's just
ridiculous (or I'm really missing something)
From my experience I know it's easy to develop reusable controls that are
independent on data, you can alsywas go the same path as MST wentwith field
mapping (i.e. DataTextField, DataValueField, DataValueFormatString, mapping
interface or any similar generic approach.). I know everyone of us developers
has to be open on suggestions and make sure things have been donebefore
deadline ;) I'm really serious about the company name :-) Could you pass it
to me so next time I look for a job I would not apply *accidentally* ;-)
Regards
Milosz
"Bob Jones" wrote:
On Feb 27, 10:08 am, Milosz Skalecki [MCAD]
<mily...@DONTLIKESPAMwp.plwrote:
Howdy,
I have just one question ;-) What's the company name so i would know where
not to apply ;-)
--
Milosz
"Bob Jones" wrote:
I have an odd business requirement and I think that the implementation
is not correct in the terms of OOP development. Any help onthe
concepts would be very appreciated!
We currently have a custom Page object which is derived from the base
Page object. We also have custom controls that derive from a base
class that performs custom drawing and inherits from our own
IOurControl interface. There is also a special caching layer in the
mix that retrieves object information from a database/application
cache based on a control id (this is a simplified explanation).
What would be ideal in the eyes of my boss would be that each of our
custom objects retrieves data from the cache on its OnInit event and
draws the content on its OnRender event so our custom page doesn't
have to iterate the custom controls and fire methods accordingly.
Although I understand his reasoning for wanting to do so, Ibelieve
that the methods for getting data and setting content should be added
to the controls IOurControl interface and that our custom page object
should be responsible for looping its child controls and invoking
those methods as needed. His way requires the developers ofnew
controls to have to know ahead of time where to place specific code or
the controls won't function properly when used in context with our
Page. I also entertained using abstract methods in the control's base
class but since the implementation would be different for each
control, it seemed pointless.
Is my boss' way the best way to implement the solution as far as OOP
concepts go, is my suggestion the best way or is there a better way of
doing so?- Hide quoted text -
- Show quoted text -
Milosz,
Trust me, I can appreciate the humor, but can you or anyone else
provide a meaningful answer to the question? I would like to have an
outside opinion on the matter.
=o)- Hide quoted text -
- Show quoted text -
Milosz,
I agree with everything you said and if I were to design this
application from scratch I would def. take a different approach.
The controls, however, are NOT databound but get information from a
caching sytem. But that was just information I gave out to give a
bigger picture. My question is basically the last part of my post.
Would it be better to make our custom Page object loop it's child
controls and call the appropiate methods (MyInit, MyRender) while
passing in needed data or would it be better to force the developers
to hard code methods in each control's OnInit and OnRender functions?
Obviously my take is the former so I can code against an Interface and
not rely on having junior level developers or contracts have to have a
manual next to them in order to write custom controls.
I cannot tell you the company name in the forums but if you would
like, send me an e-mail I can reply to and I will send you the name
(if you respond backto this post w/ your opinion). =o)
Regards,
Bob- Hide quoted text -
- Show quoted text -
Milosz,
Thanks for the code sample, so you do agree that having the page
control interate the child controls and calling the proper methods IS
the more proper way to go?
Bob- Hide quoted text -

- Show quoted text -
Thanks for the help and the code, Milosz. Ya got mail, btw.
If anyone else cares to add their two cents, please feel free

Feb 27 '07 #12
On Feb 27, 10:49 am, "Bob Jones" <goodold...@gmail.comwrote:
I have an odd business requirement and I think that the implementation
is not correct in the terms of OOP development. Any help on the
concepts would be very appreciated!

We currently have a custom Page object which is derived from the base
Page object. We also have custom controls that derive from a base
class that performs custom drawing and inherits from our own
IOurControl interface. There is also a special caching layer in the
mix that retrieves object information from a database/application
cache based on a control id (this is a simplified explanation).

What would be ideal in the eyes of my boss would be that each of our
custom objects retrieves data from the cache on its OnInit event and
draws the content on its OnRender event so our custom page doesn't
have to iterate the custom controls and fire methods accordingly.

Although I understand his reasoning for wanting to do so, I believe
that the methods for getting data and setting content should be added
to the controls IOurControl interface and that our custom page object
should be responsible for looping its child controls and invoking
those methods as needed. His way requires the developers of new
controls to have to know ahead of time where to place specific code or
the controls won't function properly when used in context with our
Page. I also entertained using abstract methods in the control's base
class but since the implementation would be different for each
control, it seemed pointless.

Is my boss' way the best way to implement the solution as far as OOP
concepts go, is my suggestion the best way or is there a better way of
doing so?
Seriously? No body has any comments on this matter?

Feb 28 '07 #13

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

0
by: thivi | last post by:
hi all i am developing an user control in which i am creating a set of menu objects in a panel.. i have overriden the oncontroladded and painting. whenever i add the menu object i add it to the...
3
by: Jim Heavey | last post by:
Trying to figure out the technique which should be used to add rows to a datagrid. I am thinking that I would want an "Add" button on the footer, but I am not quite sure how to do that. Is that...
1
by: sleigh | last post by:
Hello, I'm building a web application that will build a dynamic form based upon questions in a database. This form will have several different sections that consist of a panel containing one to...
5
by: Jeremy Ames | last post by:
I have run into a major road block with my page development projects. I am trying to add a literal control to my asp.net page and I got an error stating that the control could not be added because...
1
by: seanmayhew | last post by:
I have a form page that that while editing saves the data to an xml doc before submitting to db. On each page unload it saves the xmldoc as the user can add multiple items to the company like...
3
by: Ankit Aneja | last post by:
I have a strange situation and I have no idea how to solve this. Its a Recruitment Search Page,in the Admin Page, for every button click event the Admin Person has to create a checkbox on the users...
1
by: srneu71 | last post by:
I have a project that requires a dynamically generated matrix table. The table is setup with 4 quadrants (N,S,E,W) with checkboxes to "link" the data in adjacent quadrants. The table has to be...
1
by: =?Utf-8?B?U3RldmUgUmFuZGFsbA==?= | last post by:
I have a form with a number of panel controls on it. I have overriden the paint event (of the panel controls) to provide custom painting. What I have done is to use the Paint event to paint the...
1
by: Jordan S. | last post by:
Using .NET 3.5, I'm wondering how to get a control's specific type (e.g,. "Button" and not simply "Control") after the control is inserted into a control hierarchy - when ParseControl is used. ...
2
by: Kemmylinns12 | last post by:
Blockchain technology has emerged as a transformative force in the business world, offering unprecedented opportunities for innovation and efficiency. While initially associated with cryptocurrencies...
0
hi
by: WisdomUfot | last post by:
It's an interesting question you've got about how Gmail hides the HTTP referrer when a link in an email is clicked. While I don't have the specific technical details, Gmail likely implements measures...
0
Oralloy
by: Oralloy | last post by:
Hello Folks, I am trying to hook up a CPU which I designed using SystemC to I/O pins on an FPGA. My problem (spelled failure) is with the synthesis of my design into a bitstream, not the C++...
0
BLUEPANDA
by: BLUEPANDA | last post by:
At BluePanda Dev, we're passionate about building high-quality software and sharing our knowledge with the community. That's why we've created a SaaS starter kit that's not only easy to use but also...
0
by: Rahul1995seven | last post by:
Introduction: In the realm of programming languages, Python has emerged as a powerhouse. With its simplicity, versatility, and robustness, Python has gained popularity among beginners and experts...
2
by: Ricardo de Mila | last post by:
Dear people, good afternoon... I have a form in msAccess with lots of controls and a specific routine must be triggered if the mouse_down event happens in any control. Than I need to discover what...
1
by: Johno34 | last post by:
I have this click event on my form. It speaks to a Datasheet Subform Private Sub Command260_Click() Dim r As DAO.Recordset Set r = Form_frmABCD.Form.RecordsetClone r.MoveFirst Do If...
1
by: ezappsrUS | last post by:
Hi, I wonder if someone knows where I am going wrong below. I have a continuous form and two labels where only one would be visible depending on the checkbox being checked or not. Below is the...
0
DizelArs
by: DizelArs | last post by:
Hi all) Faced with a problem, element.click() event doesn't work in Safari browser. Tried various tricks like emulating touch event through a function: let clickEvent = new Event('click', {...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.