Hi Ryan -- Eclipse can look for fully specified names but 'members/Navigation' isn't fully specified. The component specification looks like:
@Component(type="member/Navigation") public Navigation getNavigation(); (FYI, in my example I was only giving the full flassname for illustration only) You talk about the ambiguity if the 'type' parameter isn't specified. What ambiguity are you refering to? I haven't encountered a single example of such ambiguity yet. The only case I have heard of is the template-only components. But that isn't an issue for me as those components I specify anonymously in my html template. So in my situation, the type parameter is merely a source of run-time bugs when Tapestry can find a component. -Pat On 10/14/06, Ryan Holmes <[EMAIL PROTECTED]> wrote:
Actually, eclipse will pick up @Component 'type' values during refactoring if you check the "Update textual occurrences in comments and strings" option when you rename a component class. The "bug" you illustrate is a good example of why the type parameter should be required, at least for the time being. If the @Component annotation worker could resolve class names as you expect, perhaps making 'type' optional would be nice. Of course, you also wouldn't need to do : @Component public abstract com.transparentpolitics.core.web.components.members.Navigation getNavigation(); as it's no different than: import com.transparentpolitics.core.web.components.members.Navigation public abstract Navigation getNavigation(); I think there are more important things to be done in Tap 4.1 and I prefer the predictable behavior of the 'type' parameter (which, as I mentioned, is refactorable in Eclipse) over the more elegant but potentially ambiguous behavior that arises when omitting 'type'. Just my $.02 -Ryan On Oct 13, 2006, at 10:19 AM, Patrick Moore wrote: > I would vote just the opposite way. In this case I am returning the > exact type that is declared on the abstract method. I am not returning > a BaseComponent. I hate the 'type' parameter. It interfers with > refactoring because eclipse doesn't know it should do anything with > the type parameter. So far 100% of the times where I had to specify > the type hasn't needed any clarification. The coding style I am using > means that I never use the .jwc/.page files, only annotations. > > The current behavior points out a Tapestry bug as well. > > 1. Declare a method: > > @Component > public abstract > com.transparentpolitics.core.web.components.members.Navigation > getNavigation(); > > 2. Declare the classes: > com.transparentpolitics.core.web.components.members.Navigation > and > com.transparentpolitics.core.web.components.Navigation > > 3. Declare the component-class-packages: > <meta key="org.apache.tapestry.component-class-packages" > value="com.transparentpolitics.web.components"/> > > If Tapestry looks at the > com.transparentpolitics.core.web.components.members.Navigation class > file, it can see that it has been annotated correctly and it should > chose the class, > com.transparentpolitics.core.web.components.members.Navigation, not > com.transparentpolitics.core.web.components.Navigation. > > However, Tapestry gets really wigged out and throws this exception: > > Property navigation has already been accounted for by the element at > Annotation @org.apache.tapestry.annotations.Parameter(cache=true, > defaultValue=, required=true, name=, aliases=) of public abstract > com.transparentpolitics.web.components.member.Navigation > com.transparentpolitics.web.components.member.NonflowBorder.getNavigat > ion(). > > -Pat > > On 10/13/06, Norbert Sándor <[EMAIL PROTECTED]> wrote: >> > If this causes confusions , i'm 100% for making type required >> again. >> >> I would vote a +1 for changing "type" back to required, mainly >> because of new users. >> >> Discarding "type" results in less readable code for example when >> compared to omitting @InjectObject, which has a more implicit >> meaning. >> >> >So, in a word, Tapestry cannot use the class name (neither the >> simple >> nor the full) >> This may not be evident for new users, especially when they read >> in the >> docs that Tapestry supports pure-java, annotation-only components... >> >> IMO >> >> Regards, >> Norbi >> >> andyhot wrote: >> > Patrick Moore wrote: >> > >> >> To my untrained eye, it looks like the problem is that the >> >> _componentResolver on line 390 of >> >> org.apache.tapestry.pageload.PageLoader doesn't have the full >> class >> >> name. >> >> >> >> On 10/12/06, Patrick Moore <[EMAIL PROTECTED]> wrote: >> >> >> >>> Hi there -- >> >>> >> >>> I just shifted over to Tap 4.1.1 and I was hoping I could get >> rid of >> >>> the use of 'type' in my @Component annotation. But no such luck. >> >>> >> > >> > It's not a matter of luck... You can simply have many components >> all >> > sharing the same class. Think for instance all those template-only >> > components... >> > their class is BaseComponent. >> > >> > So, in a word, Tapestry cannot use the class name (neither the >> simple >> > nor the full) >> > in order to make apart a component. It always needs the type. >> > >> > type has been made optional to facilitate cases where it matches >> the >> > class name. >> > I believe that's what stated at >> > http://tapestry.apache.org/tapestry4.1/tapestry-annotations/ >> index.html >> > If this causes confusions , i'm 100% for making type required >> again. >> > >> > >> > >> >>> In my application file I indicate that the components are in the >> >>> 'com.transparentpolitics.web.components' directory (or its >> >>> subdirectories). However, Tap doesn't find components that are in >> >>> child directories of the 'com ... components' directory. So >> component >> >>> references like this: >> >>> >> >>> @Component >> >>> public abstract Navigation getNavigation() >> >>> >> >>> don't work but this does work : >> >>> >> >>> @Component(type="utils/Navigation") >> >>> public abstract Navigation getNavigation() >> >>> >> >>> (Navigation is >> >>> 'com.transparentpolitics.core.web.components.util.Navigation') >> >>> Now I don't understand why Tap can't find the component as the >> method >> >>> call returns the exact component class. Is this just a known >> temporary >> >>> limit? Or would changing this current behavior to look at the >> actual >> >>> class supplied cause problems? >> >>> >> >>> I do know that I can list out each child component directory >> but that >> >>> has its own problem as there are some cases of duplicate class >> names. >> >>> In any case all the information is on that annotated method call. >> >>> >> >>> -Pat >> >>> >> >>> >> >> >> --------------------------------------------------------------------- >> >> 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] > --------------------------------------------------------------------- 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]
