That saves some processing but adds complexity for users and us. I think the fundamental difference here between this and most annotation setups is that this is just about rendering objects and is meant to be a completely optional feature of a component library for the view layer. It is far more common to use method annotations for controller location/config in frameworks. So while both involve identify the method meant to be used for a function, the reality is that this feature just isn't worth the level of effort/complexity inherent in using annotations for it.
Given the way that #3 (for those who dislike dependencies) can work seamlessly with #1 (which offers the best compile time checks for those who like them), that's the way i'm going to implement it. On Sat, Dec 25, 2010 at 6:06 PM, Will Glass-Husain <[email protected]> wrote: > 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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
