Built-in mechanism to identify self-referential links and/or event/render
requests
----------------------------------------------------------------------------------
Key: TAP5-948
URL: https://issues.apache.org/jira/browse/TAP5-948
Project: Tapestry 5
Issue Type: Improvement
Components: tapestry-core
Affects Versions: 5.0.18, 5.0.17, 5.0.16, 5.0.15, 5.1.0.5, 5.1.0.4,
5.1.0.3, 5.1.0.2, 5.1.0.1, 5.1.0.0
Reporter: Kalle Korhonen
Discussed on Tapestry user thread:
http://old.nabble.com/Best-practice-for-initializing-page-to-default-context-td26689270.html
One of the cases where the issue manifests itself is that it's more difficult
to initialize a page to default context than it needs to (and redirect to it)
since event requests always cause a parameterless onActivate() to be invoked as
well and there's no (framework-level) support for identifying event and render
requests. There are many other uses for being able to easily identify links
referring back to the same page.
Howard says:
"I've had to solve this problem for one of my clients as well and I think it's
something that should go into the framework. The approach
I took was to identify self-referential links (page render links that are to
the same page they originate from) using an additional query
parameter. This allows Tapestry to differentiate between requests that start on
a new page vs. those that continue on the page. Tapestry can
then fire a notification on components to perform initialization (on page
render requests without the query parameter).
This would be a new lifecycle method, like pageAttached() or pageLoaded(). I'm
still working on the right terminology, for Widen it is "initialized", as in
method pageInitialized()."
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
