> >what's ugly about it? As I understand it, Ara's criticism is over the > >placement of constants in an interface. atm, we have > >finders: > > > > @ejb:finder query="java.util.Collection findAll()" > > Ah, what I thought ugly was placing something that's pure Java into a > comment and into the xdoclet description of the bean. You have to quote > citation marks and you don't get the highlighting of code the editor > normally gives you. I would say that the same thing goes for finder in a way.
true... I'm not going to argue that (o: > > What I think is ugly is having the same field declaration in > >the bean class as in the interface. Alternatively, Ara's suggestion of > >using a constants class is obviously also a perfectly valid > >way of doing things. > > Since the field is final static is not like a variable as such but as a > name for something. Therefore I don't think it's too ugly to have the same > constant in several places since they have a common root and can't be out > of sync. I see it more like #defines in a header file in C/C++ that are > included in several .c-files. I like that better than having to refer to a > file (the interface) that haven't been generated yet. Since the interfaces > are generated from the bean class, I would like to keep dependencies the > other way, from the bean class on the interfaces, at a minimum. ok, I'll agree to disagree on that one. [snip] > Not that it's of religious importance. If it's done in another way I'll use > that. I just don't have to think that it's the best way? ;-) (o: same for me. the options I see are : (a) do nothing, and use constants class (b) your suggestion of using fields int he ejb, and replicating in interfaces (c) my suggestion of finder style declarations. Ara - I'll put one of these in (well, b or c) if you want to make a call as to which one it should be (or shouldn't be in the case of a). cheers dim _______________________________________________ Xdoclet-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/xdoclet-user
