This week I spent some time trying to add a 'tooltip' to some textareas in a list.
I spent quite some time adapting a jquery script i found, finally made it work almost correctly in internet explorer 6, only to find out that it did not work as expected in ie7.
Finally I opted for a much easier solution : wrapping the textareas in a div with a title attribute containing the content of the textarea, like this :
<div title="test"><textarea>test</textarea></div>
(see html title attribute doc)
If you let the mouse rest a second over the textarea, the tool tip appears.
I did not have access directly to the code generating the textareas, but I could do it nicely with jquery. Let's say my textareas were called 'textarea_1', 'textarea_2', and so on. Here is the line i came up with :
$("textarea[name^='textarea_']").each(function (){jQuery(this).wrap('<div title="' + this.value + '"></div>')})
$("textarea") selects all textareas. (jquery element selector)
$("textarea[name^='textarea_']") selects every textarea whose name starts with 'textarea_'. (jquery 'attribute starts with' selector)
The 'each' function iterates over the selected elements. (jquery each)
'this' refers to the DOM element.
jQuery(this) turns the DOM element into a jQuery object. (jQuery)
The 'wrap' function allowed me to wrap each textarea inside a div. (wrap)
A last step : replacing quotes in the content so that text containing quotes would not be incomplete :
$("textarea[name^='textarea_']").each(function (){jQuery(this).wrap('<div title="' + this.value.replace('"', '"') + '"></div>')})
Oh, that replaces only the first quote it finds... We need to use a 'global' search :
$("textarea[name^='textarea_']").each(function (){jQuery(this).wrap('<div title="' + this.value.replace(/"/g, '"') + '"></div>')})
I only just found out I'd missed the global search, will go correct my code. Writing this post will have been useful to me, at least.
Monday, June 29, 2009
Tuesday, June 9, 2009
infinite loop in an sql server trigger
Hi.
I've spent some time writing sql server triggers these days and I made the same mistake twice in a month, so I thought I'd keep a note about it here.
In these triggers I have a main loop on the records that were inserted / updated / deleted.
To write this loop I :
At the end of the loop I had to write the FETCH CurIns INTO [...] again, not very DRY.
Nor especially pretty.
For some rows I did not want to execute the whole loop, so I used the CONTINUE keyword, as I would in php :
I tested my trigger via the browser, and the page just kept loading and loading and loading.
I had an infinite loop, because I should have called the FETCH CurIns INTO [...] before CONTINUEing. So my @@FETCH_STATUS was always zero, and the loop kept iterating on the same row.
So instead of writing the FETCH statement a third time I just enclosed the body of my loop in an IF block.
Beautiful.
I found it hard to avoid repetition, in these triggers.
Oh, and the process seemed to just go on and on, I don't know if there is a timeout for this kind of thing. To find out the process id :
I found the SPID based on the time and user and asked the DBA to kill it.
I've spent some time writing sql server triggers these days and I made the same mistake twice in a month, so I thought I'd keep a note about it here.
In these triggers I have a main loop on the records that were inserted / updated / deleted.
To write this loop I :
- defined a cursor CurIns on the special 'inserted' table
- fetched the elements and put them into variables (FETCH CurIns INTO @var1, @var2, ...)
- iterated with a
WHILE(@@FETCH_STATUS = 0)
BEGIN
[...]
END
At the end of the loop I had to write the FETCH CurIns INTO [...] again, not very DRY.
Nor especially pretty.
For some rows I did not want to execute the whole loop, so I used the CONTINUE keyword, as I would in php :
foreach ($array as $element) {
[...]
if (doNotNeedToHandleThis($element)) {
continue;
}
[...]
}I tested my trigger via the browser, and the page just kept loading and loading and loading.
I had an infinite loop, because I should have called the FETCH CurIns INTO [...] before CONTINUEing. So my @@FETCH_STATUS was always zero, and the loop kept iterating on the same row.
So instead of writing the FETCH statement a third time I just enclosed the body of my loop in an IF block.
Beautiful.
I found it hard to avoid repetition, in these triggers.
Oh, and the process seemed to just go on and on, I don't know if there is a timeout for this kind of thing. To find out the process id :
EXEC sp_who2 'Active'
I found the SPID based on the time and user and asked the DBA to kill it.
Tuesday, June 2, 2009
promotion
A recruiting agency called me last week to see if i'd be interested in working as a 'php analyst-developer' for one of their clients.
The recruiter told me what she thought were the nice sides of the company, and particularly that there were opportunities to get promoted to 'business analyst' or 'project manager'.
Am i to conclude that developer is a lousier job than BA or PM?
The recruiter told me what she thought were the nice sides of the company, and particularly that there were opportunities to get promoted to 'business analyst' or 'project manager'.
Am i to conclude that developer is a lousier job than BA or PM?
Subscribe to:
Posts (Atom)