beehive-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daryl Olander <dolan...@gmail.com>
Subject Re: deprecating NetUI's FormData
Date Wed, 16 Nov 2005 14:23:00 GMT
I'd add two interfaces, but you can't "evolve" these interfaces. Once you
ship an interface, it's there forever. Validation and Reset are very
different things and not related, which is the reason for two interfaces.

I also wouldn't add the uber interface. There doesn't seem to be reason for
it and it just one more thing that you can't change that duplicates existing
functionality.

On 11/15/05, Eddie O'Neil <ekoneil@gmail.com> wrote:
>
> Since you asked...
>
> :)
>
>
> On 11/15/05, Rich Feit <richfeit@gmail.com> wrote:
> > That's definitely my instinct, too. Any thoughts on:
> >
> > 1) whether to include a simple FormBean interface that extends both
> > of the others
>
> I wouldn't -- if a class wants both interfaces, they can implement
> both. In doing so, they're still implementing the same number of
> methods, so the only typing difference is something like:
>
> implements Validatable, FormLifecycle
>
> versus:
>
> implements FormStuff
>
> > 2) what to call the interface with prePopulate
>
> FormLifecycle?
>
> >
> > ?
> > Rich
> >
> > Eddie O'Neil wrote:
> >
> > > My vote would be for two interfaces as it allows each to evolve
> > >independently. I'd guess that not all of our existing tests need
> > >both, so that's probably somewhat representative of some basic usage
> > >patterns which implies the loose coupling. Might as well not force
> > >classes to implement methods they don't need. :)
> > >
> > >Eddie
> > >
> > >
> > >On 11/15/05, Rich Feit <richfeit@gmail.com> wrote:
> > >
> > >
> > >>OK, this is in with revision 344895.
> > >>
> > >>I did find the *single* bit of usefulness in extending FormData. Like
> > >>the Struts ActionForm, it allows you to perform initialization and
> other
> > >>logic in a reset() method. This method is called before population of
> > >>data from the request, and it has access to the request object.
> > >>
> > >>Given this, I'd propose exposing something like prePopulate() through
> an
> > >>interface. My preference would be to have a single interface
> (FormBean)
> > >>that either contains both prePopulate() and validate(), or extends two
> > >>separate interfaces for each of those two methods.
> > >>
> > >>Any thoughts on this?
> > >>
> > >>Thanks,
> > >>Rich
> > >>
> > >>Rich Feit wrote:
> > >>
> > >>
> > >>
> > >>>Excellent. I made a local change that does this (and fixes up all the
> > >>>code/test that depends on it). If no one else has any objections,
> I'll
> > >>>check it in as soon as I'm finished.
> > >>>
> > >>>Eddie O'Neil wrote:
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>>+1
> > >>>>
> > >>>>Seems totally right to start doing this with the "legacy"
> infrastructure. :)
> > >>>>
> > >>>>
> > >>>>On 11/14/05, Rich Feit <richfeit@gmail.com> wrote:
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>>>Hi all,
> > >>>>>
> > >>>>>Would anyone object to me deprecating
> > >>>>>org.apache.beehive.netui.pageflow.FormData? It's basically a
legacy
> > >>>>>action form base class that's no longer necessary (as a
> user-visible
> > >>>>>class) since we support *any* type as a form bean.
> > >>>>>
> > >>>>>Let me know if you see any problem with this...
> > >>>>>
> > >>>>>Thanks,
> > >>>>>Rich
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>
> > >>>
> > >>>
> > >
> > >
> > >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message