Ah - but unfortunately there's no common super interface, so in this
case I'd be relying on AbstractField#getClientId, since this mixin would
probably apply only to those (although possibly not). So that's a bit of
a pain, but you're saying that calling allocateClientId will give the
same results (even if it requires more work)?
I'm still trying to figure out why I need Tapestry to be aware of an
actual server side component that represents the recipient of the JS
keystrokes. I feel like one should be there, but I'm yet sure why...
Kristian Marinkovic wrote:
most of the components offer a public getClientId() method :)
if you use some that doesn't you have to do:
@Inject
private PageRenderSupport _pageRenderSupport;
@Inject
private ComponentResources _resources;
_pageRenderSupport.allocateClientId(_resources.getId());
Chris Lewis <[EMAIL PROTECTED]>
10.10.2007 15:10
Bitte antworten an
"Tapestry users" <users@tapestry.apache.org>
An
Tapestry users <users@tapestry.apache.org>
Kopie
Thema
Re: T5: coordinating components and/or mixins
So when I use @InjectComponent, what type must I inject? If the
PageRenderSupport service has the method I need, woudn't I inject that
(as an @Environmental)?
thanks again :)
Kristian Marinkovic wrote:
1) getId() returns the id of the component you used in your code.
you get a problem when you use your component in a loop. then your
id would not be unique anymore... this is also true if you use the
same component with the same id in another nested component.
T5 uses the PageRenderSupport service to generate unique
client-side ids even in loops. getClientId returns this generated unique
id
2) using heartbeat... you're right is possible too
3) why another service... i tend to generate my js code only at
the end of my page. therefore i first collect my data and at the end
i do the js stuff like adding js event listener and the whole js wiring
and such. so my mixins stay relatively dumb. i think its just a matter
of taste :)
i'm glad i could help. i thought i scared you off with my
previous post :)
g,
kris
Chris Lewis <[EMAIL PROTECTED]>
10.10.2007 14:28
Bitte antworten an
"Tapestry users" <users@tapestry.apache.org>
An
Tapestry users <users@tapestry.apache.org>
Kopie
Thema
Re: T5: coordinating components and/or mixins
Sorry, but you seemed to grasp it well. I have some questions regarding
your response:
Kristian Marinkovic wrote:
a few thoughts that
come into my mind.....
you can use a Mixin to determine the generated id of
a component by using @InjectComponent and reading
getClientId.
Currently I'm @Inject-ing ComponentResources and using getId() - should
be the same right?
This Mixin would delgate the id to a service
that is contributed to PageRenderInitializer and is available
through the @Environmental annotation. After your page
has been processed succesfully your service has
the chance to generate the appropriate JS code for the
ids it gathered (using PageRenderSupport or DocumentScriptBuilder)
... and here is where you could add events and whatever :)
Why would I delegate the id to a service? If I want to execute my
mixin's rendering after the page is processed, couldn't I just use
@MixinAfter or use a heartbeat, and then generate the JS code in the
mixin? This is what I'm using the mixin for, to generate the appropriate
JS code to count/monitor the key-presses.
you can also use a Mixin to generate the counter field by
intercepting the render phase methods and adding new nodes
using the markupwriter... but i would'n do this because then you
would have to make some assumptions on the generated
markup of the component your Mixin is attached to.
Exactly.
Instead
i'd write a component that will be passed to the mixin via a
parameter. And this component can be placed whereever you
want because the JS wiring will be delegated to the injected
service of your mixin.
I still don't see why I'd use a service to generate the JS instead of
the mixin - it seems superfluous.
You understand exactly what I'm aiming for though, but I'm still not
sure about the component that receives the events. The receiving
component wouldn't need any server side validation or state - it only
needs to provide the code to modify the document (counter, etc). I guess
the first thing to decide is what kind of component, and how would they
be wired up...
Sorry I'm still thinking this over, but your input helped and I'd like
more if you have it :). At any rate, thanks!
chris
i hope i've not confused you to much :)
g,
kris
Chris Lewis <[EMAIL PROTECTED]>
09.10.2007 23:09
Bitte antworten an
"Tapestry users" <users@tapestry.apache.org>
An
Tapestry users <users@tapestry.apache.org>
Kopie
Thema
T5: coordinating components and/or mixins
Hello again,
I've been working on a mixin that will count the characters typed into
a
TextField or TextArea, as they are typed. It works fine but among other
things, I want to make it possible to control where and how user
feedback is displayed. My mixin just implements the counting logic, but
it should be possible for a user to use this mixin and configure it to
display a counter, implement text-length restriction (something not
possible for html text areas without JS), and implement notification.
How should I go about doing this? I could easily have a domId parameter
on the mixin that would receive the counter notifications, but I'd
rather make it easy for one to plug in their own logic and receive
these
notifications as events. Obviously that part would happen in
client-side
JS, but I want the framework to coordinate the two (ensuring the
components exist, etc). Does anyone have any thoughts on this?
sincerely,
chris
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]