I'm sorry Max,
I forgot to mention that I am still on holiday in Barcelona :-)
My comments were in no way whatsoever meant as some plan of action.
Rather they were meant as observations, just simple food for thought.
A pastime if you will.
Not to be taken too seriously but with a grain of salt.
Peace,
Rami
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
