On Oct 16, 2006, at 2:13 PM, andyhot wrote:
Here's another:
I've seen (and even written) components that provide nicer gui on top
of contrib:Table. They all usually define the same component class as
contrib:Table
does...
Interesting, that's the use case I couldn't think of ;) I actually do
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)
Patrick Moore wrote:
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
Hi Patrick,
I was referring to the class resolution ambiguity you encountered in
your Navigation example. Had you specified the 'type' parameter, you
would be forced to indicate whether you meant 'Navigation' or
'members/Navigation'.
Specifically, I was talking about the ambiguity in the
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
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
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,
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
