On 11/18/05, Oliver Steele <[EMAIL PROTECTED]> wrote:
Good ideas! We used to have a feature where you could set a flag in the URL and all debugger output would be copied to the server log, but nobody used it, and it rotted away a little. And actually if debug logging is enabled in lps.xml, you will see a copy of all your debug expressions appear in the log. But I should make this into a nice easy to enable feature that logs to a named file on the server.
Side note, from a failed DHTML developer: All this stuff would be simpler if we could use components in the debugger UI, so you could pop up a prefs window like we used to, and click a checkbox for this and other goodies.
I tried to make a pop up dialog window in the dev console, but it was painful because the console dev app is just embedded in a thin strip in the page, and it needs to be larger to see the dialog box, which in turn means painful _javascript_ hacking in the browser to resize the containing HTML DIV element, and at that point I gave up.
On Nov 17, 2005, at 3:12 PM, Scott Evans wrote:
> Pablo and I just had a great idea -- how about storing debugger
> history
> between app invocations? In cookies, or on the server? Maybe on a
> per-app basis? Holy cow that would be nice.
That reminds me of two things that I'd like. One is easy: it's for
the debugger window size and position to persist between sessions.
This is just ("just") a matter of porting the code form examples/
sessionwindow.lzx to the debugger. The trick is to do this in a way
that doesn't break your ability to debug if sessionrpc is broken. I
don't know whether this is hard.
The other is some round-trip system for logging the debugger command
history to an lzunit file, so that you can develop tests
incrementally in the debugger and then easily edit them into an
automated test case. For example, if you type this sequence in the
debugger:
aview.setAttribute ('x', 100);
otherview.width // testing that constraint updates -> 50
assert(50, otherview.width);
then you could easily get a single text block of these commands
without intervening responses, which you could edit into:
<TestCase>
<method name="test">
aview.setAttribute('x', 100);
otherview.width // testing that constraint updates -> 50
assert(50, otherview.width);
</TextCase>
and then edit out the "overview.width" line, since it was only
exploratory and isn't necessary in the test.
____________________________________________
Good ideas! We used to have a feature where you could set a flag in the URL and all debugger output would be copied to the server log, but nobody used it, and it rotted away a little. And actually if debug logging is enabled in lps.xml, you will see a copy of all your debug expressions appear in the log. But I should make this into a nice easy to enable feature that logs to a named file on the server.
Side note, from a failed DHTML developer: All this stuff would be simpler if we could use components in the debugger UI, so you could pop up a prefs window like we used to, and click a checkbox for this and other goodies.
I tried to make a pop up dialog window in the dev console, but it was painful because the console dev app is just embedded in a thin strip in the page, and it needs to be larger to see the dialog box, which in turn means painful _javascript_ hacking in the browser to resize the containing HTML DIV element, and at that point I gave up.
--
Henry Minsky
Software Architect
[EMAIL PROTECTED]
_______________________________________________ Laszlo-user mailing list [email protected] http://www.openlaszlo.org/mailman/listinfo/laszlo-user
