You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by Patrick Moore <tr...@gmail.com> on 2006/10/13 06:02:52 UTC
Component resolution question
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.
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: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Component resolution question
Posted by Ryan Holmes <ry...@hyperstep.com>.
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
the same thing (override some contrib components but reuse the class)
and still couldn't come up with it.
Must... read... more... slowly
-Ryan
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Component resolution question
Posted by andyhot <an...@di.uoa.gr>.
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 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.
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...
But this doesn't mean we aren't looking for ways to make this easier for
users...
We just have to make sure that (given the way things currently work) no
problems
are introduced - and IMHO this is exactly what will happen if we even try to
resolve component types from classes.
--
Andreas Andreou - andyhot@apache.org - http://andyhot.di.uoa.gr
Tapestry / Tacos developer
Open Source / J2EE Consulting
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Component resolution question
Posted by Patrick Moore <tr...@gmail.com>.
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/06, Ryan Holmes <ry...@hyperstep.com> wrote:
> 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 component
> resolution logic in ComponentAnnotationWorker when you don't specify
> a 'type' parameter. If you look at the ComponentAnnotationWorker
> source, you can see that Method.getReturnType().getSimpleName() is
> used to guess the component type if the 'type' parameter is an empty
> string. It's sort of a "best effort" approach, apparently provided as
> a convenience for those cases where the 'type' parameter is
> completely redundant with your method's return type.
>
> As Andreas mentioned, many components have BaseComponent as their
> class. Obviously, Tapestry cannot resolve a method return type of
> BaseComponent to a specific component. In those cases, the behavior
> is so ambiguous that it's useless.
>
> Even when your component has a specific class, you could conceivably
> have situations where your Tapestry component type differs from the
> return type of your @Component annotated method (although I can't
> honestly think of a use-case that makes good sense, even with a
> component class hierarchy).
>
> Having said all that, 'type' is indeed redundant in many cases and it
> would be great if it there was a better way. In the meantime, I would
> actually prefer to have only one way to specify the type of a
> component (not that I'm really complaining about the current
> "component type guessing" behavior -- I just probably won't use it).
> In short, getting rid of the 'type' parameter or significantly
> changing component resolution logic seems more like a Tap 5 thing and
> I'm more interested in seeing 4.1 stabilize.
>
>
> Regarding Eclipse refactoring, the 'type' parameter's value does not
> need to be fully qualified to be detected. For example, the type
> parameters in the following @Component methods will be updated
> correctly if you check the "Update textual occurrences in comments
> and strings" box:
>
> @Component(type = "FlushLiquidSystem", bindings =
> "poolSet=prop:poolSet")
> public abstract FlushLiquidSystem getFlushLiquidSystem();
>
> -- or --
>
> @Component(type = "directoryThatDoesNotMatchThePackageName/
> FlushLiquidSystem", bindings = "poolSet=prop:poolSet")
> public abstract FlushLiquidSystem getFlushLiquidSystem();
>
>
> I'm using Eclipse 3.2 and this works for @InjectPage annotations as
> well. It's obviously not as robust as regular type refactoring and
> you have to pay attention to the preview, but it does make the
> process pretty easy. Let me know if your experience is different,
> because this is an extremely handy feature.
>
> I don't mean to dampen your enthusiasm to make improvements and I
> think everyone has noticed that 'type' feels oddly redundant. It's
> just that it makes sense when you step back and realize that a
> Tapestry component type is not the same as Java type, except when it
> is ;)
>
> -Ryan
>
> On Oct 16, 2006, at 10:22 AM, 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 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 <ry...@hyperstep.com> 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.getNaviga
> >> t
> >> > ion().
> >> >
> >> > -Pat
> >> >
> >> > On 10/13/06, Norbert Sándor <de...@erinors.com> 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 <tr...@gmail.com>
> >> 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: users-unsubscribe@tapestry.apache.org
> >> >> >> For additional commands, e-mail: users-help@tapestry.apache.org
> >> >> >>
> >> >> >>
> >> >> >>
> >> >> >
> >> >> >
> >> >> >
> >> >>
> >> >>
> >> >>
> >> ---------------------------------------------------------------------
> >> >> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> >> >> For additional commands, e-mail: users-help@tapestry.apache.org
> >> >>
> >> >>
> >> >
> >> >
> >> ---------------------------------------------------------------------
> >> > To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> >> > For additional commands, e-mail: users-help@tapestry.apache.org
> >> >
> >>
> >>
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> >> For additional commands, e-mail: users-help@tapestry.apache.org
> >>
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> > For additional commands, e-mail: users-help@tapestry.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Component resolution question
Posted by Ryan Holmes <ry...@hyperstep.com>.
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 component
resolution logic in ComponentAnnotationWorker when you don't specify
a 'type' parameter. If you look at the ComponentAnnotationWorker
source, you can see that Method.getReturnType().getSimpleName() is
used to guess the component type if the 'type' parameter is an empty
string. It's sort of a "best effort" approach, apparently provided as
a convenience for those cases where the 'type' parameter is
completely redundant with your method's return type.
As Andreas mentioned, many components have BaseComponent as their
class. Obviously, Tapestry cannot resolve a method return type of
BaseComponent to a specific component. In those cases, the behavior
is so ambiguous that it's useless.
Even when your component has a specific class, you could conceivably
have situations where your Tapestry component type differs from the
return type of your @Component annotated method (although I can't
honestly think of a use-case that makes good sense, even with a
component class hierarchy).
Having said all that, 'type' is indeed redundant in many cases and it
would be great if it there was a better way. In the meantime, I would
actually prefer to have only one way to specify the type of a
component (not that I'm really complaining about the current
"component type guessing" behavior -- I just probably won't use it).
In short, getting rid of the 'type' parameter or significantly
changing component resolution logic seems more like a Tap 5 thing and
I'm more interested in seeing 4.1 stabilize.
Regarding Eclipse refactoring, the 'type' parameter's value does not
need to be fully qualified to be detected. For example, the type
parameters in the following @Component methods will be updated
correctly if you check the "Update textual occurrences in comments
and strings" box:
@Component(type = "FlushLiquidSystem", bindings =
"poolSet=prop:poolSet")
public abstract FlushLiquidSystem getFlushLiquidSystem();
-- or --
@Component(type = "directoryThatDoesNotMatchThePackageName/
FlushLiquidSystem", bindings = "poolSet=prop:poolSet")
public abstract FlushLiquidSystem getFlushLiquidSystem();
I'm using Eclipse 3.2 and this works for @InjectPage annotations as
well. It's obviously not as robust as regular type refactoring and
you have to pay attention to the preview, but it does make the
process pretty easy. Let me know if your experience is different,
because this is an extremely handy feature.
I don't mean to dampen your enthusiasm to make improvements and I
think everyone has noticed that 'type' feels oddly redundant. It's
just that it makes sense when you step back and realize that a
Tapestry component type is not the same as Java type, except when it
is ;)
-Ryan
On Oct 16, 2006, at 10:22 AM, 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 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 <ry...@hyperstep.com> 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.getNaviga
>> t
>> > ion().
>> >
>> > -Pat
>> >
>> > On 10/13/06, Norbert Sándor <de...@erinors.com> 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 <tr...@gmail.com>
>> 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: users-unsubscribe@tapestry.apache.org
>> >> >> For additional commands, e-mail: users-help@tapestry.apache.org
>> >> >>
>> >> >>
>> >> >>
>> >> >
>> >> >
>> >> >
>> >>
>> >>
>> >>
>> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> >> For additional commands, e-mail: users-help@tapestry.apache.org
>> >>
>> >>
>> >
>> >
>> ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> > For additional commands, e-mail: users-help@tapestry.apache.org
>> >
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: users-help@tapestry.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Component resolution question
Posted by Patrick Moore <tr...@gmail.com>.
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 <ry...@hyperstep.com> 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 <de...@erinors.com> 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 <tr...@gmail.com> 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: users-unsubscribe@tapestry.apache.org
> >> >> For additional commands, e-mail: users-help@tapestry.apache.org
> >> >>
> >> >>
> >> >>
> >> >
> >> >
> >> >
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> >> For additional commands, e-mail: users-help@tapestry.apache.org
> >>
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> > For additional commands, e-mail: users-help@tapestry.apache.org
> >
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Component resolution question
Posted by Ryan Holmes <ry...@hyperstep.com>.
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 <de...@erinors.com> 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 <tr...@gmail.com> 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: users-unsubscribe@tapestry.apache.org
>> >> For additional commands, e-mail: users-help@tapestry.apache.org
>> >>
>> >>
>> >>
>> >
>> >
>> >
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: users-help@tapestry.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Component resolution question
Posted by Patrick Moore <tr...@gmail.com>.
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.getNavigation().
-Pat
On 10/13/06, Norbert Sándor <de...@erinors.com> 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 <tr...@gmail.com> 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: users-unsubscribe@tapestry.apache.org
> >> For additional commands, e-mail: users-help@tapestry.apache.org
> >>
> >>
> >>
> >
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Component resolution question
Posted by Norbert Sándor <de...@erinors.com>.
> 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 <tr...@gmail.com> 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: users-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: users-help@tapestry.apache.org
>>
>>
>>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Component resolution question
Posted by andyhot <an...@di.uoa.gr>.
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 <tr...@gmail.com> 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: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
--
Andreas Andreou - andyhot@apache.org - http://andyhot.di.uoa.gr
Tapestry / Tacos developer
Open Source / J2EE Consulting
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Component resolution question
Posted by Patrick Moore <tr...@gmail.com>.
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 <tr...@gmail.com> 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.
>
> 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: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org