headers
Sebastian Wagner | 1 Sep 11:23
Picon
Gravatar

using SWC-Libraries in SWF9, using ActionScript3 Libraries

hi,

there are numerous of SWC-Libraries available for Flex. How can we make them available in OpenLaszlo in SWF9? Is there a Library directory on Server Side where I can put all my SWC libraries? Or can I pass *manually* library-Files to the mxml-Compiler by adding some attributes to the LZX-App?

What do you think? Any ideas on how-to implement that?

You can test that by for example using the flexlib.swc of the Flexlib Project: http://code.google.com/p/flexlib/downloads/list

The other question would be how-to load simple Actionscript3 Libraries to the Application. For example the XIFF library (http://www.igniterealtime.org/projects/xiff/) for instant messaging using the Jabber protocol.

Is this already on the todo list of features for SWF9? Idea's howto implement it?

sebastian

--
Sebastian Wagner
http://www.webbase-design.de
http://openmeetings.googlecode.com
http://www.laszlo-forum.de
seba.wagner <at> gmail.com
Permalink | Reply | 4 comments |
headers
Henry Minsky | 1 Sep 15:50
Favicon

Re: using SWC-Libraries in SWF9, using ActionScript3 Libraries



On Mon, Sep 1, 2008 at 5:23 AM, Sebastian Wagner <seba.wagner <at> gmail.com> wrote:
hi,

there are numerous of SWC-Libraries available for Flex. How can we make them available in OpenLaszlo in SWF9? Is there a Library directory on Server Side where I can put all my SWC libraries? Or can I pass *manually* library-Files to the mxml-Compiler by adding some attributes to the LZX-App?

What do you think? Any ideas on how-to implement that?

That is a good question. I can see advantages to both approaches; if there were a common lib directory, then the developer could put their SWCs in there, and there would be no need to specify a library path explicitly. On the other hand, it would be more modular to put an applications custom SWC libraries inside of the app directory someplace. 

Perhaps we should have two mechanisms;

1)  a common flexlib/ directory which is added as a library path to every compilation, say in WEB-INF/flexlib

2) add a well known directory named "flexlib" which is a subdirectory of the application's directory, to the search path.

The other issue is how to allow the user to conveniently insert the needed as3 "import" statements
at the proper place in their code. We have a mechanism now for hand-written javascript code in the
LFC, which looks like this (this example is from some swf9 kernel code)

public class LzIdleKernel  {

    #passthrough (toplevel:true) {  
    import flash.display.*;
    import flash.events.*;
    import flash.utils.*;
    }#
  

The "passthrough (toplevel:true)" pragma causes the block of code to get inserted inside the default "package" block, but outside of the class declaration, so the code above actually expands to

package {
  
    import flash.display.*;
    import flash.events.*;
    import flash.utils.*;
    public class LzIdleKernel {
 
So this would be sufficient for writing libraries in the style of drawview, or the video library that Raju Bitter
was working on adding swf9 support for.

However we don't have any way to conveniently insert as3 import statments in pure LZX code right now.
Perhaps we need some kind of <passthrough> tag which could allow for that. 





You can test that by for example using the flexlib.swc of the Flexlib Project: http://code.google.com/p/flexlib/downloads/list

The other question would be how-to load simple Actionscript3 Libraries to the Application. For example the XIFF library (http://www.igniterealtime.org/projects/xiff/) for instant messaging using the Jabber protocol.

Do you mean loading as3 libraries at runtime, rather than linking them into the app at compile time? What is the mechanism for doing that in as3 applications? 



Is this already on the todo list of features for SWF9? Idea's howto implement it?

We've been so busy getting the basic swf9 runtime working that we haven't had time to
think about user-defined libraries and runtime loading, but this is a good time to discuss it!




 

sebastian



 



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


Permalink | Reply | 3 comments |
headers
Sebastian Wagner | 1 Sep 16:19
Picon
Gravatar

Re: using SWC-Libraries in SWF9, using ActionScript3 Libraries

hi,

2008/9/1 Henry Minsky <hminsky <at> laszlosystems.com>


On Mon, Sep 1, 2008 at 5:23 AM, Sebastian Wagner <seba.wagner <at> gmail.com> wrote:
hi,

there are numerous of SWC-Libraries available for Flex. How can we make them available in OpenLaszlo in SWF9? Is there a Library directory on Server Side where I can put all my SWC libraries? Or can I pass *manually* library-Files to the mxml-Compiler by adding some attributes to the LZX-App?

What do you think? Any ideas on how-to implement that?

That is a good question. I can see advantages to both approaches; if there were a common lib directory, then the developer could put their SWCs in there, and there would be no need to specify a library path explicitly. On the other hand, it would be more modular to put an applications custom SWC libraries inside of the app directory someplace. 

Perhaps we should have two mechanisms;

1)  a common flexlib/ directory which is added as a library path to every compilation, say in WEB-INF/flexlib

2) add a well known directory named "flexlib" which is a subdirectory of the application's directory, to the search path.

=> I think implementing both ways would be excellent but for getting started the first solution would be sufficient for most of the developers
 

The other issue is how to allow the user to conveniently insert the needed as3 "import" statements
at the proper place in their code. We have a mechanism now for hand-written javascript code in the
LFC, which looks like this (this example is from some swf9 kernel code)

public class LzIdleKernel  {

    #passthrough (toplevel:true) {  
    import flash.display.*;
    import flash.events.*;
    import flash.utils.*;
    }#
  

The "passthrough (toplevel:true)" pragma causes the block of code to get inserted inside the default "package" block, but outside of the class declaration, so the code above actually expands to

package {
  
    import flash.display.*;
    import flash.events.*;
    import flash.utils.*;
    public class LzIdleKernel {
 
So this would be sufficient for writing libraries in the style of drawview, or the video library that Raju Bitter
was working on adding swf9 support for.

However we don't have any way to conveniently insert as3 import statments in pure LZX code right now.
Perhaps we need some kind of <passthrough> tag which could allow for that. 





You can test that by for example using the flexlib.swc of the Flexlib Project: http://code.google.com/p/flexlib/downloads/list

The other question would be how-to load simple Actionscript3 Libraries to the Application. For example the XIFF library (http://www.igniterealtime.org/projects/xiff/) for instant messaging using the Jabber protocol.

Do you mean loading as3 libraries at runtime, rather than linking them into the app at compile time? What is the mechanism for doing that in as3 applications? 
 
=> I mean linking them at compile time. I think in AS3 you cannot reference Classes which are unknown at compile time, so you need them all available at compile time.
For linkage at compile time you just add import statements as you have shown above to your AS3-class or mxml-script area.





Is this already on the todo list of features for SWF9? Idea's howto implement it?

We've been so busy getting the basic swf9 runtime working that we haven't had time to
think about user-defined libraries and runtime loading, but this is a good time to discuss it!




 

sebastian



 



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





--
Sebastian Wagner
http://www.webbase-design.de
http://openmeetings.googlecode.com
http://www.laszlo-forum.de
seba.wagner <at> gmail.com
Permalink | Reply | 2 comments |
headers
J Crowley | 1 Sep 19:41
Favicon

Re: For Review: 20080813-laszlo-2 Summary: An assortment of bug fixes for doc examples

No worries re: lateness.

The reason I put in the ternary operator was because I get an 
ActionScript error:

TypeError: Error #1009: Cannot access a property or method of a null 
object reference.
    at LzApplication()
    at LzSpriteApplication()

...so I have to check for m before trying to access m.value.  There's 
probably a better thing to put there instead of "undefined", though...

And I'll look into the state examples.  Thanks!

Max Carlson wrote:
> Sorry for the late reply.  For the state examples, you should be able 
> to use applied/onapplied for constraints and to find out when the 
> state was applied/unapplied.
>
> Also, why did you have to add a ternary operator (? :) to 
> tag_constraints.lzx?
>
> J Crowley wrote:
>> Change 20080813-laszlo-2 by laszlo <at> T43-L3XEXMW on 2008-08-13 13:19:53 
>> EDT
>>    in /home/laszlo/src/svn/openlaszlo/trunk-solidus
>>    for http://svn.openlaszlo.org/openlaszlo/trunk
>>
>> Summary: An assortment of bug fixes for doc examples
>>
>> New Features:
>>
>> Bugs Fixed: LPP-6778 - "Constraints in tags" example in Constraints 
>> fails with ActionScript error, SWF9
>>            LPP-6783 - Methods, Events, Attributes example 23 is broken
>>            LPP-6785 - States example 2 fails with ActionScript error, 
>> SWF9 exclusive
>>            LPP-6786 - Compilation error in States example 5       
>>            LPP-6787 - Compilation Error in Unit Testing example 1, 
>> SWF9 exclusive
>>
>> Technical Reviewer: max
>> QA Reviewer: henry
>> Doc Reviewer: (pending)
>>
>> Documentation:
>>
>> Release Notes:
>>
>> Details: Updated examples to be compliant with current/new ways
>>    of doing things.
>>
>> Tests: Run each of the modified files and they should compile and
>>    have no ActionScript errors.
>>
>> Files:
>> M      docs/src/developers/programs/states-$5.lzx
>> M      docs/src/developers/programs/states-$2.lzx
>> M      docs/src/developers/programs/states-$6.lzx
>> M      docs/src/developers/programs/databinding-$27.lzx
>> M      docs/src/developers/programs/methods-events-attributes-$23.lzx
>> M      docs/src/developers/programs/lzunit-$1.lzx
>> M      docs/src/developers/programs/tag_constraints.lzx
>>
>> Changeset: 
>> http://svn.openlaszlo.org/openlaszlo/patches/20080813-laszlo-2.tar
>>
>>
>
Permalink | Reply | 0 comments |
headers
André Bargull | 1 Sep 23:30

For Review: Change 20080901-bargull-M9C Summary: dhtml http-loader

Change 20080901-bargull-M9C by bargull <at> dell--p4--2-53 on 2008-09-01 22:32:11
in /home/Admin/src/svn/openlaszlo/trunk
for http://svn.openlaszlo.org/openlaszlo/trunk

Summary: dhtml http-loader

New Features:

Bugs Fixed: LPP-6912

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

Documentation:

Release Notes:

Details:
LzXMLParser:
- changed to a less verbose form
LzXMLTranslator:
- changed to a less verbose form
- removed slashPat, it wasn't referenced anywhere
- use now "localName" (resp. "baseName") instead of manually splitting 
the nsprefix
- removed debug-statements
LzHTTPLoader:
- moved all "static" properties to the beginning
- added local variable in translateXML (LPP-6912)
- fixed/added implementation of getResponseStatus(), 
getResponseHeaders(), getResponseHeader(), getElapsedTime()
- clear response-variables in "open" before doing a new request
- and some other trivial changes (e.g. renamed variables and moved 
functions for consistency)

Tests:
all-data passes
weather (uses nsprefix)

Files:
M WEB-INF/lps/lfc/kernel/dhtml/LzHTTPLoader.js
M WEB-INF/lps/lfc/kernel/dhtml/LzXMLTranslator.js
M WEB-INF/lps/lfc/kernel/dhtml/LzXMLParser.js

Changeset: 
http://svn.openlaszlo.org/openlaszlo/patches/20080901-bargull-M9C.tar
Permalink | Reply | 1 comment |
headers
Philip Romanik | 1 Sep 23:27
Favicon

Wrapping up changes to support setter tag

Hi Tucker,

I'm close to sending out a changeset for the new setter tag in 
components. There are a few edge cases I am cleaning up. Some changes 
to the LFC are necessary so that the setter is the primary codepath 
(LPP-5644). When the review is complete a lot of deprecated warnings 
will be displayed until the components and LFC are converted to use 
setAttribute. This will be a separate changeset.

Why am I telling you this? You're going to be the reviewer!

Thanks!

Phil
Permalink | Reply | 0 comments |
headers
Quirino Zagarese | 2 Sep 11:28

Can this impact on DHTML runtime?

Most of you will already know about this http://www.google.com/googlebooks/chrome/
Google says it will be open to let other browsers increase their capabilities.
JavaScript Virtual Machines will highly improve DHTML performances.
If this is future, does following Adobe runtime releases still make sense?

--
Quirino Zagarese

LaszloItalia Founder (www.laszloitalia.org)
Software Development Manager - Galilaeus s.r.l.
Permalink | Reply | 0 comments |
headers
Amy Muntz | 2 Sep 15:37
Favicon

JIRA updates

Hi All,

We recently tagged a build as a beta version (a separate branch off of 
trunk called 4.2b). This is a checkpoint release for additional swf9 
functionality (js browser communication, HTML tag, xml-rpc, calendar and 
amazon sample applications running, embedded fonts, scaling, etc.). You 
can find it here: http://download.openlaszlo.org/nightly/4.2beta/10833 
This is not a fully-qualified release, rather a checkpoint so that you 
can begin using functionality as it comes online in a stable 
environment. This was the "KrispyKreme" project in JIRA.

Development is ongoing in trunk. This is the least stable, but most 
current branch. Use at our own risk. We have created "HoneyDew (4.2b2)" 
in JIRA to track changes for the next checkpoint release. Please assign 
new bugs and submit potential fixes to HoneyDew for review.

  The final version of 4.2, which will be a fully-qualified release of 
swf9, is named "Dunkin (4.2)" in JIRA.

Thanks,
Amy
Permalink | Reply | 0 comments |
headers
Henry Minsky | 2 Sep 16:36
Favicon

Re: For Review: Change 20080901-bargull-M9C Summary: dhtml http-loader

approved!

On Mon, Sep 1, 2008 at 5:30 PM, André Bargull <andre.bargull <at> udo.edu> wrote:
Change 20080901-bargull-M9C by bargull <at> dell--p4--2-53 on 2008-09-01 22:32:11
in /home/Admin/src/svn/openlaszlo/trunk
for http://svn.openlaszlo.org/openlaszlo/trunk

Summary: dhtml http-loader

New Features:

Bugs Fixed: LPP-6912

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

Documentation:

Release Notes:

Details:
LzXMLParser:
- changed to a less verbose form
LzXMLTranslator:
- changed to a less verbose form
- removed slashPat, it wasn't referenced anywhere
- use now "localName" (resp. "baseName") instead of manually splitting the nsprefix
- removed debug-statements
LzHTTPLoader:
- moved all "static" properties to the beginning
- added local variable in translateXML (LPP-6912)
- fixed/added implementation of getResponseStatus(), getResponseHeaders(), getResponseHeader(), getElapsedTime()
- clear response-variables in "open" before doing a new request
- and some other trivial changes (e.g. renamed variables and moved functions for consistency)


Tests:
all-data passes
weather (uses nsprefix)

Files:
M WEB-INF/lps/lfc/kernel/dhtml/LzHTTPLoader.js
M WEB-INF/lps/lfc/kernel/dhtml/LzXMLTranslator.js
M WEB-INF/lps/lfc/kernel/dhtml/LzXMLParser.js

Changeset: http://svn.openlaszlo.org/openlaszlo/patches/20080901-bargull-M9C.tar





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


Permalink | Reply | 0 comments |
headers
P T Withington | 2 Sep 18:17
Favicon

Re: Wrapping up changes to support setter tag

On 2008-09-01, at 17:27EDT, Philip Romanik wrote:

> Hi Tucker,
>
> I'm close to sending out a changeset for the new setter tag in  
> components. There are a few edge cases I am cleaning up. Some  
> changes to the LFC are necessary so that the setter is the primary  
> codepath (LPP-5644). When the review is complete a lot of deprecated  
> warnings will be displayed until the components and LFC are  
> converted to use setAttribute. This will be a separate changeset.
>
> Why am I telling you this? You're going to be the reviewer!

Oh boy!
Permalink | Reply | 0 comments |

Gmane