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 --
I am not saying that the type parameter can be discarded. Andrei and
you have both made the case that there are cases of ambiguity that
need the type parameter. I am saying that for me so far the component
resolution has been sorely lacking.
anyhow enough on this for now...
On 10/16/
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
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 fu
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)
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 th
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
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.
>
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 T
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
10 matches
Mail list logo
