this should do it :)
@InjectComponent
private ClientElement component;
void beginRender() {
if(component != null)
System.out.println(component.getClientId());
}
Chris Lewis <[EMAIL PROTECTED]>
10.10.2007 15:54
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
Ok, but in order to use the component's method getClientId, I'd have to:
1) require the component to be of a certain (base) type
2) get access to the actual instance
I'm not sure how to do #2 without specifying it as a parameter. I
shouldn't have to do that thought because the component uses the mixin
and the mixin should be able to get it easily (and i'm not sure how)!
Sorry I'm new to mixins and am finding it a bit cumbersome to get the
correct client id.
Kristian Marinkovic wrote:
> 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]
>>
>>
>>
>>
>>
>
>
>
>
>
