Hi Peter,

This isn't my situation. I'm not writing a component, I'm writing a
generic mixin that attaches an instance of a JS object, defined in an
accompanying JS file, simply by knowing the DOM id of the HTML element
resulting from the component. If I were writing a component I'd be ok,
because I have control over it's parameters. However I'm writing a mixin
for general reuse.

chris

Peter Beshai wrote:
> Hi Chris,
>
> This may not be the proper way of doing things, but I needed to get the
> client Id of one of my components, so I did this:
>
> @Inject
> private PageRenderSupport _pageRenderSupport;
>
> private String _clientId;
>
> void beginRender()
> {
>     _clientId = _pageRenderSupport.allocateClientId(_resources);
> }
>
> public String getCurrentBeanRowId()
> {
>     return _clientId + "row" + _currentBeanRow;
> }
>
> and in my template I used:
> <a class="beanaction" href="javascript:;"
> onclick="$('${currentBeanRowId}').remove(); return
> false">${removeBeanLabel}</a>
>
> and it seems to get the client id right :-)
>
> Hope this gives you an idea,
>
> Peter Beshai
>
> On Fri, Apr 11, 2008 at 12:57 AM, Chris Lewis <[EMAIL PROTECTED]>
> wrote:
>
>   
>> Hi Josh,
>>
>> Indeed t:id does work, but apart from the fact that I'm not entirely
>> sure what T5 does with that value as opposed to the un-namespaced
>> version (id), it doesn't fully work. The reason is because the Any
>> component, like many in the core lib, do not explicitly write a DOM id
>> in the HTML of the resulting element. So while this allows me to get
>> some id in java code (which I need), it doesn't address the problem of
>> their not being a DOM id, so of course my JS fails. The only ways around
>> this that I know are:
>>
>> 1) Explicitly provide the id as the normal 'id' attribute in the
>> template as an informal parameter and provide another one in the t:
>> namespace, to be passed to the component. The problem with this is I
>> have to provide it twice, which aside from being annoying is error-prone.
>>
>> 2) Have the mixin explicitly write a HTML id attribute to the tag of the
>> containing component. This would be horrible in my opinion, because
>> without intimate knowledge of the component using the mixin, or any
>> other mixins coordinating behavior, you can't know be sure you won't
>> damage something (overwriting an id attribute already created, writing a
>> second id attribute (which would be wrong), etc). And of course if the
>> mixin requires intimate knowledge then it's not a good mixin.
>>
>> Thanks - any other ideas? :-)
>>
>> chris
>>
>> Josh Canfield wrote:
>>     
>>> Hey Chris,
>>>
>>> t:id="my_div" seems to do what you want. I haven't looked closely at
>>> un-namespaced id works in Tapestry, I've just always used the t:id
>>> variety...
>>>
>>> Josh
>>>
>>> On Thu, Apr 10, 2008 at 5:36 AM, Chris Lewis <[EMAIL PROTECTED]>
>>>       
>> wrote:
>>     
>>>> Dear list,
>>>>
>>>> I decided to throw together an app detailing how JS works with T5 (how
>>>> to connect behavior from a component or mixin, the important inner
>>>> workings, etc). I created a mixin that attaches behavior (mouse overs)
>>>> to an HTML element (and doing this requires the DOM id of that
>>>>         
>> element).
>>     
>>>> For a simple demo I just wanted to attach it to a styled <div
>>>> id="my_div">, so I had to use a <div t:type="any" id="my_div">. No
>>>> problem. Now I need that DOM id in my java code (mixin) so I can pass
>>>>         
>> it
>>     
>>>> to the instantiation string of my JS object. Here's what I tried:
>>>>
>>>>    @Parameter(value = "prop:componentResources.id", defaultPrefix =
>>>> TapestryConstants.LITERAL_BINDING_PREFIX)
>>>>    private String clientId;
>>>>
>>>> This is the 'usual' way of getting the client side id of the component,
>>>> at least when that component outputs it in the html element body. Since
>>>> Any does not, it appears to interpret (or rather ignore) the id
>>>> attribute and treat it as an informal. The problem with that is there
>>>>         
>> is
>>     
>>>> no way, at least that I know of, to get my hands on that value in java
>>>> code. So what I'm having to do in my template code is explicitly
>>>>         
>> declare
>>     
>>>> the t:clientId parameter:
>>>>
>>>> <div t:type="any" t:mixins="hoverhighlight" id="my_box"
>>>>         
>> t:clientId="my_box">
>>     
>>>> This works, but it's annoying that T5 can't know what the client side
>>>>         
>> id
>>     
>>>> will be. Components that actually produce a T5-generated client side id
>>>> generally implement ClientElement#getClientId and explicitly insert the
>>>> html id attribute with that as a value. I realize that it wouldn't make
>>>> sense for _every_ component to do this, but IMO there should be a way
>>>>         
>> to
>>     
>>>> get at this id in the situations where it's been provided. Perhaps I've
>>>> missed something, but unless I've missed something there's no current
>>>> way to do this and get the dom id in code:
>>>>
>>>> <div t:type="any" t:mixins="hoverhighlight" id="my_box">
>>>>
>>>> Thanks for any input you can offer.
>>>>
>>>> chris
>>>>
>>>> --
>>>> http://thegodcode.net
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>>>> For additional commands, e-mail: [EMAIL PROTECTED]
>>>>
>>>>
>>>>
>>>>         
>>>
>>>
>>>       
>> --
>> http://thegodcode.net
>>
>>
>>     
>
>   

-- 
http://thegodcode.net

Reply via email to