be careful when you use
_pageRenderSupport.allocateClientId(_resources.getId());
as it always generates a new id.
i looked at my code and i check whether the injected component
implements the interface ClientElement
Kristian Marinkovic <[EMAIL PROTECTED]>
10.10.2007 15:18
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
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]
>
>
>
>
