Benjamin Shine | 1 Sep 01:31
Favicon

Re: for review, change to fix LPP-2588 -- debug flag on canvas causes trouble in DHTML runtime

The attachment is just the change description, not the diffs. Please send diffs?

On Aug 31, 2006, at 1:25 PM, Henry Minsky wrote:

Change change.sdWjP4036.txt by hqm <at> IBM-AA473F7AA76 /home/hqm/src/svn/openlaszlo/branches/legals/WEB-INF/lps/ on 2006-08-31 16:17:00 EDT

Summary: pass canvas debug attribute info through to ResponderLFC via html template

New Features:

Bugs Fixed:LPP-2588

Technical Reviewer: ben
QA Reviewer: (pending)
Doc Reviewer: (pending)

Documentation:

Release Notes:

Details:
   
fix for LPP-2588 Putting debug=true on canvas in DHTML causes error when running in non-debug app

The computed canvas 'debug' attribute (computed via the canvas
attribute plus any request debug query args) needs to get passed out
to the wrapper HTML template generator, so that the request for the DHTML LFC
can know whether to deliver the debug or non-debug version.


Tests:

Run this app as foo.lzx?lzr=dhtml

<canvas debug="true">
  <text text="${'$debug='+$debug}"/>
</canvas>

It should come up without error in Firefox, saying $debug=true


Files:
M      server\src\org\openlaszlo\servlets\responders\ResponderLFC.java
M      server\src\org\openlaszlo\servlets\responders\ResponderHTML.java
M      server\src\org\openlaszlo\compiler\CanvasCompiler.java
M      server\src\org\openlaszlo\compiler\Canvas.java
M      templates\html-response.xslt



--
Henry Minsky
Software Architect
hminsky <at> laszlosystems.com

<change.sdWjP4036.txt>

_______________________________________________
Laszlo-dev mailing list


_______________________________________________
Laszlo-dev mailing list
Laszlo-dev <at> openlaszlo.org
http://www.openlaszlo.org/mailman/listinfo/laszlo-dev
P T Withington | 1 Sep 01:55
Favicon

Re: Class syntax and <script/> blocks

You left out the superclass.  Er, and you forgot to call the  
superclass initialize method from your initialize method.  Um, and  
you didn't define the removeLoadChecker method (you tried to, but you  
named it removeLoadCheckerDel).  Other than that...

BTW, The 'modern' way to say what you want is:

<script>
class LzTestEventReg extends LzMediaLoader {
   function initialize ( owner , args ) {
     super.initialize ( owner, args);
     //todo: this isn't working: why?
     this.removeLoadCheckerDel =
       new LzDelegate( this, "removeLoadChecker", this, "onloaddone" );
   }

   function removeLoadChecker () {
     Debug.write('removeLoadCheckerDel');
   }

   var onloaddone = LzDeclaredEvent;

   function testDel () {
     this.onloaddone.sendEvent();
   }
}

var foo = new LzTestEventReg();
foo.testDel();
</script>

On 2006-08-31, at 18:49 EDT, Max Carlson wrote:

> Hi,
>
> I'm trying to make a simple test case that creates a class with a  
> custom constructor.  It's based on the LzMediaLoader class in the  
> LFC.  I want to keep it as similar the the LFC class as possible.   
> Can you take a look and tell me what I got wrong?  In DHTML it  
> fails due to 'too much recursion' creating the class, while SWF  
> does even less:
>
>
> <canvas width="800" height="400">
> <script>
> LzTestEventReg = new Class(
>     "LzTestEventReg",
>     function ( owner , args ) {
>         //todo: this isn't working: why?
>         this.removeLoadCheckerDel =
>             new LzDelegate( this, "removeLoadChecker", this,  
> "onloaddone" );
>     }
> );
>
> LzTestEventReg.prototype.removeLoadCheckerDel = function() {
>     Debug.write('removeLoadCheckerDel');
> }
>
> LzTestEventReg.prototype.testDel = function() {
>     this.onloaddone.sendEvent();
> }
> DeclareEvent(LzTestEventReg.prototype, 'onloaddone' );
>
> var foo = new LzTestEventReg();
> foo.testDel();
> </script>
> </canvas>
>
>
> Thanks!
>
> -Max
Henry Minsky | 1 Sep 02:04
Picon

Re: for review, change to fix LPP-2588 -- debug flag on canvas causes trouble in DHTML runtime

oopsy maybe this is it





On 8/31/06, Benjamin Shine <ben <at> laszlosystems.com> wrote:
The attachment is just the change description, not the diffs. Please send diffs?

On Aug 31, 2006, at 1:25 PM, Henry Minsky wrote:

Change change.sdWjP4036.txt by hqm <at> IBM-AA473F7AA76 /home/hqm/src/svn/openlaszlo/branches/legals/WEB-INF/lps/ on 2006-08-31 16:17:00 EDT

Summary: pass canvas debug attribute info through to ResponderLFC via html template

New Features:

Bugs Fixed:LPP-2588

Technical Reviewer: ben
QA Reviewer: (pending)
Doc Reviewer: (pending)

Documentation:

Release Notes:

Details:
   
fix for LPP-2588 Putting debug=true on canvas in DHTML causes error when running in non-debug app

The computed canvas 'debug' attribute (computed via the canvas
attribute plus any request debug query args) needs to get passed out
to the wrapper HTML template generator, so that the request for the DHTML LFC
can know whether to deliver the debug or non-debug version.


Tests:

Run this app as foo.lzx?lzr=dhtml

<canvas debug="true">
  <text text="${'$debug='+$debug}"/>
</canvas>

It should come up without error in Firefox, saying $debug=true


Files:
M      server\src\org\openlaszlo\servlets\responders\ResponderLFC.java
M      server\src\org\openlaszlo\servlets\responders\ResponderHTML.java
M      server\src\org\openlaszlo\compiler\CanvasCompiler.java
M      server\src\org\openlaszlo\compiler\Canvas.java
M      templates\html-response.xslt



--
Henry Minsky
Software Architect
hminsky <at> laszlosystems.com

<change.sdWjP4036.txt>

_______________________________________________
Laszlo-dev mailing list




--
Henry Minsky
Software Architect
hminsky <at> laszlosystems.com

Attachment (patch.hqm.3168.tgz): application/x-gzip, 2070 bytes

_______________________________________________
Laszlo-dev mailing list
Laszlo-dev <at> openlaszlo.org
http://www.openlaszlo.org/mailman/listinfo/laszlo-dev
Adam Wolff | 1 Sep 17:42
Favicon

ie optimization tips

old, but potentially useful:
    http://blogs.msdn.com/ie/default.aspx

one thing I hadn't thought of: assigning global functions to a local
before calling them repeatedly.

A
Benjamin Shine | 1 Sep 21:33
Favicon

logging to console with lzc


Phill A asked me to look into this, so I figured it out a bit, and it  
seems useful. If you are debugging and you want to call lzc directly,  
and you want to see log messages for just a few specific classes in  
the console, you can do that, like so:

Create a file named $LPS_HOME/console-debug.properties
containing something like this:
log4j.logger.org.openlaszlo.compiler.CanvasCompiler=DEBUG

that is:
log4j.logger.<package or class name>=<loglevel>

In your source code, create a logger for that class, or use the  
existing logger. CanvasCompiler.java declares:
private static Logger mLogger = Logger.getLogger(CanvasCompiler.class);

Then call methods on mLogger: debug, info, error, warn
         mLogger.debug("(debug) Compiling canvas.");
         mLogger.info("(info) Compiling canvas.");
         mLogger.error("(error) Compiling canvas.");

Then invoke the compiler with -lp console-debug.properties:
lzc -lp console-debug.properties test/hello.lzx

...and you'll see log messages for the level you specified and  
higher, for that class or package only.

-ben
Phillip G. Apley | 2 Sep 01:40
Favicon

SWF to PNG substitution code for DHTML


So, I committed all the PNGs.

I wrote and debugged this patch to the point that:
    1. It compiles without error
    2. It appears to find the right files in the few tests I've done.

For example:
lzc -lp $LPS_HOME/console-debug.properties layouttest.lzx --runtime=dhtml

    3. There's still something wrong, since the file does not load anything
into the browser when the file is viewed. I include the output file for
inspection.

    4. I've run out of time for today. If someone finds a consistent
conversion error with the PNGs I can redo them over the weekend.

I'd also like to apologize that the code changes are not as nicely
modularized as I would have liked. Making a class ResourceFileResolver that
specializes FileResolver would probably be the right way to do it, but it
would have taken me longer because other changes would have had to be made.

Use the enclosed console-debug.properties for debugging with the expression
above.

I hope this is some help.

I'll be in Canada over the weekend and you're welcome to call my cell phone
or skype, but there's no guarantee you'll get through. If you do I'll be
happy to answer any questions.

Phill

Attachment (patch.papley.8Mdy.tgz): application/octet-stream, 3024 bytes
Attachment (PGALegalsDiff.bin): application/octet-stream, 8 KiB
Attachment (layouttest.swf): application/octet-stream, 77 KiB
Attachment (console-debug.properties): application/octet-stream, 115 bytes

_______________________________________________
Laszlo-dev mailing list
Laszlo-dev <at> openlaszlo.org
http://www.openlaszlo.org/mailman/listinfo/laszlo-dev
Jim Grandy | 2 Sep 01:47
Favicon

Announcing Legals PR3

It is with pleasure that we announce our third Legals snapshot,  
Legals PR3. PR3 is available in the following ways:

* Prebuilt installers are available at http://www.openlaszlo.org/ 
download

* Sources are available at http://svn.openlaszlo.org/openlaszlo/tags/ 
legalspr3

The OpenLaszlo Legals PR3 snapshot represents the current state of  
the Legals project, the goal of which is to make OpenLaszlo a true  
multi-runtime environment by supporting DHTML in addition to SWF.

With this snapshot, the refactoring phase of Legals is essentially  
done: you will find the first complete kernel API spec, separate  
DHTML and SWF7-8 kernels, a target-agnostic runtime, and a number of  
pervasive improvements to the runtime sources themselves.

In addition, IE6 and Firefox 1.5 support have improved, and LZPIX  
runs reasonably well on Safari 2.0.4 and Opera 9. We are also keeping  
a close eye on IE7, Firefox 2, the Mozilla nightly build (aka  
Minefield), and the Safari nightly build (aka Webkit).

Since PR3 is a snapshot and development continues to proceed rapidly,  
if you want to work with the latest Legals sources we encourage you  
to download a nightly build. These can be found at http:// 
www.openlaszlo.org/download, or you can download the latest Legals  
sources from http://svn.openlaszlo.org/openlaszlo/branches/legals.
Adam Wolff | 2 Sep 02:12
Favicon

css $style pass

Hi Tucker,
Ben found a bug with using $style in a class definition. Given:
    <class name="super" bgcolor="${ 'stylea1' }"/>
    <class name="sub" extends="super" x="${ 'stylea2' }"/>

An instance of sub doesn't get the styled value. In general, this kind of
thing is handled by passing the collected style attributes as an Object,
which are then attached to the superclass version of the same in the ugly
loop at the top of the LzNode constructor. Since right now, the $style
attribute is a function, this object composition isn't happening.

Thoughts? Feelings? Seems like the easiest thing to do would be to pass
$styles as a hash.

A
Benjamin Shine | 2 Sep 08:08
Favicon

For Review: Change change.sr9shiP1d.txt Summary: Added more tests for LzText, font color and style

I feel kind of weird about this change; I'm not sure we really expect  
the LzText api's to work the way I've written the tests. Seems like  
the text api is in motion as we move to legals. The implementation  
has improved so much (in legals) that I think we might need to port  
some of the improvements in the legals LzText.lzs and LzTextSprite.as  
back into trunk, in order to write css text formatting sanely.

Change change.sr9shiP1d.txt by ben <at> cooper.local /Users/ben/src/svn/ 
openlaszlo/trunk on 2006-09-01 22:48:29 PDT

Summary: Added more tests for LzText, font color and style

New Features:

Bugs Fixed:

Technical Reviewer: pbromanik, max
QA Reviewer: (pending)
Doc Reviewer: (pending)

Documentation:
Most of the tests I just added fail in trunk; these are pretty much  
expected failures, because we know that text color and fontstyle  
handling in trunk are problematic. I'm curious as to whether they  
will work in legals. We really want to be able to control text  
properties as just another attribute.

Release Notes:

Details:

Tests:
http://localhost:8080/trunk/test/lztest/lztest-text.lzx

Files:
M      test/lztest/lztest-text.lzx

Attachment (patch.ben.2VNb.tgz): application/octet-stream, 1787 bytes

_______________________________________________
Laszlo-dev mailing list
Laszlo-dev <at> openlaszlo.org
http://www.openlaszlo.org/mailman/listinfo/laszlo-dev
Max Carlson | 2 Sep 19:15
Favicon

Re: For Review: Change change.sr9shiP1d.txt Summary: Added more tests for LzText, font color and style

The text APIs are still in flux for legals.  If you have any specific 
suggestions about how to improve them, let us know!  I agree that all 
text properties should be controllable via attributes.  The fact that 
they aren't in trunk is likely an oversight and should be fixed...

-Max

Benjamin Shine wrote:
> I feel kind of weird about this change; I'm not sure we really expect 
> the LzText api's to work the way I've written the tests. Seems like the 
> text api is in motion as we move to legals. The implementation has 
> improved so much (in legals) that I think we might need to port some of 
> the improvements in the legals LzText.lzs and LzTextSprite.as back into 
> trunk, in order to write css text formatting sanely.
> 
> Change change.sr9shiP1d.txt by ben <at> cooper.local 
> /Users/ben/src/svn/openlaszlo/trunk on 2006-09-01 22:48:29 PDT
> 
> Summary: Added more tests for LzText, font color and style
> 
> New Features:
> 
> Bugs Fixed:
> 
> Technical Reviewer: pbromanik, max
> QA Reviewer: (pending)
> Doc Reviewer: (pending)
> 
> Documentation:
> Most of the tests I just added fail in trunk; these are pretty much 
> expected failures, because we know that text color and fontstyle 
> handling in trunk are problematic. I'm curious as to whether they will 
> work in legals. We really want to be able to control text properties as 
> just another attribute.
> 
> Release Notes:
> 
> Details:
> 
> 
> Tests:
> http://localhost:8080/trunk/test/lztest/lztest-text.lzx
> 
> Files:
> M      test/lztest/lztest-text.lzx
> 
> 

Gmane