RE: [Xdoclet-user] XDoclet with subclasses - dangerous?

[Mike Cannon-Brookes]

(I just delved into the WebWork codebase for 10 minutes, but it's very hard
to get a handle on what does what in the generation process ;))

Having said that, I just got Dmitri's email and tried messing with purely
tags in the template - lo and behold, powerful new XDoclet features! ;)

I've prefixed my modifications with <NEW> rather than <XDoclet>, tell me if
you think this will fuck anything up ;)

 <XDoclet:ifNotUsingCmp2>
 <XDoclet:forAllPersistentFields>
   <NEW:ifHasMethod name="<XDoclet:getterMethod/>"
parameters="<XDoclet:methodType/>">
           <NEW:ifIsAbstract>
                        public <XDoclet:methodType/> <XDoclet:propertyName/>;
           </NEW:ifIsAbstract>
   </NEW:ifHasMethod>
 </XDoclet:forAllPersistentFields>

 <XDoclet:forAllPersistentFields>
   public <XDoclet:methodType/>
<XDoclet:getterMethod/>()<XDoclet:exceptionList/>
   {
   <NEW:ifIsAbstract>
                return this.<XDoclet:propertyName/>;
   </NEW:ifIsAbstract>
   <NEW:ifIsNotAbstract>
                return super.<XDoclet:getterMethod/>();
   </NEW:ifIsNotAbstract>
   }

  <XDoclet:ifHasMethod name="<XDoclet:setterMethod/>"
parameters="<XDoclet:methodType/>">

   public void <XDoclet:setterMethod/>( <XDoclet:methodType/>
<XDoclet:propertyName/> )<XDoclet:exceptionList
method="<XDoclet:setterMethod/>"/>
   {
   <NEW:ifIsAbstract>
                this.<XDoclet:propertyName/> = <XDoclet:propertyName/>;
   </NEW:ifIsAbstract>
   <NEW:ifIsNotAbstract>
                super.<XDoclet:setterMethod/>(<XDoclet:propertyName/>);
   </NEW:ifIsNotAbstract>

      makeDirty();
     <XDoclet:ifIsWithDataContainer>
      dataHolder = null;
     </XDoclet:ifIsWithDataContainer>
   }

  </XDoclet:ifHasMethod>

 </XDoclet:forAllPersistentFields>
 </XDoclet:ifNotUsingCmp2>

wow - I can feel the power, four or five changes and IMHO XDoclet will not
only generate abstract methods, all other non abstract methods are delegated
to parent class! ;)

Here's an example generated non-abstract getter / setter pair:

   public java.util.Locale getLocale()
   {
                return super.getLocale();
   }

   public void setLocale( java.util.Locale locale )
   {
                super.setLocale(locale);

      makeDirty();
   }

IMHO it should still makeDirty() so I left that in. Also this does not
create a field in the subclass, but it does still generate all fields
(superclass and generated) in ejb-jar.xml and dataobjects.

Again - wow, I love this project more and more ;)


-mike


Mike Cannon-Brookes :: [EMAIL PROTECTED]

Atlassian :: http://www.atlassian.com
     Supporting YOUR J2EE World



> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Mike
> Cannon-Brookes
> Sent: Friday, October 19, 2001 11:00 AM
> To: Dmitri Colebatch
> Cc: Ara Abrahamian; [EMAIL PROTECTED]
> Subject: RE: [Xdoclet-user] XDoclet with subclasses - dangerous?
>
>
> Sure it does - that's the way I personally would _expect_ it to work?
>
> Where should I start looking? ;)
>
> -mike
>
>
> Mike Cannon-Brookes :: [EMAIL PROTECTED]
>
> Atlassian :: http://www.atlassian.com
>      Supporting YOUR J2EE World
>
>
>
> > -----Original Message-----
> > From: [EMAIL PROTECTED]
> > [mailto:[EMAIL PROTECTED]]On Behalf Of Dmitri
> > Colebatch
> > Sent: Friday, October 19, 2001 10:48 AM
> > To: Mike Cannon-Brookes
> > Cc: Ara Abrahamian; [EMAIL PROTECTED]
> > Subject: RE: [Xdoclet-user] XDoclet with subclasses - dangerous?
> >
> >
> > On Fri, 19 Oct 2001, Mike Cannon-Brookes wrote:
> >
> > >
> > > How can I tell XDoclet to 'ignore bar in the generation and
> trust me it
> > > already exists'? I want it to churn out code in C like :
> > >
> > >   public Foo getBar()
> > >   {
> > >           return super.getBar();
> > >   }
> > >
> > > I have a sneaking suspicion that you're going to tell me it's just not
> > > possible - which bites bigtime because it rules a lot of EJBs
> > out of being
> > > XDoclet generated.
> > >
> >
> > its not possible atm out of the box, but there's no reason why you
> > couldn't implement it.  If all your ejbs follow this model you
> could just
> > change the template to produce the code you want.  Or, you could change
> > the template to check to see if super.getBar is not abstract,
> and call the
> > code based on that.  THe second approach is something that could become
> > part of the project so that others have the benefit too.
> >
> > does that make sense?
> >
> > cheesr
> > dim
> >
> >
> > _______________________________________________
> > Xdoclet-user mailing list
> > [EMAIL PROTECTED]
> > https://lists.sourceforge.net/lists/listinfo/xdoclet-user
>
>
> _______________________________________________
> Xdoclet-user mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/xdoclet-user


_______________________________________________
Xdoclet-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/xdoclet-user