Actually I spoke a little too soon about the persistent fields. I'm not
really clear on how that is solved by a ComponentRequestFilter, other
than it's a good place to do it. ComponentSource doesn't provide any
means with which to clear persistent fields.
I was achieving it before with
@Inject
private ComponentResources cr;
public void clearPersistentFields(){
cr.discardPersistentFieldChanges();
}
IIRC this has to be inside the component itself to work. My Tab
components have this, but I have no way of accessing them as objects. It
is possible to somehow cast the Component object from ComponentSource's
getPage method to the Tab interface in order to access this method? I'm
not sure if Tapestry links custom components to the Component class
somehow, but my common Java sense would tell me this is silly.
-Rich
On 08/19/2010 04:20 PM, Rich M wrote:
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
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org