[Laszlo-dev] What does this mean?

[Max Carlson]

On 2/6/10 2:14 PM, Rami Ojares wrote:
> Well a quick look at haxe at least proved that it's documentation is far
> below the OL level.
> Also currently I would have to build most of the gui components from
> scratch.
> (To be honest that's what I had to do with OL also :)
> But what it did have was a good language reference (something OL is
> missing)
> And api's clearly state on which target platform an object works.

If you notice specific issues with the docs, please use the form at the 
bottom of the page to let us know so can update them.

We try to spell out runtime-specific differences here:
http://wiki.openlaszlo.org/Runtime_Differences
Feel free to edit the wiki page and/or let us know if you run across 
anything missing!

I agree the documentation should clearly state when an API won't work 
for a specific runtime.  Currently, it's possible to check the 
view/canvas.capabilities hash at runtime and the debugger warns when a 
runtime doesn't support a feature - which on DHTML can vary depending on 
the browser.  Since this table is currently built at runtime (and the 
docs are generated at compile time) it's would be hard to automate 
putting the details into the docs.

It's probably best to manually edit the doc comments - the community can 
help by using the change request form at the bottom of each doc page, 
and/or filing bugs in JIRA.

> I feel that OL should have a core api, objects that need a target
> platform specific implementation.
> These would be implemented with performance on the target platform in mind.
> If you then develop components using this api, you would know that they
> work on all supported platforms.
> This api would be concise and conservative (obvious examples: view,
> drawview, Timer (oops that's a camelcase :))

I've been thinking it would be nice to have a series of classes/mixins 
that provide subsets of the view APIs.  This could help make components 
lighter and provide some additional clarity to the documentation.

Currently, there are core Laszlo Foundation Classes (LFC) APIs (e.g. 
view, text, inputtext, etc.) and a sprite system that provides services 
to the LFC for the underlying runtimes.  Unfortunately, the sprite API 
is not currently part of the OL docs but it's available here:
http://svn.openlaszlo.org/openlaszlo/trunk/WEB-INF/lps/lfc/kernel/

We've tried to move all runtime-specific bits into the kernel.  That's 
been essential for easing multi-runtime development, e.g. when something 
is broken on a specific runtime, we know there's likely an issue with 
the kernel code, not the core LFC.  This also minimize the amount of 
code needed to add a new runtime.

> Then you could also have target platform api's if needed.
> Say, laszlo components coded with as3
> And like it already is, you could write code directly meant for one
> target platform.

It's always possible to call into the underlying runtime when you need 
to - but you're going to break cross-runtime compatibility.  OL provides 
ways to conditionalize your LZX or script code for a specific runtime - 
see the lps/components/extensions area for examples of this including 
drawview, html, etc...

So really, you have access to all the underlying runtime goodness you 
need, when you need it.  I often prototype new features this way, then 
move them into the underlying LFC and optimize as needed.

> This would mean cleaning out all the non-crossplatform features from
> core objects.
> Eg. pixellock or clickregion from view (actually I only assume they are
> flash specific)
> These could then be brought back using mixins for those who target flash.

OL aims to support of the entire set of APIs across runtimes, where 
possible.  E.g. pixellock works across runtimes, but clickregion 
currently only works in Flash because the there isn't good clipping path 
support in DHTML yet (other than with SVG/VML) so it's tricky to provide 
clickregion support there.  And, there isn't really a standard format 
that works across Flash and DHTML for vector art - SVG is a possibility 
there.  This hasn't been a huge priority for us though, as it's a ton of 
work for something that folks don't seem to care about.

Video is another interesting example - I've been waiting to see how that 
shakes out, not that Youtube and others are adding native HTML5 players, 
we really should update videoview for DHTML.

> Now the components and OL core api are all mixed up.
> This adds to confusion.
 >
> Basically my point is that instead of writing more backends, I would
> like to see more clarity in the laszlo software stack.
> And it is my firm belief that with this added clarity and documentation
> OL would become more open.
> And prosper better in the opensource community.
> Because the biggest reason for not contributing is lack of understanding
> and insecurity that rises from the previous.

I agree the documentation could use more clarity - if anything, there's 
a lot there to take in.  It would be great to see things broken up into 
more logical, digestible chunks.  lz.view is pretty large and complex 
now.  Please let us know if you can think of other strategies.

I also want to see better LZX components.  I think that's where the 
community can help the most, as it's currently the best 
documented/accessible part of the system.

I've been having fun sketching in that domain - making extensive use of 
mixins.  I'm hoping to release something for comment soon.

Thanks for your thoughts, let's keep this conversation going!

> This does not mean that I am opposed to any backend, of course.
>
> - rami
>
>> 6.2.2010 19:34, Raju Bitter kirjoitti:
>>> Check out what the haXe folks did
>> Damn! I wasn't aware of this haxe at all.
>> Looks pretty good on paper.
>> Architecture has the kind of clarity I wished OL would have.
>> Has anyone done any comparisons between OL and haxe?
>>
>> - rami
>