Yeah. It could be that it doesn't work when firebug lite is loaded
before dojo? Either way I'll be able to fix it in dojo as needed.
On 1/20/07, andyhot <[EMAIL PROTECTED]> wrote:
Jesse Kuhnert wrote:
> Sort of I think. I was hoping to make it more transparent with the
> existing functionality.
Jesse Kuhnert wrote:
Sort of I think. I was hoping to make it more transparent with the
existing functionality. It's easy enough to detect browser type on
server requests, so if the "consoleEnabled" parameter to Script /
ScriptIncludes was enabled I was thinking I'd just include it as a
script as
Sort of I think. I was hoping to make it more transparent with the
existing functionality. It's easy enough to detect browser type on
server requests, so if the "consoleEnabled" parameter to Script /
ScriptIncludes was enabled I was thinking I'd just include it as a
script asset appropriately.
On
Jesse Kuhnert wrote:
If it helps there should be firebug lite support coming into the 4.1.2
snapshot repos for just this scenario. (ie that is)
Jesse, what do you have in mind?
Something like
http://tacos.sourceforge.net/tacos4.1/tacos-core/tapdoc/Tacos/Firebug/index.html
?
On 1/17/07, Ma
If it helps there should be firebug lite support coming into the 4.1.2
snapshot repos for just this scenario. (ie that is)
On 1/17/07, Markus Joschko <[EMAIL PROTECTED]> wrote:
I run into the exact same issue. The error is only occuring using IE.
Firefox is dealing fine with the response.
Using
OK, the problem was an encoded german umlaut. E.g. the letter "ü" is
(giving credit to the pred UTF-8 days) often encoded as ü in web
pages.
If the text is included in the XML response during an update, the XML
engine of IE is stumbling about it.
As the default charset is UTF-8 anyway it's no big
I run into the exact same issue. The error is only occuring using IE.
Firefox is dealing fine with the response.
Using fiddler I can see that there are actually ajax-response elements
included, together with a lot of HTML as a big component is completely
reloaded.
So it looks as if the clientside
Thanks Jesse for your answer but it finaly seems that my "non response
received" error is due to non XML content :
I have tags (not closed) in the HTML blocks that should be rendered
by the ResponseBuilder. These blocks are build with Tapestry @Insert
components with the raw parameter set to tr
I actually saw this today as well. Looks like it is (was) a bug in
the ResponseBuilder logic associated with a recent flush() call change
I made..
It's been fixed but only in a branch that no one can access yet. The
real fix should come out within a week. (assuming that this is your
problem, it
Stephane Decleire wrote:
Have you any idea of the cases where an Ajax request leads to the "No
ajax-response elements recieved" error on the client ?
It should generally be an uncaught exception on the server-side code...
Try to capture the actual ajax-response with a tool like FireBug and
ju
10 matches
Mail list logo
