I agree validation is an overlap (and it really doesn't need to be.) Dialog and saveState are similar but different enough (IMO) to justify the two instances. t:saveState uses a component approach to maintain state between requests. Dialog uses more of a framework approach (there are no custom tags needed.) Dialog also does a lot more then saveState.
Nothing wrong with saveState by the way ;-) In fact, sometimes the simpler feature set of saveState makes it easier (and more appropriate) then dialog. Sean On 1/5/06, Werner Punz <[EMAIL PROTECTED]> wrote: > Martin Marinschek wrote: > > In fact, > > > > I'd not deny a component coming in even if it is a little duplicate to > > what shale has to offer. Shale is not supposed to be a full-blown > > component library, that's what we are here for I'd say. > > > > regards, > > > > > The way I see it is, that shale tries to be a backend framework, it is > very clear that sometimes you have overlapping areas, validation for > instance is one of those issues, scoping (shale dialog, and saveState) > is another one, there always will be redundant areas. > >
