You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tapestry.apache.org by Kent Tong <ke...@cpttm.org.mo> on 2006/12/10 04:28:27 UTC
T5: alowing a component to get a page by name at runtime
Hi,
In an attempt to catch up with T5 and maybe to make some small
contributions, I'm trying to port the Workbench to T5. In the
process I found that it seems impossible for a component to get
a page by name that is provided at runtime (eg, in the case of
a Tab component that knows about the names of the tab pages at
runtime only). @InjectPage requires a constant page name. I'm
thinking about making the RequestPageCache available through
the infrastructure service. Do you think this is the way to do
it?
--
Author of a book for learning Tapestry (http://www.agileskills2.org/EWDT)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: T5: alowing a component to get a page by name at runtime
Posted by Howard Lewis Ship <hl...@gmail.com>.
ComponentSource can almost do what you want. I think I'll add a few more
methods to make it easier to obtain a page given a logical page name or a
page class.
On 12/9/06, Kent Tong <ke...@cpttm.org.mo> wrote:
>
> Hi,
>
> In an attempt to catch up with T5 and maybe to make some small
> contributions, I'm trying to port the Workbench to T5. In the
> process I found that it seems impossible for a component to get
> a page by name that is provided at runtime (eg, in the case of
> a Tab component that knows about the names of the tab pages at
> runtime only). @InjectPage requires a constant page name. I'm
> thinking about making the RequestPageCache available through
> the infrastructure service. Do you think this is the way to do
> it?
>
> --
> Author of a book for learning Tapestry (http://www.agileskills2.org/EWDT)
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
>
--
Howard M. Lewis Ship
TWD Consulting, Inc.
Independent J2EE / Open-Source Java Consultant
Creator and PMC Chair, Apache Tapestry
Creator, Apache HiveMind
Professional Tapestry training, mentoring, support
and project work. http://howardlewisship.com
Re: T5: alowing a component to get a page by name at runtime
Posted by Ron Piterman <rp...@gmx.net>.
Howard Lewis Ship wrote:
> On 12/10/06, Kent Tong <ke...@cpttm.org.mo> wrote:
>
>>
>> Howard Lewis Ship <hlship <at> gmail.com> writes:
>>
>> > We could have a public PageSource interface, in infrastructure, that
>> gave
>> > access to a page's root components. The *implementation* of PageSource
>> > would know about RequestPageCache.
>>
>> OK.
>>
>> > Sounds like you're getting into the code ... any thoughts or
>> observations?
>> > I've been having a few minor problems coming up with proper names for a
>> few
>> > things, mostly on the internals side.
>>
>> Some initial observations:
>> 1) The effect of @Inject is quite hard to understand as it is
>> "overloaded" to do three different things: asset injection,
>> anonymous injection (type-based) and named injection (object ref).
>> For example, I don't understand why there is a separate @InjectPage
>> but asset is injected by @Inject instead of a separate @InjectAsset.
Sure you thought about it - but will add my 2 cent: with tapestry 4.x, I
use to create a custom annotation which injects an object using a "flavour":
@AutoInject("ejb")
public MySessionEjb getMySessionEjb();
and
@AutoInject
public IRequestCycle getRequestCycle();
the "ejb" is a configurable extention, which is then responsible to turn
the class MySessionEjb to a hivemind object locator ( this in 4.x ).
Sure, tapestry can "guess" alot, but not everything, I guess this will
be the case with ejbs or spring or whatever...
Cheers,
Ron
>
>
>
> We'll see how this works out. I really want @Inject to be "one stop
> shopping" for as much injection as possible. Much like Tapestry will adapt
> to your methods, @Inject wil adapt to your instance variables.
>
> But there's only so far you can stretch that, and I have not (yet) figured
> out how to recognize a page by its type (since pages can be almost any
> type,
> including Object).
>
>
>
> 2) It took me quite a lot of time to understand the existence and
>
>> the name of ComponentResourcesCommon. Maybe it could be renamed
>> as ComponentContext or ComponentInstance.
>
>
>
> I'm going to start cranking out tutorials soon, perhaps this will help.
> Did
> you miss the fact that
> ComponentResources extends ComponentResourcesCommon? Or the fact that an
> instance of ComponentResources is injected into your component?
>
>
>
> 3) Due to the extensive use of action links and that the context is
>
>> stored on the client, an average Tapestry app will be heavily
>> subjected to security issues. Signing the context is not effective
>> as it can be grafted into another page. Storing the state into the
>> session seems to be the only way.
>
>
>
> I'm not sure I follow you. This really is not much different than T4,
> except for how "listener parameters" (in T4) are stored as context value on
> the request path in T5. And that it's more readable (simple toString() /
> parse, rather than DataSqueezer).
>
> The fact that pages that exist to display an instance of some kind of
> entity can provide handlers for
> "passivate" and "activate" should result in more readable URLs and less
> session data (always good for dealing with the browser back button).
>
> 4) I'd like to see the PageLink coming back. It can just wrap around
>
>> an ActionLink.
>
>
>
>
> Soon!
>
> 5) I don't understand why the PagePool is using only the page name
>
>> (but not the locale) to select the page. The code in T4 should be
>> quite reusable?
>
>
>
> Soon!
>
>
> --
>
>> Author of a book for learning Tapestry (http://www.agileskills2.org/EWDT)
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: dev-help@tapestry.apache.org
>>
>>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: T5: alowing a component to get a page by name at runtime
Posted by adasal <ad...@gmail.com>.
Yes, thanks. My over reaction. Interesting to see how things are
progressing, and the way things progress.
Adam
On 13/12/06, Kent Tong <ke...@cpttm.org.mo> wrote:
>
> Howard Lewis Ship <hlship <at> gmail.com> writes:
>
> > The Loop component and a bunch of other things related to intra-form
> state
> > management is not nearly complete!
>
> Right. I think storing the ComponentActions into the session should help.
>
> --
>
> To Adam,
>
> No need to be pessimistic. T5 is still in early development and will
> be probably much different from the finished product.
>
> --
> Author of a book for learning Tapestry (http://www.agileskills2.org/EWDT)
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
>
Re: T5: alowing a component to get a page by name at runtime
Posted by Kent Tong <ke...@cpttm.org.mo>.
Howard Lewis Ship <hlship <at> gmail.com> writes:
> The Loop component and a bunch of other things related to intra-form state
> management is not nearly complete!
Right. I think storing the ComponentActions into the session should help.
--
To Adam,
No need to be pessimistic. T5 is still in early development and will
be probably much different from the finished product.
--
Author of a book for learning Tapestry (http://www.agileskills2.org/EWDT)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: T5: alowing a component to get a page by name at runtime
Posted by Howard Lewis Ship <hl...@gmail.com>.
The Loop component and a bunch of other things related to intra-form state
management is not nearly complete!
On 12/12/06, adasal <ad...@gmail.com> wrote:
>
> If this is the case it will preclude adoption of T5 in most situations.
> One of the trickiest things our team had to deal with was dynamic
> sub-components in T4 and T4.1 because there was no immediate way to index
> those components. I was involved in the solution but I think it required
> using thread local in one of the methods, in other words monitoring the
> state of the component very carefully to track dynamic changes.
> Another solution would be to maintain an index on the client with the
> backing mechanism to share id and index with the host. But not if this can
> be corrupted by a hacker.
> Adam
>
> On 12/12/06, Kent Tong <ke...@cpttm.org.mo> wrote:
> >
> >
> >
> > This is not much different than T4 in principle; it is just making
> > client-persistent state more pervasive. For example, in T4 if I'd like
> > to display some selected strings from a list to be edited in a Form,
> > I will probably store the loop source into the session for the rewind.
> > In T5, as there is no rewinding anymore, how can each TextField figure
> > out which string it should set? I guess the index has to be stored by
> > on the client. By modifying the index on the client, a hacker will be
> > able to modify strings not selected for editing.
> >
> > --
> > Author of a book for learning Tapestry (http://www.agileskills2.org/EWDT
> )
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> > For additional commands, e-mail: dev-help@tapestry.apache.org
> >
> >
>
>
--
Howard M. Lewis Ship
TWD Consulting, Inc.
Independent J2EE / Open-Source Java Consultant
Creator and PMC Chair, Apache Tapestry
Creator, Apache HiveMind
Professional Tapestry training, mentoring, support
and project work. http://howardlewisship.com
Re: T5: alowing a component to get a page by name at runtime
Posted by adasal <ad...@gmail.com>.
If this is the case it will preclude adoption of T5 in most situations.
One of the trickiest things our team had to deal with was dynamic
sub-components in T4 and T4.1 because there was no immediate way to index
those components. I was involved in the solution but I think it required
using thread local in one of the methods, in other words monitoring the
state of the component very carefully to track dynamic changes.
Another solution would be to maintain an index on the client with the
backing mechanism to share id and index with the host. But not if this can
be corrupted by a hacker.
Adam
On 12/12/06, Kent Tong <ke...@cpttm.org.mo> wrote:
>
>
>
> This is not much different than T4 in principle; it is just making
> client-persistent state more pervasive. For example, in T4 if I'd like
> to display some selected strings from a list to be edited in a Form,
> I will probably store the loop source into the session for the rewind.
> In T5, as there is no rewinding anymore, how can each TextField figure
> out which string it should set? I guess the index has to be stored by
> on the client. By modifying the index on the client, a hacker will be
> able to modify strings not selected for editing.
>
> --
> Author of a book for learning Tapestry (http://www.agileskills2.org/EWDT)
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
>
Re: T5: alowing a component to get a page by name at runtime
Posted by Kent Tong <ke...@cpttm.org.mo>.
Howard Lewis Ship <hlship <at> gmail.com> writes:
> 2) It took me quite a lot of time to understand the existence and
> > the name of ComponentResourcesCommon. Maybe it could be renamed
> > as ComponentContext or ComponentInstance.
>
> I'm going to start cranking out tutorials soon, perhaps this will help. Did
> you miss the fact that
> ComponentResources extends ComponentResourcesCommon? Or the fact that an
> instance of ComponentResources is injected into your component?
No. I believe that names like XXXCommon confuse people and are not
conveying the real meaning. The class comment doesn't really help:
Operations shared by ComponentResources and ComponentPageElement
I think something being common to X and Y doesn't have to extracted
into a single Z, particular if we can't find a good name for Z. We
could extract some subset into Z1 and another subset into Z2, so as
to give Z1 and Z2 meaningful names.
> 3) Due to the extensive use of action links and that the context is
> > stored on the client, an average Tapestry app will be heavily
> > subjected to security issues. Signing the context is not effective
> > as it can be grafted into another page. Storing the state into the
> > session seems to be the only way.
>
> I'm not sure I follow you. This really is not much different than T4,
> except for how "listener parameters" (in T4) are stored as context value on
> the request path in T5. And that it's more readable (simple toString() /
> parse, rather than DataSqueezer).
>
> The fact that pages that exist to display an instance of some kind of
> entity can provide handlers for
> "passivate" and "activate" should result in more readable URLs and less
> session data (always good for dealing with the browser back button).
This is not much different than T4 in principle; it is just making
client-persistent state more pervasive. For example, in T4 if I'd like
to display some selected strings from a list to be edited in a Form,
I will probably store the loop source into the session for the rewind.
In T5, as there is no rewinding anymore, how can each TextField figure
out which string it should set? I guess the index has to be stored by
on the client. By modifying the index on the client, a hacker will be
able to modify strings not selected for editing.
--
Author of a book for learning Tapestry (http://www.agileskills2.org/EWDT)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: T5: alowing a component to get a page by name at runtime
Posted by Howard Lewis Ship <hl...@gmail.com>.
On 12/10/06, Kent Tong <ke...@cpttm.org.mo> wrote:
>
> Howard Lewis Ship <hlship <at> gmail.com> writes:
>
> > We could have a public PageSource interface, in infrastructure, that
> gave
> > access to a page's root components. The *implementation* of PageSource
> > would know about RequestPageCache.
>
> OK.
>
> > Sounds like you're getting into the code ... any thoughts or
> observations?
> > I've been having a few minor problems coming up with proper names for a
> few
> > things, mostly on the internals side.
>
> Some initial observations:
> 1) The effect of @Inject is quite hard to understand as it is
> "overloaded" to do three different things: asset injection,
> anonymous injection (type-based) and named injection (object ref).
> For example, I don't understand why there is a separate @InjectPage
> but asset is injected by @Inject instead of a separate @InjectAsset.
We'll see how this works out. I really want @Inject to be "one stop
shopping" for as much injection as possible. Much like Tapestry will adapt
to your methods, @Inject wil adapt to your instance variables.
But there's only so far you can stretch that, and I have not (yet) figured
out how to recognize a page by its type (since pages can be almost any type,
including Object).
2) It took me quite a lot of time to understand the existence and
> the name of ComponentResourcesCommon. Maybe it could be renamed
> as ComponentContext or ComponentInstance.
I'm going to start cranking out tutorials soon, perhaps this will help. Did
you miss the fact that
ComponentResources extends ComponentResourcesCommon? Or the fact that an
instance of ComponentResources is injected into your component?
3) Due to the extensive use of action links and that the context is
> stored on the client, an average Tapestry app will be heavily
> subjected to security issues. Signing the context is not effective
> as it can be grafted into another page. Storing the state into the
> session seems to be the only way.
I'm not sure I follow you. This really is not much different than T4,
except for how "listener parameters" (in T4) are stored as context value on
the request path in T5. And that it's more readable (simple toString() /
parse, rather than DataSqueezer).
The fact that pages that exist to display an instance of some kind of
entity can provide handlers for
"passivate" and "activate" should result in more readable URLs and less
session data (always good for dealing with the browser back button).
4) I'd like to see the PageLink coming back. It can just wrap around
> an ActionLink.
Soon!
5) I don't understand why the PagePool is using only the page name
> (but not the locale) to select the page. The code in T4 should be
> quite reusable?
Soon!
--
> Author of a book for learning Tapestry (http://www.agileskills2.org/EWDT)
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
>
--
Howard M. Lewis Ship
TWD Consulting, Inc.
Independent J2EE / Open-Source Java Consultant
Creator and PMC Chair, Apache Tapestry
Creator, Apache HiveMind
Professional Tapestry training, mentoring, support
and project work. http://howardlewisship.com
Re: T5: alowing a component to get a page by name at runtime
Posted by Kent Tong <ke...@cpttm.org.mo>.
Howard Lewis Ship <hlship <at> gmail.com> writes:
> We could have a public PageSource interface, in infrastructure, that gave
> access to a page's root components. The *implementation* of PageSource
> would know about RequestPageCache.
OK.
> Sounds like you're getting into the code ... any thoughts or observations?
> I've been having a few minor problems coming up with proper names for a few
> things, mostly on the internals side.
Some initial observations:
1) The effect of @Inject is quite hard to understand as it is
"overloaded" to do three different things: asset injection,
anonymous injection (type-based) and named injection (object ref).
For example, I don't understand why there is a separate @InjectPage
but asset is injected by @Inject instead of a separate @InjectAsset.
2) It took me quite a lot of time to understand the existence and
the name of ComponentResourcesCommon. Maybe it could be renamed
as ComponentContext or ComponentInstance.
3) Due to the extensive use of action links and that the context is
stored on the client, an average Tapestry app will be heavily
subjected to security issues. Signing the context is not effective
as it can be grafted into another page. Storing the state into the
session seems to be the only way.
4) I'd like to see the PageLink coming back. It can just wrap around
an ActionLink.
5) I don't understand why the PagePool is using only the page name
(but not the locale) to select the page. The code in T4 should be
quite reusable?
--
Author of a book for learning Tapestry (http://www.agileskills2.org/EWDT)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: T5: alowing a component to get a page by name at runtime
Posted by Mind Bridge <mi...@yahoo.com>.
Hi,
I have been looking at T5 only partially for now, but I agree that with
Howard and you that there should be a PageSource capability in order to
allow the configuration of the page via methods before it is rendered...
Best regards,
-mb
Kent Tong wrote:
> Howard Lewis Ship <hlship <at> gmail.com> writes:
>
>
>> We could have a public PageSource interface, in infrastructure, that gave
>> access to a page's root components. The *implementation* of PageSource
>> would know about RequestPageCache.
>>
>
> Sorry that I just realized that there is no need to get the page Component
> to display a page by name at runtime. All it takes is to return the name
> as a string.
>
> --
> Author of a book for learning Tapestry (http://www.agileskills2.org/EWDT)
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: T5: alowing a component to get a page by name at runtime
Posted by Kent Tong <ke...@cpttm.org.mo>.
Howard Lewis Ship <hlship <at> gmail.com> writes:
> We could have a public PageSource interface, in infrastructure, that gave
> access to a page's root components. The *implementation* of PageSource
> would know about RequestPageCache.
Sorry that I just realized that there is no need to get the page Component
to display a page by name at runtime. All it takes is to return the name
as a string.
--
Author of a book for learning Tapestry (http://www.agileskills2.org/EWDT)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: T5: alowing a component to get a page by name at runtime
Posted by Howard Lewis Ship <hl...@gmail.com>.
If the interface is in an internal package, such as RequestPageCache, then
it should not be available via infrastructure:
I definitely want to keep the Page interface internal, and RequestPageCache
along with it. User code should never see Page, just the root component of
the page.
We could have a public PageSource interface, in infrastructure, that gave
access to a page's root components. The *implementation* of PageSource
would know about RequestPageCache.
Sounds like you're getting into the code ... any thoughts or observations?
I've been having a few minor problems coming up with proper names for a few
things, mostly on the internals side.
On 12/9/06, Kent Tong <ke...@cpttm.org.mo> wrote:
>
> Hi,
>
> In an attempt to catch up with T5 and maybe to make some small
> contributions, I'm trying to port the Workbench to T5. In the
> process I found that it seems impossible for a component to get
> a page by name that is provided at runtime (eg, in the case of
> a Tab component that knows about the names of the tab pages at
> runtime only). @InjectPage requires a constant page name. I'm
> thinking about making the RequestPageCache available through
> the infrastructure service. Do you think this is the way to do
> it?
>
> --
> Author of a book for learning Tapestry (http://www.agileskills2.org/EWDT)
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
>
--
Howard M. Lewis Ship
TWD Consulting, Inc.
Independent J2EE / Open-Source Java Consultant
Creator and PMC Chair, Apache Tapestry
Creator, Apache HiveMind
Professional Tapestry training, mentoring, support
and project work. http://howardlewisship.com