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]
