Re: Modular and Styled OL Application

Hi,

Leonardo Mateo wrote:
> On Wed, Jun 18, 2008 at 8:17 PM, Dave Miller <dwmiller@...> wrote:
> 
>>> On Wed, Jun 18, 2008 at 1:28 PM, Greg Denton wrote:
>>> A sympathetic note....#2 is a real pain. I asked the same question a
>>> while back. I wound up rewriting all of the component classes (using
>>> the base classes) that my app uses as the lz ones are so ugly and only
>>> minimally styleable (color, font). It turns out that the data handling
>>> for the components was not what I liked anyway, and I needed to do
>>> selection management, so it was inevitable. I had to create a whole
>>> application framework to do what I wanted. Lots of time. What I have
>>> now is valuable (in terms of functionality) but has to be closely
>>> maintained. I'm sure a lot of developers are doing the same thing.
> 

Do you guys have plans on open sourcing some of your components?  Maybe 
we can work together on writing custom components or something... =)

[ simon.cpu ]
p.s.: Any news on regex support for edittext?

--

-- 
And /usr/games/fortune futurama says:

Pop a Poppler in your mouth
When you come to Fishy Joe's
What they're made of is a mystery

Now Available: 4.1 DHTML Recommended release

We are proud to announce the release of OpenLaszlo 4.1.

OpenLaszlo 4.1 is a major release bringing full support for both the  
DHTML/Ajax and the SWF/Flash platforms. It also includes over 800 bug  
fixes and a significantly improved documentation suite.

OpenLaszlo 4.1 has been fully-qualified across the following browser/ 
platform combinations: Safari3/OSX, Firefox2/OSX, Internet Explorer 7/ 
WinXP, Firefox 2/WinXP, and Firefox 2/Linux. We have tested the full  
suite of demos, samplers, and example applications with the  
requirement that, when possible, DHTML applications behave the same as  
their SWF counterparts.

OpenLaszlo 4.1 is now the recommended release for all developers on  
all platforms, and current users of OL 3.x and 4.0 should investigate  
upgrading to this new release.

Preliminary support for SWF9 is included in this release but has not  
been enabled in the developer console. If you want to try this new  
functionality, you can find  more information on using the SWF9  
support in the Release Notes (link to come).

For every release, we rely on the OpenLaszlo community to help ensure  
the quality of the platform release and to determine its future  
direction. To propose or participate in discussion of new features,  
see the  Wiki ( http://wiki.openlaszlo.org/Enhancement_Proposals ). We  
encourage you to report any problems, and to make suggestions for  
enhancements, through our JIRA bug tracking system ( http://www.openlaszlo.org/jira/browse/LPP 
  ). We'd also like to hear from you on the mailing lists ( http://www.openlaszlo.org/lists 
  ) and in the forums ( http://forum.openlaszlo.org ).

Re: Modular and Styled OL Application

I have no plans to open source due to (1) the time required, (2) the
fact that my components are not complete and not stylable either, and
(3) the feeling that since much of the power of the framework rests on
(tight) integration with the special "xml model" layer it would not be
as valuable to others.

It would require a bit of work to redesign for less coupling between
these subsystems (for "mixing and matching"). I also took a lot of
performance shortcuts/improvements by favoring callbacks over events.
The subsystems are all pretty tightly integrated:

- recoding of form components for my own graphic look and to be data
driven using the xml model code
- extension to command functionality for execution and subcommands,
tied to context menus and selection
- selection management: tied to commands, extended tree and form
selection, window activation
- drag/drop: special dragger code, integrated with sink registration
- xml models supporting "deleting" notifications, undo/redo, cross
references/dependencies between objects

Oddly, after all this work there is a hard show stopper for me: lack
of REST support for SOLO apps :(.

If you would like some input to a discussion of OL frameworks let me know.

On Mon, Jun 30, 2008 at 9:27 PM, Simon Cornelius P. Umacob
<simoncpu@...> wrote:
>
> Hi,

Re: Modular and Styled OL Application

This is a great discussion!  The fact is, the current component set 
needs modernization to be more easily extensible, styleable, etc.  It's 
  an old code base that's been brought along as the runtime has been 
modernized.  There's lots of room for improvement!

Right now the OpenLaszlo team is focused on Flash 9 support, which 
promises to bring huge performance benefits.  As you know, rewriting 
components is a big job and something do plan to do with the community's 
help.

Of course, we'd love any contributions, even if it's just towards the 
design.  It would be great to get some more specifics about which design 
choices you made, and why.  For example, what about the existing 
selection and drag/drop management didn't work for you?  Were things 
broken or did you just need to extend them?

Also, it sounds like some of the smaller bits could be very useful to 
the community, e.g. subcommands, especially if they are integrated into 
the LFC.

It's really valuable to know what problems you faced with the language 
and any APIs and extension points you needed so we can make sure they're 
addressed in the next round.

And yes, I agree fully about XML models needing to send a 'delete' 
event.  REST support is critical - what issues are you seeing?  I want 
to make sure this is working.

Thanks for being a part of the community, and giving such astute feedback!

Re: Modular and Styled OL Application

Note to self, check if the SWF9 URL Loader API supports REST semantics...

On Tue, Jul 1, 2008 at 7:20 PM, Max Carlson <max@...> wrote:
> This is a great discussion!  The fact is, the current component set needs
> modernization to be more easily extensible, styleable, etc.  It's  an old
> code base that's been brought along as the runtime has been modernized.
>  There's lots of room for improvement!
>
> Right now the OpenLaszlo team is focused on Flash 9 support, which promises
> to bring huge performance benefits.  As you know, rewriting components is a
> big job and something do plan to do with the community's help.
>
> Of course, we'd love any contributions, even if it's just towards the
> design.  It would be great to get some more specifics about which design
> choices you made, and why.  For example, what about the existing selection
> and drag/drop management didn't work for you?  Were things broken or did you
> just need to extend them?
>
> Also, it sounds like some of the smaller bits could be very useful to the
> community, e.g. subcommands, especially if they are integrated into the LFC.
>
> It's really valuable to know what problems you faced with the language and
> any APIs and extension points you needed so we can make sure they're
> addressed in the next round.
>
> And yes, I agree fully about XML models needing to send a 'delete' event.
>  REST support is critical - what issues are you seeing?  I want to make sure
> this is working.
>
> Thanks for being a part of the community, and giving such astute feedback!

Global aliases to Services removed from 4.1.x (sources and nightly builds)

The following deprecated global aliases to services have been removed  
in trunk:

   LzAudio
   LzBrowser
   LzCursor
   LzFocus
   LzGlobalMouse
   LzHistory
   LzIdle
   LzInstantiator
   LzKeys
   LzModeManager
   LzTimer
   LzTrack

Each of the services is still accessible though the `lz` package,  
using the service name without the 'Lz'.  For example, LzFocus can be  
found at lz.Focus.  The package entries are already available in  
4.1.0, so you can make this change in your code now, in preparation  
for any subsequent release.

If you plan to use trunk r10175 or later you should run the script / 
WEB-INF/lps/server/bin/convert_required.pl on your lzx files to make  
the required modifications.  You can also find the script
[here](http://svn.openlaszlo.org/openlaszlo/trunk/WEB-INF/lps/server/bin/convert_required.pl 
 >http://svn.openlaszlo.org/openlaszlo/trunk/WEB-INF/lps/server/bin/convert_required.pl) 
.

API change proposal: Disallow <method> in <state>

[Cf.: http://jira.openlaszlo.org/jira/browse/LPP-5624]

In the current system, LZX developers have sometimes written methods  
inside states.  As far as we can tell, this is neither explicitly  
supported or unsupported, but it happens to work for swf and dhtml.   
It can't work for static runtimes like swf9 (or other JS2's), because  
states can be placed, so the compiler cannot tell at compile time  
which class these methods really belong to -- they are dynamically  
attached to instances at runtime.  We have tried a number of ideas to  
work around this issue with no success and currently this is one of  
the major roadblocks to getting some applications working in swf9.  We  
propose making the following API change for states:

1) The <method> tag is not permitted in the <state> tag.

2) Introduce a new tag, <function>, which is allowed anywhere <method>  
is allowed and is also allowed in <state>.  <function> behaves exactly  
as <method> does, except that:

  a) it does not support (what we call) "implicit this" and
  b) you cannot make `super` calls from a function.

In the body of a function, if you want to access the members of the  
instance the function was called on, you must explicitly say  
`this.<membername>`.  Saying `<name>` without qualification in the  
body of a function can only be used to refer to globals, parameters,  
and local variables of the function.

What this means to the LZX developer:

Generic code

Hi guys, I've been googling for some tip about write generic code with OL (by 
generic, I mean to work for both SWF and DHTML) by can't find anything 
useful. I asked in the forum too, but no luck (I don't know how many of you 
see both, forum and list, so I decided to ask here too).

Anyone can point me to somewhere I can read about this? O even better, share 
your experience about this situation?

Thanx a lot in advance.

--

-- 
Leonardo Mateo.
There's no place like ~

Dynamically call in runtime a set of actions

Deleting imported libraries clarification

I've put some optional code of my app into a dynamic library.  When an 
instance of one of the classes is needed, I do a load on the library and 
create the instance after the onload() handler.  I've been reading the 
Software Engineer's Guide, aka Developer's Guide, in 15.5 "Deleting 
Imported Libraries".  It's pretty short, so I'll include it here:

    5. Deleting Imported Libraries

To 'unload' an imported library, three things have to be done:

   1.

      Destroy all the instances that were created by the library. This
      is done by calling |iii.destroy();| for each instance |iii|. Note
      that if you have created references to the instance outside of the
      library, you must delete those references.

   2.

      Destroy all classes that were created by the snippet. This is done
      by calling |ccc.destroy();| for each class |ccc|. Note that if you
      have created references to the class outside of the library, you
      must delete those references.

   3.

      Unload the library. This is done by calling |sss.unload()`| where
      |sss| is the name of the library (in the import tag).

-----------------------------------------
I have run destroy() on the instances of the classes from the imported 
library.

I'm not being successful on step 2.  I'm running OL 4.0.12 and tried 
lz['employeeMaintenanceWindow'].destroy() but get the dreaded "ERROR 
 <at> vr.lzx#600: call to undefined method 'destroy'".  I can write to the 
debug console the class name and reference:

global class  employeeMaintenanceWindow  is «¡¿Class?!#12| 
lz.employeeMaintenanceWindow».

I am able to do step 3 and run the unload() of the library using the 
name from the import.  However, when I run code that needs a class from 
the library and I load() it again, I get these warnings:

snippetLoaded loadmc= «LoadObj#2| undefined (loading)» 
«LzLibraryLoader#18| undefined (loading)»
WARNING: Redefining tag employeeMaintenanceWindow from 
lz.employeeMaintenanceWindow to employeeMaintenanceWindow
INFO: The global `employeeMaintenanceWindow` is already defined.  To 
dynamically create a <employeeMaintenanceWindow> element, you will have 
to use `lz.employeeMaintenanceWindow`.

What's the syntax that I should use to remove the global class 
definition?  Or is it still a requirement to do that?...or am I just 
misunderstanding something...

Thanks,
Cary