Yes, that is want I want. For now, what I've done works. Just getting
the page requires the use of internal classes. I can't even think
about how to get the component. Once this is included, then I can
eliminate my hack.
Norman Franke
Answering Service for Directors, Inc.
www.myasd.com
On Jun 20, 2009, at 3:31 PM, Robert Zeigler wrote:
Hm. What if you have a structure like:
page
component x
bean edit form
And you want the messages in component x (to make component x be
reusable)?
The way you've got it now, you'll always have to put the messages in
the top level page.
That said, I'm in the middle of:
https://issues.apache.org/jira/browse/TAP5-692
Which, I think, is exactly what you're trying to accomplish...
right? :)
I have a bit more liberty than you in that I can tweak the framework
to make this easier. :)
What I"m considering at the moment is having
FieldValidatorDefaultSourceImpl push the overriding component
resources onto the environment just before calling into the
ValidationConstraintGenerator service (and popping it off
immediately after), so the MessagesConstraintGenerator can access it.
My only concern is whether any users have already pushed some
instance of ComponentResources onto the environment and are counting
on a particular instance to be available.
I may wrap ComponentResources into a "holder" class to avoid this,
but for now, I'm pushing ComponentResources directly.
Anyway, hth.
Robert
On Jun 19, 2009, at 6/193:44 PM , Norman Franke wrote:
On Jun 19, 2009, at 3:31 PM, Thiago H. de Paula Figueiredo wrote:
Em Fri, 19 Jun 2009 15:26:44 -0300, Norman Franke
<nor...@myasd.com> escreveu:
No, the pages's properties. I figure I may want different
settings on
each page.
Nice point. :)
Seems like I'd need to know the page name and/or class for that. I
don't.
You can inject the Request and use the ComponentEventLinkEncoder
service to get the logical name (xxx/yyy) that was requested and
then use ComponentClassResolver.resolvePageNameToClassName() to
get the class name.
That seems more icky. Plus, you just get the page path. I think
getting the actual Page would be better, since another
implementation could use variables in the page instance. I did try
it now, bug got a NPE when trying to resolvePageNameToClassName.
So, I'll stick with what I have, I guess.
If there isn't any better way to do it nor a JIRA about it, let's
file one.
Sure, feel free. Something along the lines if an injectable Page
for
the current page, or the current Component?
You can do this yourself (all you need is to create an account at
Apache's JIRA), but I already created it: https://issues.apache.org/jira/browse/TAP5-753
Thanks! I think it would be best if that was implemented.
Norman Franke
Answering Service for Directors, Inc.
www.myasd.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
