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
