From: Alan Gutierrez on
dark_gf wrote:

> I have a problem: in my job we creating ria based on extjs, and
> divided code by components, all works great but its difficult to trace
> errors in components, because they executed via eval() functions, does
> any have any ideas how to get max information about error that happed
> in code?

1) Firebug.
2) Surround eval stuff with try catch and read the exception.

--
Alan Gutierrez - alan(a)blogometer.com - http://twitter.com/bigeasy
From: Thomas 'PointedEars' Lahn on
David Mark wrote:

> Thomas 'PointedEars' Lahn wrote:
>> [...] Last I checked, ExtJS was a 277K+ blob that used
>> browser sniffing to generate a UI that was not accessible;
>> needlessly, I should add.
>
> Look again. It's 700K+. Or perhaps you are referring to the size
> after GZIP?

I was referring to the total size of all files in in ext-core/src/core/,
which AIUI would be the minimum code required to make ExtJS work. But
the difference doesn't really matter here, does it?


PointedEars
--
realism: HTML 4.01 Strict
evangelism: XHTML 1.0 Strict
madness: XHTML 1.1 as application/xhtml+xml
-- Bjoern Hoehrmann
From: David Mark on
On Jul 27, 7:13 pm, Thomas 'PointedEars' Lahn <PointedE...(a)web.de>
wrote:
> David Mark wrote:
> > Thomas 'PointedEars' Lahn wrote:
> >> [...]  Last I checked, ExtJS was a 277K+ blob that used
> >> browser sniffing to generate a UI that was not accessible;
> >> needlessly, I should add.
>
> > Look again.  It's 700K+.  Or perhaps you are referring to the size
> > after GZIP?
>
> I was referring to the total size of all files in in ext-core/src/core/,
> which AIUI would be the minimum code required to make ExtJS work.  But
> the difference doesn't really matter here, does it?
>

In what way? Certainly when it comes to bad code, it's in for a
penny...

Or perhaps you refer to the OP's use of "framework" which implies that
they are likely using the various widgets as well (pushing the
required payload over 700K).

Either way, it's a problem.
From: David Mark on
On Jul 27, 7:05 pm, Alan Gutierrez <a...(a)blogometer.com> wrote:
> dark_gf wrote:
> > I have a problem: in my job we creating ria based on extjs, and
> > divided code by components, all works great but its difficult to trace
> > errors in components, because they executed via eval() functions, does
> > any have any ideas how to get max information about error that happed
> > in code?
>
> 1) Firebug.

I think it can be assumed from the OP's description that they are
already using a debugger of some sort.

> 2) Surround eval stuff with try catch and read the exception.
>

That's absolutely the wrong answer as it would prevent the debugger
from tracing and presenting the execution that led to the exception.
Not unsurprisingly, this is (sort of) what Dojo does, which makes
debugging their dynamically loaded "modules" virtually impossible.

One part of the answer to problems like these is to eliminate try-
catch clauses (particularly those that throw "friendly" replacement
errors), not to add them.

Another answer it to avoid the use of eval, which is virtually never
needed anyway.

In Dojo's case, I replaced all of their loader without using a single
eval call. The solution in their case was to use document.write
before the DOM was ready and script injection afterward. Not
unexpectedly, it made debugging infinitely easier (as well as speeding
up the loading exponentially). And no, they didn't use any of it.

ISTM they got hung up on some obscure case of using two differnt Dojo
versions in the same document. I explained that I hadn't tried that
(and neither had they with my branch), but couldn't say for sure what
the ramficiations of such a bizarre scheme would be. That was enough
for them to want to cling to their old synchronous XHR/eval version
(which remains to this day) as in their minds, it was "well-tested"
and worked in "all browsers". :)
From: Alan Gutierrez on
David Mark wrote:
> On Jul 27, 7:05 pm, Alan Gutierrez <a...(a)blogometer.com> wrote:
>> dark_gf wrote:
>> 2) Surround eval stuff with try catch and read the exception.

> ISTM they got hung up on some obscure case of using two differnt Dojo
> versions in the same document. I explained that I hadn't tried that
> (and neither had they with my branch), but couldn't say for sure what
> the ramficiations of such a bizarre scheme would be. That was enough
> for them to want to cling to their old synchronous XHR/eval version
> (which remains to this day) as in their minds, it was "well-tested"
> and worked in "all browsers". :)

Is there a link to this conversation on one of their development
listservs or otherwise publicly available. I'd be eager to read the
exchange and see what reasons they gave.

--
Alan Gutierrez - alan(a)blogometer.com - http://twitter.com/bigeasy