Hi,
thanks for the response. So it looks like I can manage the components
mostly through the ComponentSource service, I should be able to clear
persistent fields this way and load the current SubPage I want. Then I
can implement a ComponentRequestFilter to aid in the Permissions I wrote
about.
That just leave a) which I see I did not explain well enough. By
"directs content" I was trying to generalize the concept that the
ModuleIndex would be including (or Injecting?) the SubPage component
related to that current SubPage. Just like when you include any
component in a template i.e. <t:SubPage />. I was achieving this through
Delegate and Block before, but that was linked up to the @Component
SubPages so it could load the right one.
Also, you mentioned not using 'mvn jetty:run', is there anything
particularly wrong with that? That's how I run the application.
I certainly agree many things about my current implementation are not
ideal (memory consumption, not typical way of doing things) but working
is better than nothing, not to mention how hard it is to figure out what
the "recommended way of doing it" is for any given feature without asking =/
-Rich
On 08/19/2010 03:04 PM, Thiago H. de Paula Figueiredo wrote:
On Thu, 19 Aug 2010 15:41:20 -0300, Rich M <rich...@moremagic.com> wrote:
a) ModuleIndex functions similar to the Layout page, it must contain
the navigation menu and then directs content from a specific page of
the Module (I will call these SubPages) into the template.
What do you mean by "directs content"?
b) The module needs to keep track of all the SubPage instances so it
can wipe their persistent fields when navigation changes.
This can be implemented as a ComponentRequestFilter. In addition,
Tapestry 5.2 adds one page lifecycle that my be useful this kind of
situation:
http://tapestry.apache.org/tapestry5.2-dev/apidocs/org/apache/tapestry5/annotations/PageReset.html
c) The module needs to assess the target of page navigation, and then
filter the resulting SubPage based on user permissions within the
application.
This can be implemented as a ComponentRequestFilter. That's the
recommended way of doing it.
d) When one of the specific SubPage classes is changed in source, it
should be able to be live reloaded without restarting the application
In Eclipse, I just leave all the projects (modules) open and it works,
as long as I'm not using Maven's jetty:run. I usually create a Main
class that launches a Jetty instance.
ModuleIndex has a @Component for each SubPage and then maps these
components to the activation context integers in a @SessionState Map.
In Tapestry 5.1 (page pool), this would lead to a large memory
comsumption. In 5.2 there's no such problem.
Anyway, a good option is to use ComponentSource to get instances of
components or pages in runtime instead of holding references to
instances, leading to the ClassCastExceptios you're experiencing.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
