Howard Lewis Ship wrote:
On 12/10/06, Kent Tong <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
