Ah, great! That helped move things forward. Transformation is starting
to take place, I was able to get one of the SubPages to Live Reload, but
the display is wrong, part a) isn't quite complete. What is the best way
to feed the current SubPage into the containing ModuleIndex's page/template?
Thanks,
Rich
On Thu, 19 Aug 2010 17:53:56 -0300, Rich M <rich...@moremagic.com> wrote:
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.
From ComponentSource you get the page instance (a Component). It has a
getComponentResources() method. From there, you can invoke
discardPersistentFieldChanges().
--
Thiago H. de Paula Figueiredo
Independent Java, Apache Tapestry 5 and Hibernate consultant, developer,
and instructor
Owner, Ars Machina Tecnologia da Informação Ltda.
http://www.arsmachina.com.br
On 08/19/2010 04:53 PM, Rich M wrote:
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
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
