beehive-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Carlin Rogers" <carlin.rog...@gmail.com>
Subject Re: adding NetUI annotation processing for an external form bean class in check() phase
Date Sun, 27 Aug 2006 19:50:11 GMT
Rich, I'm not so sure about having the second standalone factory, FBAPF, and
a different AP (FBCAP).

I found a way to avoid creating a method level checker by taking the set of
declarations (method and class) that the FBCAP gets and constructing just
the unique set of class declarations (with single instance of a class
declaration for the various individual method decls that might be present).

However, this leads to an issue with ensuring the correct behavior with the
generate() phase. How can one AP know about the errors in another AP? The
PFCAP should not call generate() if there are errors in the FBCAP. Otherwise
we still have the same issue as before with BEEHIVE-1127. There could be
errors in the form bean but if the PFCAP does not know about the errors,
then the generate phase could fail.

Thoughts?

Carlin

On 8/24/06, Carlin Rogers <carlin.rogers@gmail.com> wrote:
>
> Just another note after looking at this some more...
>
> Seems that to handle the MethodDeclaration we would need to have a method
> level checker. Otherwise, if we just get the ClassDeclaration from the
> MethodDeclaration and pass it into the FormBeanChecker, we could run the
> checker multiple times. The FBC would run on the same class for each method
> with a validatable property annotation.
>
> Rich, I think we'd need a different method level checker for validation
> properties. What do you think. For now I will check in my original work and
> then as an iterative step look at making FBAPF handle @Jpf.Validatable* .
>
> Carlin
>
> On 8/23/06, Carlin Rogers < carlin.rogers@gmail.com> wrote:
> >
> > Hey Rich,
> >
> > With the current NetUI AP class hierarchy it wouldn't matter either way.
> > The PFCAP and FBCAP both inherit from BaseCoreAnnotationProcessor which
> > extends TwoPhaseCoreAnnotationProcessor. The check() "phase" of the TPCAP
> > passes each declaration annotation to check(decl) method implemented in the
> > BCAP. This BCAP method only gets a checker if the decl is an instance of
> > ClassDeclaration. So an external form bean without the @FormBean would not
> > get processed.
> >
> > I guess we could have FBCAP override check(decl) or figure out a way to
> > rewrite BCAP to handle a general case of a MethodDeclaration. I think I'd go
> > with the former and if the decl is a ClassDeclaration it can just go on to
> > the super method. Otherwise check for MethodDeclaration and call the
> > getChecker() routine.
> >
> > Thanks,
> > Carlin
> >
> >
> > On 8/23/06, Rich Feit < richfeit@gmail.com> wrote:
> > >
> > > Nice job.  Just curious: is it possible for the
> > > FormBeanAnnotationProcessorFactory to handle all @Jpf.Validatable*
> > > annotations?  PageFlowChecker could still crawl into them if it needed
> > > to, but of FBAPF handled them, then its annotation processor should
> > > end
> > > up getting a shot at all external form bean classes.  Just a thought.
> > >
> > > Rich
> > >
> > > Carlin Rogers wrote:
> > > > I have some local changes for the standalone checker... a new
> > > > FormBeanAnnotationProcessorFactory that hooks up the
> > > > FormBeanCoreAnnotationProcessor and added an entry in the
> > > > META-INF/services/com.sun.mirror.apt.AnnotationProcessorFactory for
> > > the
> > > > factory. Initial tests seem to be OK. I also have my change that
> > > will
> > > > check
> > > > an external form bean from within FlowControllerChecker, only when
> > > > there is
> > > > *no* @FormBean.
> > > >
> > > > I have not added a warning message to users that they should always
> > > > have a
> > > > @FormBean annotation when using any of the @ValidatableProperty
> > > > annotations
> > > > in a form bean. I was concerned that there is already a precedent
> > > for
> > > > just
> > > > using the @FormBean to define a message bundle. See the NetUI
> > > tutorial
> > > > and
> > > > the note about using @FormBean...
> > > >
> > > > http://beehive.apache.org/docs/1.0.1/netui/tutorial.html#validation
> > > >
> > > > Does anyone feel strongly that we should change the behavior and
> > > always
> > > > expect @FormBean annotation when using any of the
> > > @ValidatableProperty
> > > > annotations? If so, I will add the warning and change the tutorial.
> > > >
> > > > Kind regards,
> > > > Carlin
> > > >
> > > > On 8/15/06, Rich Feit <richfeit@privatei.com > wrote:
> > > >>
> > > >> That makes sense to me -- basically we'd be saying that we require
> > > a
> > > >> top-level annotation if you want to use method- or field-level
> > > >> annotations.
> > > >>
> > > >> You can also just go with your original suggestion, but I think
> > > that in
> > > >> that case you could end up with multiple errors for a single class.
> > >
> > > >>
> > > >> Rich
> > > >>
> > > >> Carlin Rogers wrote:
> > > >> > Rich,
> > > >> >
> > > >> > I'll take a look at this more closely and make sure I follow
as
> > > I'm
> > > >> > not yet
> > > >> > sure how that impacts the use of the @ValidatableBean annotation
> > > >> > (which is
> > > >> > used with the validatableBeans attribute of the Controller
> > > annot). I
> > > >> > guess
> > > >> > either @ValidatableBean or @FormBean would be required for
> > > >> > @ValidatableProperty?
> > > >> >
> > > >> > Thanks,
> > > >> > Carlin
> > > >> >
> > > >> > On 8/15/06, Rich Feit < richfeit@gmail.com> wrote:
> > > >> >>
> > > >> >> Carlin,
> > > >> >>
> > > >> >> Makes sense -- I'd forgotten that we don't require the
> > > annotation.
> > > >> >> Seems like we're being too lax in this case -- I actually
think
> > > >> that it
> > > >> >> would be best to require the @FormBean annotation when using
any
> > > >> of the
> > > >> >> @ValidatableProperty annotations.  We don't want to require
> > > @FormBean
> > > >> >> just to use an external bean, but I don't see the harm in
> > > >> requiring it
> > > >> >> when any of the other annotations are used inside the
> > > bean.  That
> > > >> way,
> > > >> >> we can preserve the idea of a standalone checker.
> > > >> >>
> > > >> >> For back-compat, you could run a checker on any external
form
> > > bean
> > > >> from
> > > >> >> within PageFlowChecker (as you suggested), but only when
there
> > > is
> > > >> *no*
> > > >> >> @FormBean.  If you encounter any @ValidatableProperty
> > > annotations in
> > > >> >> that case, you could deprecation-warn that @FormBean should
be
> > > used.
> > > >> >>
> > > >> >> What do you think?
> > > >> >>
> > > >> >> Rich
> > > >> >>
> > > >> >> Carlin Rogers wrote:
> > > >> >> > Rich,
> > > >> >> >
> > > >> >> > I have a question about the suggestion to create and
use the
> > > FBAPF.
> > > >> It
> > > >> >> > seems
> > > >> >> > that this would work only in the case that the standalone
> > > includes
> > > >> >> the @
> > > >> >> > Jpf.FormBean annotation. However, users can define validation
> > > rules
> > > >> >> > without
> > > >> >> > @Jpf.FormBean and just use @Jpf.ValidatableProperty.
The
> > > FormBean
> > > >> >> > allows the
> > > >> >> > class to define its own message bundle for validation
errors,
> > > but
> > > >> it's
> > > >> >> > just
> > > >> >> > an option.
> > > >> >> >
> > > >> >> > We need to make sure that we check the ValidatableProperty
> > > before
> > > >> >> > going to
> > > >> >> > generate() to provide AP error information. The
> > > ValidatableProperty
> > > >> >> > can be
> > > >> >> > on a method (of a bean) and an annotation type (listed
in the
> > > @
> > > >> >> > Jpf.Controller or @Jpf.Action). Since it's not just
associated
> > > to a
> > > >> >> type,
> > > >> >> > would we still be able to do something like you suggested
and
> > > >> create
> > > >> >> > an AP
> > > >> >> > factory for ValidatableProperty? Maybe I'm missing something
> > > though
> > > >> >> with
> > > >> >> > what you were suggesting.
> > > >> >> >
> > > >> >> > Thanks,
> > > >> >> > Carlin
> > > >> >> >
> > > >> >> > On 8/14/06, Rich Feit < richfeit@gmail.com> wrote:
> > > >> >> >>
> > > >> >> >> Hey Carlin,
> > > >> >> >>
> > > >> >> >> I think what might be better would be to make a
> > > >> >> >> FormBeanAnnotationProcessorFactory in
> > > >> >> >> compiler-apt/org/apache/beehive/netui/compiler/apt,
and make
> > > it
> > > >> >> >> responsible for the form bean annotation (you'd
need to
> > > remove
> > > >> that
> > > >> >> >> annotation from the list of supported annotations
in
> > > >> >> >> PageFlowAnnotationProcessorFactory).  FBAPF could
then simply
> > > >> >> return a
> > > >> >> >> FormBeanCoreAnnotationProcessorFactory -- which
already
> > > exists
> > > >> -- in
> > > >> >> its
> > > >> >> >> getCoreProcessorFor().  I honestly cannot remember
why I
> > > didn't do
> > > >> >> that
> > > >> >> >> -- sorry.
> > > >> >> >>
> > > >> >> >> If it turns out that this doesn't work for some
reason, you
> > > could
> > > >> >> also
> > > >> >> >> roll the functionality from FormBeanCoreAnnotationProcessor
> > > into
> > > >> >> >> PageFlowCoreAnnotationProcessor (and to delete the
former).
> > > >> >> >>
> > > >> >> >> In either case, you end up with standalone checking
form bean
> > > >> >> classes,
> > > >> >> >> which is nicer because you don't have to worry about
multiple
> > >
> > > >> >> >> PageFlowCheckers triggering checking on the same
external
> > > form
> > > >> bean
> > > >> >> >> class, and it's just cleaner to have it be standalone.
> > > >> >> >>
> > > >> >> >> All that said, I didn't wire it up in the first
place, so if
> > > >> you run
> > > >> >> >> into any difficulties let me know -- it's possible
there's
> > > >> something
> > > >> >> I'm
> > > >> >> >> missing here.
> > > >> >> >>
> > > >> >> >> Rich
> > > >> >> >>
> > > >> >> >> Carlin Rogers wrote:
> > > >> >> >> > I'm taking a look at BEEHIVE-1127 and wanted
to share some
> > > >> thoughts
> > > >> >> >> about
> > > >> >> >> > ensuring the annotation processing of validatable
bean
> > > >> properties
> > > >> >> >> > declared
> > > >> >> >> > in an external form bean class during the check()
phase.
> > > >> >> >> >
> > > >> >> >> > The current implementation for processing of
the Controller
> > > >> >> >> > annotations does
> > > >> >> >> > not process external form bean during the check()
phase of
> > > the
> > > >> >> >> > TwoPhaseCoreAnnotationProcessor. During the
Controller
> > > >> annotation
> > > >> >> >> > processing, FlowControllerChecker.onCheck()
creates the
> > > >> >> >> > FormBeanChecker and
> > > >> >> >> > then during the onCheckInternal() uses it to
check
> > > >> >> ValidatableProperty
> > > >> >> >> > annotations on inner classes only.
> > > >> >> >> >
> > > >> >> >> > I'd like to modify FlowControllerChecker.checkMethod()
(for
> > > >> action
> > > >> >> >> > grammar
> > > >> >> >> > checking) to also look at the parameter of
an action and
> > > >> check for
> > > >> >> >> > validation rules. The change would only use
the
> > > >> FormBeanChecker on
> > > >> >> the
> > > >> >> >> > parameter class if it is a ClassDeclaration
without a
> > > declaring
> > > >> >> type
> > > >> >> >> > (so we
> > > >> >> >> > don't re-check an inner class). Does this sound
right?
> > > Anyone
> > > >> have
> > > >> >> >> some
> > > >> >> >> > additional thoughts?
> > > >> >> >> >
> > > >> >> >> > Rich, do you have some input on this AP change?
> > > >> >> >> >
> > > >> >> >> > Thanks,
> > > >> >> >> > Carlin
> > > >> >> >> >
> > > >> >> >>
> > > >> >> >
> > > >> >>
> > > >> >
> > > >>
> > > >
> > >
> > >
> > >
> >
>

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