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

Discussion in 'ASP .Net' started by Bob Jones, Feb 27, 2007.

  1. Bob Jones

    Bob Jones Guest

    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?
    Bob Jones, Feb 27, 2007
    #1
    1. Advertising

  2. RE: ASP.NET/OOP and adding specific logic to controls in overriden met

    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?
    >
    >
    =?Utf-8?B?TWlsb3N6IFNrYWxlY2tpIFtNQ0FEXQ==?=, Feb 27, 2007
    #2
    1. Advertising

  3. Bob Jones

    Bob Jones Guest

    Re: ASP.NET/OOP and adding specific logic to controls in overriden met

    On Feb 27, 10:08 am, Milosz Skalecki [MCAD]
    <> wrote:
    > 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)
    Bob Jones, Feb 27, 2007
    #3
  4. Bob Jones

    Bob Jones Guest

    On Feb 27, 9:31 am, "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?


    Just cross-posting this message
    Bob Jones, Feb 27, 2007
    #4
  5. Bob Jones

    Bob Jones Guest

    > 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?
    Bob Jones, Feb 27, 2007
    #5
  6. Bob Jones

    Bob Jones Guest

    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?
    Bob Jones, Feb 27, 2007
    #6
  7. Re: ASP.NET/OOP and adding specific logic to controls in overriden

    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]
    > <> wrote:
    > > 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)
    >
    >
    =?Utf-8?B?TWlsb3N6IFNrYWxlY2tpIFtNQ0FEXQ==?=, Feb 27, 2007
    #7
  8. Bob Jones

    Bob Jones Guest

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

    On Feb 27, 11:52 am, Milosz Skalecki [MCAD]
    <> wrote:
    > 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]
    > > <> wrote:
    > > > 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
    Bob Jones, Feb 27, 2007
    #8
  9. Re: ASP.NET/OOP and adding specific logic to controls in overriden

    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<IOurControl> ourControls = new
    System.Collections.Generic.List<IOurControl>();

    public System.Collections.Generic.List<IOurControl> OurControls
    {
    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]
    > <> wrote:
    > > 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]
    > > > <> wrote:
    > > > > 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
    >
    >
    =?Utf-8?B?TWlsb3N6IFNrYWxlY2tpIFtNQ0FEXQ==?=, Feb 27, 2007
    #9
  10. Bob Jones

    Bob Jones Guest

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

    On Feb 27, 2:48 pm, Milosz Skalecki [MCAD] <>
    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<IOurControl> ourControls = new
    > System.Collections.Generic.List<IOurControl>();
    >
    > public System.Collections.Generic.List<IOurControl> OurControls
    > {
    > 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]
    > > <> wrote:
    > > > 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]
    > > > > <> wrote:
    > > > > > 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
    Bob Jones, Feb 27, 2007
    #10
  11. Re: ASP.NET/OOP and adding specific logic to controls in overriden

    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] <>
    > 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<IOurControl> ourControls = new
    > > System.Collections.Generic.List<IOurControl>();
    > >
    > > public System.Collections.Generic.List<IOurControl> OurControls
    > > {
    > > 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]
    > > > <> wrote:
    > > > > 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]
    > > > > > <> wrote:
    > > > > > > 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
    >
    >
    =?Utf-8?B?TWlsb3N6IFNrYWxlY2tpIFtNQ0FEXQ==?=, Feb 27, 2007
    #11
  12. Bob Jones

    Bob Jones Guest

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

    On Feb 27, 3:11 pm, Milosz Skalecki [MCAD] <>
    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] <>
    > > 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<IOurControl> ourControls = new
    > > > System.Collections.Generic.List<IOurControl>();

    >
    > > > public System.Collections.Generic.List<IOurControl> OurControls
    > > > {
    > > > 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]
    > > > > <> wrote:
    > > > > > 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]
    > > > > > > <> wrote:
    > > > > > > > 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- 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
    Bob Jones, Feb 27, 2007
    #12
  13. Bob Jones

    Bob Jones Guest

    On Feb 27, 10:49 am, "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?


    Seriously? No body has any comments on this matter?
    Bob Jones, Feb 28, 2007
    #13
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. VisionSet
    Replies:
    51
    Views:
    4,256
    Tony Morris
    Jul 14, 2004
  2. =?Utf-8?B?Y2hlbG9tYW4xMg==?=

    overriden viewstate events and gridview

    =?Utf-8?B?Y2hlbG9tYW4xMg==?=, May 4, 2006, in forum: ASP .Net
    Replies:
    0
    Views:
    343
    =?Utf-8?B?Y2hlbG9tYW4xMg==?=
    May 4, 2006
  3. =?Utf-8?B?Y2hlbG9tYW4xMg==?=

    GridView problems with viewstate events overriden.

    =?Utf-8?B?Y2hlbG9tYW4xMg==?=, May 9, 2006, in forum: ASP .Net
    Replies:
    1
    Views:
    4,513
    Teemu Keiski
    May 9, 2006
  4. Binary
    Replies:
    3
    Views:
    284
  5. Gerrit Horeis

    Nested controls overriden by skin file

    Gerrit Horeis, Apr 12, 2007, in forum: ASP .Net Building Controls
    Replies:
    0
    Views:
    155
    Gerrit Horeis
    Apr 12, 2007
Loading...

Share This Page