beehive-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rich Feit <>
Subject Re: adding NetUI annotation processing for an external form bean class in check() phase
Date Tue, 15 Aug 2006 17:29:16 GMT

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?


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 <> 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
>> >

View raw message