[xinf] DOM Events?

Fri Jun 23 18:12:56 CEST 2006

This is thinking out loud :-)  It has been a long crappy week and I'm
aching to get home and eat something, so I may not be thinking straight
;)

Lee

________________________________

From: xinf-bounces at xinf.org [mailto:xinf-bounces at xinf.org] On Behalf Of
Lee McColl-Sylvester
Sent: 23 June 2006 17:12
To: xinf is not flash
Subject: Re: [xinf] DOM Events?

That sounds a lot better, though still leaves a number of issues...

Hmmmmmmmm.............

You almost need a way in which you can serialize the type identifier for
cross applications transportation.  Maybe XML again, only not external
to haXe.

How about, within haxe, simple string references are used, but include
the ability to access the information regarding the events external to
the application using XML serialized from those string identifiers?
This would also mean that further information, in simple string format,
could be included in the serialization for consumption by those external
applications.  The transfer would be two way, of course, which means
that a class will need to be included in the haXe side which includes
the serializer / deserializer, while a C version would exist in the VM
for calls made to or from the other side of the fence.

Lee

________________________________

From: xinf-bounces at xinf.org [mailto:xinf-bounces at xinf.org] On Behalf Of
hank williams
Sent: 23 June 2006 16:56
To: xinf is not flash
Subject: Re: [xinf] DOM Events?

If you use enums, then you cant communicate with the outside world. You
couldnt optionally add this to an existing enum based model. Though you
could have two totally separate system, thought that seems clunky to me
as well. 

As I said in my last post, I actually think my system would not impose
any burden on the programmer if done right because they wouldnt need to
see it.

On additional thought is if enums could be strings instead of numbers
then we *could* have the best of both worlds! This would require a
change or enhancement to haxe, but it might just solve the problem if
haxe could allow a string to define a type within the compiler. Then we
wouldnt need to infer a compled type from its field types, we could
absolutely determine its type based perhaps in part by the fields but in
conjunction with a string. 

Hank

On 6/23/06, Lee McColl-Sylvester <lee.mccoll at lyons-group.co.uk> wrote:

Sounds to me like two options are going to be necessary.  Perhaps a
loose Xml layer that will need to be constucted by hand (or force
exported) and linked in order to provide cross platform integration,
while standard events usage would have no such requirement, so no Xml
file.

Lee

________________________________

From: xinf-bounces at xinf.org [mailto: xinf-bounces at xinf.org
<mailto:xinf-bounces at xinf.org> ] On Behalf Of hank williams
Sent: 23 June 2006 16:44

To: xinf is not flash
Subject: Re: [xinf] DOM Events?

I agree, it is a little clunky. But I think it solves the problem in a
way that satisfies all the requirements. In actuality, the user would
never come across this directory unless they were doing cross platform
stuff. Otherwise, haXe could do all of this without the user even
knowing. Even the directory would not have to be defined on the command
line. It could be a default unless changed kind of thing. But yes, if
you need to do the kind of thing that Dan and I are doing i.e. cross
platforms etc., there is an extra, clunky step. But for me it would be
worth it. For everyone else, it could be seamless.

Hank

On 6/23/06, Lee McColl-Sylvester <lee.mccoll at lyons-group.co.uk> wrote:

That's a little clunky, though, don't you think?  Maybe an XML object
that you can include as a resource, but even then it's clunky

Lee

________________________________

From: xinf-bounces at xinf.org [mailto: xinf-bounces at xinf.org
<mailto:xinf-bounces at xinf.org> ] On Behalf Of hank williams
Sent: 23 June 2006 16:34

To: xinf is not flash
Subject: Re: [xinf] DOM Events?

Ok, so I am going to suggest what I said before was my idea as to how to
resolve this issue. Remember Nicolas you promised to listen :). It would
require a change to haxe, but it could solve the problem.

Basically, when a file or project is compiled, an "events identifier"
directory is identified on the command line. The file contains a
platform neutral (XML) description which includes the unique name of all
the events published and all the events subscribed to. Each XML event
descriptor has as a field a name which helps to semantically
disambiguate. Each event descriptor also has all the fields and field
types for the data associated with the event. 

So within the events identifier directory there are two folders, one for
published events, and one for subscribed to events. The compiler
generates an error if any event in the subscribers folder has a name
that matches a name in the publishers folder but where the event field
types do not match. 

This would allow for Nicloas's type checking at compilation time. It
would also allow cross platform communications by allowing other
languages to see what events are available for a given module, and how
to communicate with it. No specialized code would be required for anyone
to play here. Of course your C code isnt going to get the benefit of the
type checking without a preprocessor, but even this is possible. 

Of course I havent read the full w3c events spec, but I bet I am just
suggesting something that in some form or another they have already
thought of.

Regards
Hank

On 6/23/06, daniel fischer <dan at f3c.com> wrote:

"hank williams" <hank777 at gmail.com > (on Fri, 23 Jun 2006 10:04:59
-0400):

  > I need a way to communicate semantic
  > intent of the event. Your system doesnt do that 

seems you are right here. semantics in nicolas' proposal are implied by
the dispatcher variable "name". i'd prefer explicit "event types" ("what
happened?") too. i cannot think of anythin better than string, although
using strings also poses problems... 

deadlocked?

-dan

--
http://0xDF.com/
http://iterative.org/

--
xinf is not flash
http://xinf.org/ 

--
xinf is not flash
http://xinf.org/

--
xinf is not flash
http://xinf.org/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://xinf.org/pipermail/xinf/attachments/20060623/81976a2b/attachment.html 