Thanks Nick - you're right, i should have looked over list and jira first: http://thread.gmane.org/gmane.comp.java.tapestry.user/51015 https://issues.apache.org/jira/browse/TAPESTRY-1679
I agree that 'configure' is a step forward - configureRequestHandler() is better than contributeRequestHandler(). I think i see what you mean by tapestry-ioc calling 'something' a configuration - the arguments to contributor methods are of type Configuration, OrderedConfiguration or MappedConfiguration. Is that what you mean? What i heard Howard saying is that it might be helpful to allow the contributor method name itself to describe what is being contributed, hence my suggestion of, eg: contributeTimingFilterToRequestHandler(). This is particularly helpful when i have a single, specific contribution to make. For cases where i can make multiple contributions from within a single method, or the specificity is unnecessary, i could fall back on just: contributeToRequestHandler(). I apoligize if i'm rehashing an old discussion - the threads i found hadn't spawned much discussion, but i could just have missed the interesting ones. Also, a quick question about protocol: once an issue has been logged on jira, do y'all prefer to move discussions there? I'm (a few months) new to the community so would appreciate direction. Thanks, lasitha. On 10/15/07, Nick Westgate <[EMAIL PROTECTED]> wrote: > Tapestry-ioc already calls the "something" a configuration: > http://tapestry.apache.org/tapestry5/tapestry-ioc/configuration.html > > so Howard's "configure" naming suggestion looks even better. > (This has been discussed previously in this list.) > > Cheers, > Nick. > > > lasitha wrote: > > Howard, > > > > Just in case that was an invitation for proposals :), how about: > > contributeSomethingToSomeService(), where 'Something' is optional? > > > > Allows for a little more specificity while still being an easily > > parsed convention. And for those that don't care - its only two more > > characters :) > > > > In any case, +1 for not leaving it as is. > > > > Cheers, > > lasitha > > > > Oh, p.s - immeasurable thanks for T5! > > > > On 10/14/07, Howard Lewis Ship <[EMAIL PROTECTED]> wrote: > >> Where I dropped the ball here, in a minor way, is that it should be > >> "contributeTo" as a prefix, or perhaps "configure". It's a prefix on the > >> *service* being configured or contributed to. So I would choose option #2 > >> or #3. > >> > >> I wonder if there's some value in something like: > >> > >> @Contribute(FooBar.class) > >> public void whatWouldYouCallThis(Configuration<FooBarDatum> configuration) > >> { > >> ... } > >> > >> This is heading a bit backwards from my initial goals, of naming > >> conventions > >> over annotations, and raises the question of the convention for naming such > >> methods, but it would allow for more pleasing names such as > >> "contributeLoggingFilter" (with the annotation) vs. > >> "contributeRequestHandler" (which gives no indication what is being > >> contributed). > >> > >> > >> On 10/12/07, Dan Adams <[EMAIL PROTECTED]> wrote: > >>> Let's say you have a service that allows multiple contributions. One of > >>> the contributions is simply a list of other objects (say an ordered > >>> configuration). What is the naming convention for the configuration > >>> point for that list of objects? For instance, lets say you want to have > >>> a list of FooBars contributed. Which of the following is recommended: > >>> > >>> contributeFooBars() > >>> > >>> contributeFooBarManager() > >>> > >>> contributeMasterFooBar() > >>> > >>> or would you recommend something else entirely? I think I like the first > >>> one simply because it more readable in the modules that are > >>> contributing. > >>> > >>> -- > >>> Dan Adams > >>> Senior Software Engineer > >>> Interactive Factory > >>> 617.235.5857 > >>> > >>> > >>> --------------------------------------------------------------------- > >>> To unsubscribe, e-mail: [EMAIL PROTECTED] > >>> For additional commands, e-mail: [EMAIL PROTECTED] > >>> > >>> > >> > >> -- > >> Howard M. Lewis Ship > >> Partner and Senior Architect at Feature50 > >> > >> Creator Apache Tapestry and Apache HiveMind > >> > > > > --------------------------------------------------------------------- > > 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]
