headers
John Sundman | 1 Dec 01:08
Favicon

Re: For Review: Change 20061130-jgrandyw-t Summary:Merge js2doc tools from private branch

Wow. Now I know how the rest of the OL team has felt for the last  
year.  This really is pulling the tablecloth out from under the dishes:

> D      docs/src/wrappers/animatorgroup.html
> D      docs/src/wrappers/node.html
> D      docs/src/wrappers/animator.html
> D      docs/src/wrappers/lzdataelement.html
> D      docs/src/wrappers/layout.html
> D      docs/src/wrappers/canvas.html
> D      docs/src/wrappers/class.html
> A  +   docs/src/xsl/js2doc2dbk.xsl

Go for it, Jim.  This is one ambitious project, ain't it.

jrs

On Nov 30, 2006, at 6:51 PM, Jim Grandy wrote:

> Change 20061130-jgrandyw-t by jgrandyw <at> jgrandy-pb.local on  
> 2006-11-30 15:44:14 PST
>     in /Users/jgrandyw/dev/svn/openlaszlo/branches/legals
>
> Summary:Merge js2doc tools from private branch
>
> New Features:New tool, js2doc, that extracts comments from js2  
> files and places them in an xml file. Ant tasks for docs/src that  
> extract documentation from the LFC and renders them (very roughly)  
> to HTML.
>
> Bugs Fixed:LPP-1436 LPP-1438
(Continue reading)

Permalink | Reply | 0 comments |
headers
Henry Minsky | 1 Dec 04:29
Picon

Re: LzNode initialization order proposal

>
> We propose an initial implementation to approximate this behavior for
> testing in Beta 1:  During LzNode.initialize LzEvent.sendEvent will
> be intercepted and queued and as the last step of initialization,
> that queue will be drained.
>

So, I'm trying to implement queuing up the sendEvents,  I wanted to
put some code in the
default sendEvent handler method on LzDeclaredEvent, but given that
we're calling this.onfoo.sendEvent(...), I can't see how to figure out
what the value of "this"  (the calling lznode) is when I am inside of
LzEvent.sendEvent, so I can queue that info up.

It would be better if we had used
LzNode .sendEvent(this.event, arg) instead of this.event.sendEvent(arg).
Permalink | Reply | 1 comment |
headers
Max Carlson | 1 Dec 05:31
Favicon

For Review: Change 20061130-maxcarlson-a Summary: Updated: Eliminate css include and write css out dynamically instead

Change 20061130-maxcarlson-a by maxcarlson <at> max-carlsons- 
computer.local on 2006-11-30 20:30:11 PST
     in /Users/maxcarlson/openlaszlo/legals

Summary: Updated: Eliminate css include and write css out dynamically  
instead

New Features:

Bugs Fixed:

Technical Reviewer: promanik
QA Reviewer: ptw
Doc Reviewer: (pending)

Documentation:

Release Notes:

Details:  This centralizes css defaults in the dhtml sprite where  
they belong.  Use lzOptions in wrapper only when required - DHTML  
needs the server root for blank images.  Fix minor brain-oh in  
LzTextSprite.js.  Eliminated extra blank image load for every  
resource in IE.  Updated text measurement to account for multiline  
text.  Canvas is hidden during init time - speeding startup time.

Tests: All apps run as they did before - but faster!

Files:
M      WEB-INF/lps/lfc/kernel/dhtml/LzSprite.js
(Continue reading)

Permalink | Reply | 0 comments |
headers
Benjamin Shine | 1 Dec 05:45
Favicon

modified wrapper pages


Max, can you please summarize in a few sentences the changes to the  
wrapper/embed pages in Beta1? Not the exact details of how to use  
them, but an overview of what was changed and why.

(This is for the release notes.)

benjamin shine
software engineer
ben <at> laszlosystems.com
Permalink | Reply | 1 comment |
headers
Benjamin Shine | 1 Dec 05:55
Favicon

mixins and traits and interfaces, new class regime


Tucker, can you please give me a one or two sentence description for  
the release notes -- The bug lists and your notes list mixins,  
interfaces, traits. What does a person considering upgrading to 4.0B1  
need to know about mixins, traits, and interfaces?

Similarly, what does an application developer need to know about the  
new class regime?

benjamin shine
software engineer
ben <at> laszlosystems.com
Permalink | Reply | 1 comment |
headers
Benjamin Shine | 1 Dec 06:02
Favicon

release notes on resource loading


Phill, can you please describe, at a high level, the options and  
mechanisms available in the autopng tool?
Is the offline batch asset generation available for outsiders to use?  
Is it documented enough for someone to use it?
Can you please also describe the server-side changes which support  
the autoPng mechanism?
benjamin shine
software engineer
ben <at> laszlosystems.com
Permalink | Reply | 1 comment |
headers
Benjamin Shine | 1 Dec 06:14
Favicon

implicit this


Is this a good moment to document the implicit this problem? are we  
now entering into a land without implicit this? At least, we should  
put a note in the release notes saying "you used to be able to  
do .... but now that won't work. instead make this explicit, like  
so: .... "

benjamin shine
software engineer
ben <at> laszlosystems.com
Permalink | Reply | 2 comments |
headers
Jim Grandy | 1 Dec 08:28
Favicon

question about adding field decls to classes

A JS2 question: what are the side-effects (runtime-detectable  
changes) to expect from adding a field declaration for a field that  
is already used post-construction? There's a fairly common idiom in  
the LFC to document a field only when it is first used (this.foo =  
10), and I'd like to hoist the documentation to a formal class field  
declaration (var foo), but want to make certain I'm not changing the  
program's meaning.

What about adding initial values to field declarations that didn't  
have them before? Any behavioral or performance impact? I'm trying  
not to do this, even though the schema specifies default values that  
are not expressed in the LFC, but in a few places it appears to make  
sense.

jim
Permalink | Reply | 3 comments |
headers
P T Withington | 1 Dec 12:59
Favicon

Re: LzNode initialization order proposal

On 2006-11-30, at 22:29 EST, Henry Minsky wrote:

>>
>> We propose an initial implementation to approximate this behavior for
>> testing in Beta 1:  During LzNode.initialize LzEvent.sendEvent will
>> be intercepted and queued and as the last step of initialization,
>> that queue will be drained.
>>
>
> So, I'm trying to implement queuing up the sendEvents,  I wanted to
> put some code in the
> default sendEvent handler method on LzDeclaredEvent, but given that
> we're calling this.onfoo.sendEvent(...), I can't see how to figure out
> what the value of "this"  (the calling lznode) is when I am inside of
> LzEvent.sendEvent, so I can queue that info up.
>
>
> It would be better if we had used
> LzNode .sendEvent(this.event, arg) instead of this.event.sendEvent 
> (arg).

Yes, that's my proposal, to make LzNode be both an event sender and  
an event target, more DOM-like.  But for now:

We don't need to defer events sent to LzDeclaredEvent, because those  
have no handlers.  When we _do_ install a handler, we create a real  
event (which _can_ defer events) and we call the handler once,  
immediately, in case there were any events missed.  (Hm, we're still  
missing the argument to the event.  Perhaps that doesn't work after  
all.)
(Continue reading)

Permalink | Reply | 0 comments |
headers
P T Withington | 1 Dec 13:27
Favicon

Re: mixins and traits and interfaces, new class regime

On 2006-11-30, at 23:55 EST, Benjamin Shine wrote:

>
> Tucker, can you please give me a one or two sentence description  
> for the release notes -- The bug lists and your notes list mixins,  
> interfaces, traits. What does a person considering upgrading to  
> 4.0B1 need to know about mixins, traits, and interfaces?

Nothing really.  Since they are not currently exposed to LZX (and  
they don't yet work in LZX <script> blocks, for obscure reasons).   
They have been implemented in the LFC core to support (and extend)  
Javascript 2 `class` declarations portably.

Briefly, the _LFC_ developer can now write Javascript 2 `class`  
declarations, rather than creating their classes using Javascript 1  
prototypes.  The Javascript 2 `interface` declaration is supported,  
but not enforced (that is, there is no compile or runtime checking  
that a class actually implements an interface).

We have extended Javascript 2 to support `mixin` declarations.  See  
[BrachaCook90](http://portal.acm.org/citation.cfm? 
id=97982&coll=portal&dl=ACM) for a formal definition of mixins.   
Informally, mixins are 'interfaces with implementation'.  They take  
the same form as a `class` declaration, but are introduced by the  
keyword `mixin`.  They are added to a class similarly to an  
interface, but with the keyword `with`.  They are allowed to add  
methods and fields to the class they are mixed in to.  They are  
allowed to override methods in the superclass and other mixins, but  
note many O-O theorists feel this generality leads to [inscrutable  
programs.][1]
(Continue reading)

Permalink | Reply | 0 comments |

Gmane