CSLA .NET

Vibrant discussion about CSLA .NET and using the framework to build great business applications.

Forum has moved

New location: CSLA .NET forum


CSLA .NET Resources:
  • CSLA .NET forum
  • CSLA .NET home page
  • WPF DataPanelBase

    rated by 0 users
    This post has 4 Replies | 1 Follower

    Top 150 Contributor
    Posts 61
    Paul Czywczynski Posted: Thu, Jun 21 2007 11:53 AM
    Hi Rocky, is there a reason you changed the base class from Decorator to StackPanel? This change has messed up our form layouts. Do CSLA panels need the layout functionality?

    Thanks...  -Paul
    Top 10 Contributor
    Posts 9,475

    It was a question of changing the class names (because they weren't panels) or making them actual panels.

    I chose to make them actual panel controls, because that's how they are used (as a container). I got tired of always having to put a container inside a "panel" so I could actually put any content on the form. Making the controls be actual panels eliminated a bunch of "junk" XAML.

    And it seemed harmless (since you can always put another layout control inside the panel).

    If it is not harmless, I'll consider going the other way and renaming all the controls from blahPanel to blahDecorator - though I personally am not too keen on having to go back and add all that extra XAML into my forms.

    Now is a good time for this discussion (today and tomorrow), because I'm just wrapping up for Beta 2.

    Rocky

    Top 150 Contributor
    Posts 61
    Actually all our forms have root grids. We liked the greater flexablity of the grids as a root element instead of panels. Since the CSLA panels were just decorators we just put them around the grids. Now that they are stack panels it screws up our grid and child container formatting.
    I guess its more of a phylisophical question. Should the CSLA panels affect layout or not? In lieu of having to change nearly 100 forms you know my answer but that shouldn't drive the design of the framework.
    Top 10 Contributor
    Posts 9,475

    I see what you are saying, and I find this to be a tough question.

    Making the controls "invisible" makes them flexible, but ultimately adds to the XAML required on a form.

    I tried making them be a "lookless" panel (inherit from Panel directly), but that's not possible. If they are actual "panel" controls, then they must control layout - that's the definition of a panel.

    But I kept trying to put stuff "into" ValidationPanel, which of course didn't work. So I'd always have to go back and wrap the content with a StackPanel inside the ValidationPanel - that was the instigation for the change.

    I suppose you are ultimately right. My guess is that 90% of the time having them be a real panel would be beneficial, but it probably precludes the other 10% from working at all...

    But I do have to rename them, because keeping "Panel" on the end confuses me continually, and will almost certainly confuse many other people over the coming years.

    I'm thinking either "Decorator" (to keep with the base class name) or "Provider". Or I could do what Microsoft appears to do and use no postfix at all:

    Validator
    Authorizer
    ObjectStatus

    That is probably the right answer.

    Rocky

    Not Ranked
    Posts 1
    okoboji replied on Tue, Jun 26 2007 12:08 PM
    Good timing for this discussion, I posted some thoughts on my blog: http://work.j832.com/2007/06/wpf-and-csla-and-subclassing-panel.html
    Page 1 of 1 (5 items) | RSS

    Copyright (c) 2006-2014 Marimer LLC. All rights reserved.
    Email admin@lhotka.net for support.
    Powered by Community Server (Non-Commercial Edition), by Telligent Systems