Getting more out of annotation processors

[Gavin King-3]

Folks, as we start work on Seam3, and the tooling for Seam3, we need
to look out for opportunities to get more out of annotation
processors. They can help us solve certain problems that we weren't
able to easily solve in the past.

One thing I would definitely like us to do is DAO generation. What I'm
thinking of is like a next generation version of the "framework"
package in Seam. For example, for each entity like Customer we could
generate a class CustomerHome extending EntityHome and adding typesafe
finder methods (findByName() and friends). Of course, the user could
extend and specialize this generated class to override or add extra
functionality.

It would even be possible to generate JSF composite components for
each entity, i.e. <e:displayCustomer/>, <e:editCustomer/>,
<e:displayCustomerAsRow/>.

Of course, all this would need to work nicely in Eclipse.

--
Gavin King
gavin.king@...
http://in.relation.to/Bloggers/Gavin
http://hibernate.org
http://seamframework.org
_______________________________________________
seam-dev mailing list
seam-dev@...
https://lists.jboss.org/mailman/listinfo/seam-dev

[Max Rydahl Andersen-2]

Just be aware annotation processors have one big limitation...it will
only generate code based on *source*, not on
available classes in the classpath.

This make it impossible (or at least very hard and clumsy) to use on
projects that have i.e. entities in one project,
dao in another and view in a third.

i.e. each "module" can generate their 'piece', but if you want the
annotation processor to generate something based
on 'cross-module-info', i.e. take the entities+dao to generate a
matching view layer then you are limited to
guessing what is in one of the two...

I realized this limitation when I wanted to try to generate a graph of
webbeans dependencies, I wouldn't see
any of the already compiled and dependent named beans from i.e. the
core, making it a rather boring graph ;)

/max

Gavin King wrote:

> Folks, as we start work on Seam3, and the tooling for Seam3, we need
> to look out for opportunities to get more out of annotation
> processors. They can help us solve certain problems that we weren't
> able to easily solve in the past.
>
> One thing I would definitely like us to do is DAO generation. What I'm
> thinking of is like a next generation version of the "framework"
> package in Seam. For example, for each entity like Customer we could
> generate a class CustomerHome extending EntityHome and adding typesafe
> finder methods (findByName() and friends). Of course, the user could
> extend and specialize this generated class to override or add extra
> functionality.
>
> It would even be possible to generate JSF composite components for
> each entity, i.e.<e:displayCustomer/>,<e:editCustomer/>,
> <e:displayCustomerAsRow/>.
>
> Of course, all this would need to work nicely in Eclipse.
>
>    

_______________________________________________
seam-dev mailing list
seam-dev@...
https://lists.jboss.org/mailman/listinfo/seam-dev

[Max Rydahl Andersen-2]

FYI: our current approach with using hibernate entitymanager to scan for
entities avoids this issue about not having
access to all the information since the entitiymanager actively scans
for entities.

And generating JSF components and typesafe dao's is easier from our
current approach. I'm not sure
what "help us solve problems that we weren't able to easily solve in the
past" means ? Generating
typesafe DAO's is definitely possible today ...not sure why you don't
think that is possible ? Same with JSF

If what you are looking for is a quicker generation (i.e. only delta)
then that is something we are working
on for next release of Hibernate tools by making it possible to only
generate for a subset of classes (note,
we still need to read the whole model to ensure we know the associations)

What we can't do today is to participate in the compile phase and inject
additional phases....but is that
really something you want to do *always* for view and data access code...?

/max

Max Rydahl Andersen wrote:

> Just be aware annotation processors have one big limitation...it will
> only generate code based on *source*, not on
> available classes in the classpath.
>
> This make it impossible (or at least very hard and clumsy) to use on
> projects that have i.e. entities in one project,
> dao in another and view in a third.
>
> i.e. each "module" can generate their 'piece', but if you want the
> annotation processor to generate something based
> on 'cross-module-info', i.e. take the entities+dao to generate a
> matching view layer then you are limited to
> guessing what is in one of the two...
>
> I realized this limitation when I wanted to try to generate a graph of
> webbeans dependencies, I wouldn't see
> any of the already compiled and dependent named beans from i.e. the
> core, making it a rather boring graph ;)
>
> /max
>
> Gavin King wrote:
>> Folks, as we start work on Seam3, and the tooling for Seam3, we need
>> to look out for opportunities to get more out of annotation
>> processors. They can help us solve certain problems that we weren't
>> able to easily solve in the past.
>>
>> One thing I would definitely like us to do is DAO generation. What I'm
>> thinking of is like a next generation version of the "framework"
>> package in Seam. For example, for each entity like Customer we could
>> generate a class CustomerHome extending EntityHome and adding typesafe
>> finder methods (findByName() and friends). Of course, the user could
>> extend and specialize this generated class to override or add extra
>> functionality.
>>
>> It would even be possible to generate JSF composite components for
>> each entity, i.e.<e:displayCustomer/>,<e:editCustomer/>,
>> <e:displayCustomerAsRow/>.
>>
>> Of course, all this would need to work nicely in Eclipse.

_______________________________________________
seam-dev mailing list
seam-dev@...
https://lists.jboss.org/mailman/listinfo/seam-dev

[Max Rydahl Andersen-2]

Gavin, I'm still wondering what it is you were thinking annotation
processors would do better considering the rather
big limitations they have ?

/max


Max Rydahl Andersen wrote:

> Just be aware annotation processors have one big limitation...it will
> only generate code based on *source*, not on
> available classes in the classpath.
>
> This make it impossible (or at least very hard and clumsy) to use on
> projects that have i.e. entities in one project,
> dao in another and view in a third.
>
> i.e. each "module" can generate their 'piece', but if you want the
> annotation processor to generate something based
> on 'cross-module-info', i.e. take the entities+dao to generate a
> matching view layer then you are limited to
> guessing what is in one of the two...
>
> I realized this limitation when I wanted to try to generate a graph of
> webbeans dependencies, I wouldn't see
> any of the already compiled and dependent named beans from i.e. the
> core, making it a rather boring graph ;)
>
> /max
>
> Gavin King wrote:
>> Folks, as we start work on Seam3, and the tooling for Seam3, we need
>> to look out for opportunities to get more out of annotation
>> processors. They can help us solve certain problems that we weren't
>> able to easily solve in the past.
>>
>> One thing I would definitely like us to do is DAO generation. What I'm
>> thinking of is like a next generation version of the "framework"
>> package in Seam. For example, for each entity like Customer we could
>> generate a class CustomerHome extending EntityHome and adding typesafe
>> finder methods (findByName() and friends). Of course, the user could
>> extend and specialize this generated class to override or add extra
>> functionality.
>>
>> It would even be possible to generate JSF composite components for
>> each entity, i.e.<e:displayCustomer/>,<e:editCustomer/>,
>> <e:displayCustomerAsRow/>.
>>
>> Of course, all this would need to work nicely in Eclipse.

_______________________________________________
seam-dev mailing list
seam-dev@...
https://lists.jboss.org/mailman/listinfo/seam-dev