adding compilation errors to debugger?

Email lists > OpenLaszlo platform development

Thread: adding compilation errors to debugger?

Search this list only Search all lists
adding compilation errors to debugger?
United States	2007-04-10 15:49:11
We deploy (and thus, develop) our apps in an HTML wrapper that embeds the app. A downside to this development style is that we don't see LZX compilation errors. It'd be nice to have compilation errors repeated in the debugger window on startup. Doable? gse

Re: adding compilation errors to debugger?
	2007-04-10 16:01:54

I can think of one way to do it, but this only works in LPS 4 There is a request type I added as of Legals (LPS 4.x) which is lzt=canvas http://localhost:8080/legals/test/hello.lzx?lzt=canvas Which gives you all the goodies that the dev console uses, including compilation errors. The output looks like this <canvas title=';OpenLaszlo Application' bgcolor='#ffffff' width=';100%' height=9;100%' proxied='true'; runtime='swf7'; lfc='lps/includes/lfc/LFC7.lzl' debug=';false' id='lzapp' accessible='false' >   <request lps="/legals" url="hello.lzx" relurl="test/hello.lzx"; fullpath="/legals/test/hello.lzx" opt-url="hello.lzo" unopt-url="hello.lzx" query_args="" pocketpc="false" console-remote-debug="null" console-floating-window="null" appuid="1176238458953" windows="true" opt-exists="false" >     <param name=";lzt" value="canvas"/>   </request>   <info size=";84693"; debug="false" encoding="null" debug-exists="false" debug-up-to-date="false" nondebug-exists=";true" nondebug-up-to-date="true" runtime="swf7" gzsize="84741" lfcsize="235210" gzlfcsize="54028" />   <console_appinfo>   ... </console_appinfo> <stats>   <swf />     <include name=";LFC7.lzl" explanation="Required for all applications" size=";247979" />     <block pathname="hello.lzx" lineno="2" tagname="text" size=";186" />     <block pathname="hello.lzx" lineno="3" tagname="view" size=";140" />     <block pathname="hello.lzx" lineno="4" tagname="view" size=";91" />   </stats> <warnings>     <error>   hello.lzx:4:22: attribute "foo" not allowed at this point; ignored<;/error>   <br/>;   <error>   hello.lzx:4:22: found an unknown attribute named "foo" on element view, check the spelling of this attribute name</error>   </warnings> <;/canvas>; The debugger could make a data request back to the server when it inits, and fetch and display this using an xpath. You're not using 4.0 yet, right? The lzt=canvas request type could be back ported I guess to 3.4, it's just this one file that goes into WEB-INF/lps/server/src/org/openlaszlo/servlets/responders/ResponderCANVAS.java: /****************************************************************************** * ResponderCANVAS.java * ***************************************************************************/ / J_LZ_COPYRIGHT_BEGIN ******************************************************* * Copyright 2001-2006 Laszlo Systems, Inc. All Rights Reserved.  ;         * * Use is subject to license terms.        ;         ;         ;         ; * * J_LZ_COPYRIGHT_END ********************************************************/ / Return the canvas xml descriptor, as XML document / package org.openlaszlo.servlets.responders; import java.io.; import java.util.; import java.net.URLEncoder; import java.util.Enumeration; import java.util.Properties; import javax.servlet.ServletConfig ; import javax.servlet.ServletException; import javax.servlet.ServletOutputStream; import javax.servlet.http.HttpSession; import javax.servlet.http.HttpServletRequest; import javax.servlet.http.HttpServletResponse ; import org.openlaszlo.compiler.Canvas; import org.openlaszlo.compiler.CompilationError; import org.openlaszlo.utils.; import org.apache.log4j.Logger; public final class ResponderCANVAS extends ResponderCompile { ;   /** ; * param fileName Full pathname to file from request.   ; /   protected void respondImpl(String fileName, HttpServletRequest req,       ;         ;         HttpServletResponse res)       throws IOException   {     ; ServletOutputStream out = res.getOutputStream();       try {     ;     res.setContentType ("text/xml");     ;     Canvas canvas = getCanvas(fileName, req);     ;     String xml = canvas.getXML(ResponderAPP_CONSOLE.getRequestXML(req, fileName));       ;   out.write(xml.getBytes()); ;       } finally {     ;     FileUtils.close(out);       }   } ;   public int getMimeType()   {     ; return MIME_TYPE_XML; ; } } On 4/10/07, Scott Evans* < gselaszlosystems.com"> gselaszlosystems.com>; wrote: We deploy (and thus, develop) our apps in an HTML wrapper that embeds the app. A downside to this development style is that we don't see LZX compilation errors. It'd be nice to have compilation errors repeated in the debugger window on startup.  Doable? gse -- Henry Minsky Software Architect hminskylaszlosystems.com">hminskylaszlosystems.com
Re: adding compilation errors to debugger?
United States	2007-04-10 16:19:30
On 2007-04-10, at 16:49 EDT, Scott Evans wrote: > We deploy (and thus, develop) our apps in an HTML wrapper that embeds > the app. A downside to this development style is that we don't see > LZX > compilation errors. > > It'd be nice to have compilation errors repeated in the debugger > window on > startup. Doable? Not that easy, but... If you request your app with (the undocumented type) ?lzt=canvas you will get back xml that will have an <lps-error> node if there are any errors. Is that helpful at all?

Re: adding compilation errors to debugger?
United States	2007-04-10 18:09:04
On Tue, 10 Apr 2007, P T Withington wrote: > On 2007-04-10, at 16:49 EDT, Scott Evans wrote: > > > We deploy (and thus, develop) our apps in an HTML wrapper that embeds > > the app. A downside to this development style is that we don't see LZX > > compilation errors. > > > > It'd be nice to have compilation errors repeated in the debugger window on > > startup. Doable? > > Not that easy, but... > > If you request your app with (the undocumented type) ?lzt=canvas you > will get back xml that will have an <lps-error> node if there are any > errors. Is that helpful at all? Well, ideally this would be a feature that gets added to OpenLaszlo at some point -- that was really the intention of my original post. So we wouldn't change anything in our app; we'd just start seeing compile errors in the debugger. It's not something we need yesterday; it's more of a "this sure would be nice" thing. Before I opened a Jira feature, I wanted to hear from you guys if it was even worthwhile. gse

Re: adding compilation errors to debugger?
	2007-04-10 18:29:07

There has been talk of moving all of the debugger interface to use a remote debugger protocol of some kind, so the debugger could be running in its own browser window, that would probably make things easier at some point, but it's just been bits of ideas tossed out up to now. On 4/10/07, Scott Evans < gselaszlosystems.com">gselaszlosystems.com > wrote: On Tue, 10 Apr 2007, P T Withington wrote: > On 2007-04-10, at 16:49 EDT, Scott Evans wrote: > > > We deploy (and thus, develop) our apps in an HTML wrapper that embeds >; > the app. A downside to this development style is that we don't see LZX > > compilation errors. > > >; > It'd be nice to have compilation errors repeated in the debugger window on > > startup.  Doable? > > Not that easy, but... >; > If you request your app with (the undocumented type) ?lzt=canvas you > will get back xml that will have an <lps-error> node if there are any > errors.  Is that helpful at all? Well, ideally this would be a feature that gets added to OpenLaszlo at some point -- that was really the intention of my original post. So we wouldn';t change anything in our app; we'd just start seeing compile errors in the debugger. It's not something we need yesterday; it's more of a "this sure would be nice" thing.  Before I opened a Jira feature, I wanted to hear from you guys if it was even worthwhile. gse -- Henry Minsky Software Architect hminskylaszlosystems.com">hminskylaszlosystems.com

[1-5]

about | contact Other archives ( Real Estate discussion Medical topics )