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.
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]
-- 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
