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

[Ralf Bokelberg]

Hi Martin,

i wonder if you understand your mails by yourself ;). Probably it is
better to approach the problems you see with HaXe one after the other.
For example - you could try to implement something like Spring on your
own and if you encounter a concrete problem, you can come up with a
concrete question. What do you think?

Cheers,
Ralf.

On 8/2/06, Marcelo de Moraes Serpa <celoserpa at gmail.com> wrote:
> Nice thoughts. Thanks for sharing
>
>
> On 8/2/06, Martin Heidegger <mastakaneda at gmail.com> wrote:
> >
>
> 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.
>
>
>
> --
> haXe - an open source web programming language
> http://haxe.org
>
>
>
> --
> haXe - an open source web programming language
> http://haxe.org
>
>


-- 
Ralf Bokelberg <ralf.bokelberg at gmail.com>
Flex & Flash Consultant based in Cologne/Germany