> by "class proliferation" you mean having to extend a base class?
well, I mean using three classes to do what I've been accomplishing with one
- it struck me as off, but I'm sure you guys know what you're about :)
Jonathan, thanks for the advise.
feeling and I'd
> like
> avoid it if possible.
>
> Any other ideas?
>
> Thanks,
> Loren
>
>
--
View this message in context:
http://www.nabble.com/building-extensible-components-tp21488696p21490219.html
by "class proliferation" you mean having to extend a base class?
-igor
On Thu, Jan 15, 2009 at 3:40 PM, Loren Cole wrote:
> No that is pretty much what I meant. The composition solution would involve
> and abstract superclass and then for each kind of widget a fairly trivial
> implementation of
No that is pretty much what I meant. The composition solution would involve
and abstract superclass and then for each kind of widget a fairly trivial
implementation of the superclass, a static panel, and a dynamic panel. It's
just that all that class proliferation gives me a nasty feeling and I'd
As I understand it, you have a generic container component, which may
contain different subpanels. You do know that Panels can actually have their
own markup and also markup inheritance (?), so you'd end up with three
classes: the main panel (container) and you add an instance of (sub)classes
2 (th
I'm building an app that will have *lots* of panels that all follow a very
similar pattern:
They have a form and a static view whose visibility gets toggled when when
you click edit/cancel|save|delete
They display a warning if their model is empty
They pop up a warning when you delete them
They al
