[haXe] All my knowledge that gained about programming the last few years.

[Martin Heidegger]

Okay, I know some of my posts to this list have been kindof insurgent and
without the respect for the haXe team.
This post might read different but I want to share my knowledge because haXe
seemt to get into competition
with ruby on rails and haXe wants to be made for it. I think this thoughts
might be inherently important if you
want to create something with real different value:

Configuration of Applications
Because of private contacts I read two books about/related to Spring (
www.springframework.org) that
explain the extreme power of configuration to any application. Most popular
is a xml based - completly modular
configuration that allows any object to be set up for a easy configuration
of an application. Just porting it to
flash was not really senseful because you it took quite a lot of time to
wire the configuration and you exposed
the configuration to any body (you know flash needs to read it). So it
was/is necessary to have a compiler based
configuration that somehow transforms the certain configuration into
application code (which is not only faster
but also closed and using less resources).

Binding of User Interface elements and Code
In Flash I use for every work with Designers the Flash UI and I add the code
to the certain library elements by
class wiring (UI support of Flash: Export for Runtime). You have
same/similar problem with/in javascript: In order
to get valid HTML you just dismiss most of the javascript and wrap it
afterwards around the html nodes. This
means you have proper html code - that works for searchengines whatsoever
and add javascript/ajax functionality
by some rules to the dom code (means straight seperation layer): You can
find a approach at http://www.ripcord.co.nz/behaviour/
and a article at
http://ajaxian.com/archives/ajax-templating-seperation-of-layout-and-logic.
I for myself worked quite
a lot with this approch and got only good response. Thats the reason I
wanted to think a step further and expressed my wish
to a css - like approach for binding. Which got realised in kukit:
http://azax.ree.hu/documentation/kss.

What I think is best would be a binding that defines two things: 1.) the
main functionality of a Object 2.) What methods to be
executed with an object:

MyObject, .MyObject { // any instance of class/library element MyObject or
any element with the class MyObject
  Class: com.project.MyClass; // Direct registry
  Register: Scene; // Takes the Object registered to the key "Scene" from a
central registry
  propertyX: valueX; // sets the properties (defined as properties in the
code
  propertyY: valueY;
}

This is something valueable for the mapping of structure to UI. Of course
you could do that in lots of different ways but this allows to map a certain
response to functionality (which is good imho).

Events
If you analyse events are calls to a list of objects passing all same
parameter with the special ability of interuption of the process. You also
define by a external controller what object needs to be informed. Now you
need to be sure. A event can occur all the time so all you need to be able
is to set what to be executed on a defined event. Scoping (pushing events
into scopes) is daily used by extending a Broadcaster (you save the list
into a scope). In fact this is a filter. Filters are necessary but why not
filtering more generically:

EventRegistry.register(<forevent>, <Call>, <Requirements>); // onload,
openPopup, {scope: window, }
EventRegistry.execute(<event>, <arguments>);

// arguments need to match requirements and it should work good.

This is something that can be done even from server to client ... with ajax.
The Event could be triggered by the server, using continous requests for
events.
Furthermore this could be a language feature ... i mean you need to KNOW
what arguments get passed also what arguments you need to pass. This could
be done by language support ( how ever this looks like ).

Well. I think all of those things are not featured well in current haxe. And
they could lead to a real good thing to work with.

yours
Martin.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.motion-twin.com/pipermail/haxe/attachments/20060802/91039871/attachment.htm