We could work like Spring and specify a list of packages to scan in the configuration set up...
Will On Saturday, December 25, 2010, Nathan Bubna <[email protected]> wrote: > Most examples i know involve classpath scanning at startup, so runtime > performance isn't a concern. I suppose we could do likewise and scan > the whole classpath at startup looking for @Template<Type> and @Render > method annotations at startup. But again, that seems like overkill > for the feature in question. > > On Sat, Dec 25, 2010 at 10:00 AM, Will Glass-Husain > <[email protected]> wrote: >> The main advantage is convention. Java development has clearly shifted >> towards annotations as a way to handle exactly this type of issue. >> >> Having said that, either approach seems reasonable to me. >> >> WILL >> >> On Sat, Dec 25, 2010 at 11:22 AM, Nathan Bubna <[email protected]> wrote: >> >>> Yeah, they're nice, but i'm actually having second thoughts about >>> offering them due to performance/complexity concerns. Scanning the >>> class heirarchy of each reference value for an invokable method with >>> the right annotation (and, hopefully, signature) seems like a bad >>> idea. Even if the results are cached by Class, it seems like a lot of >>> work just to give users flexibility about which method they want to >>> use. I think we'd need to have a convincing reason that annotations >>> are clearly superior to the getAs<Type> convention, which also plays >>> nicer with keeping the interfaces available. >>> >>> On Sat, Dec 25, 2010 at 7:16 AM, Will Glass-Husain >>> <[email protected]> wrote: >>> > I like the annotations idea a lot. >>> > >>> > Annotations are pretty mainstream by now, and also very convenient. >>> > >>> > Will >>> > >>> > P.S. Happy Christmas! >>> > >>> > On Friday, December 24, 2010, Nathan Bubna <[email protected]> wrote: >>> >> Ok, we've taken some good steps toward this in the past (via >>> >> Renderable, TemplateNumber, get, put, and good ol' toString(). With >>> >> 2.0, it's long been a major goal of mine to step it up a bit. There >>> >> are options. I have my opinions, but thought it best to consult ya'll >>> >> before i started in on it. >>> >> >>> >> 1) add missing interfaces: TemplateString, TemplateBoolean >>> >> 2) annotations: �...@templatenumber, @TemplateString, @TemplateBoolean, >>> >> @TemplateRender >>> >> 3) convention: getAsString(), getAsNumber(), getAsBoolean(), >>> >> render(context, writer) >>> >> >>> >> #1 is great for people who want compile-time checking, but makes >>> >> velocity a runtime dep for users. i am not content to leave it at >>> >> that, but i am willing to keep and complete the interfaces if people >>> >> still find them useful. >>> >> >>> >> #2 lets people name methods whatever they want, but makes velocity a >>> >> compile-time dep for users. >>> >> >>> >> #3 no dependency, but no compile time guards. this is also more the >>> >> way we've been doing things. >>> >> >>> >> i am willing to do #1 with either #2 or #3, but not all three >>> >> together. i'm also perfectly happy to drop the TemplateNumber >>> >> interface and discourage external use of Renderable, if people see >>> >> little use in them. performance is a concern for the string/render >>> >> stuff, as the check will happen for every non-String value that >>> >> results from a $reference evaluation. and the boolean check will >>> >> happen for every #if( $ref ). number checks will of course happen >>> >> anytime math is involved. >>> >> >>> >> also, we might later want to discuss if we want to apply these >>> >> checks/conversions to $method.expectsBoolean($hasGetAsBoolean). i >>> >> think we should, but we haven't done that in the past, so it's not my >>> >> first priority. >>> >> >>> >> --------------------------------------------------------------------- >>> >> To unsubscribe, e-mail: [email protected] >>> >> For additional commands, e-mail: [email protected] >>> >> >>> > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
