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]
