Hi Tim

Reading through your recent posts on the EWB framework I can see the
logic for sticking within EWB for the visual aspects of an application.
One non-visual JS library I was banking on being able to use, however,
is the new RemObjects Javascript client (almost all of my apps sit on a
RemObjects core). A key part of RO clients is an interface unit that is
generated by the RO framework and so changes as the server-side app changes.

I realise this is verging on a support question so I don't expect an
immediate answer, but a guide on how to interface with such non-visual
JS units would be very welcome. I'm going through WebDOM but as a
JavaScript/Web app newbie it'll probably take a while....

Thanks, Bob

Bob,

<< I realise this is verging on a support question so I don't expect an
immediate answer, but a guide on how to interface with such non-visual JS
units would be very welcome. I'm going through WebDOM but as a
JavaScript/Web app newbie it'll probably take a while.... >>

Check out the use of the "external" keyword, and particularly how the WebDOM
unit sets up properties as read/write/read-write.  What you effectively do
is tell the compiler what the various object interfaces/functions/procedures
"look like".  Also, because of this, external object interfaces don't have a
"private" scope for variables/methods.

One big caveat: you *must* get the case-sensitivity correct for all external
declarations, since JS is case-sensitive.  The compiler uses the case of the
external declarations *exactly as specified* when emitted the JS.  However,
the one good thing is that the compiler also automatically uses the case of
the external declarations for all references.  For example, if you define
this object:

  external THTMLImageElement = class(THTMLElement)
     public
        { Properties }
        property alt: String read write;
        property height: Integer read;
        property isMap: Boolean read write;
        property longDesc: String read write;
        property name: String read write;
        property src: String read write;
        property useMap: String read write;
        property width: Integer read;
     end;

But refer to the "src" property in your code as MyElement.SRC, the compiler
will generate the JS in the proper case based upon the original property
declaration -"src", not "SRC".  So, once an external declaration is properly
set up, other developers (or yourself) can merrily use the unit like they
would any other Object Pascal unit, without case-sensitivity.

--
Tim Young
Elevate Software
www.elevatesoft.com

Thanks Tim - I can see that the compiler will know where to look for the
DOM on the local PC (does it always assume IE?), but how do I tell it
where my external Javascript files are? Just stick them in the Framework
directory?

Cheers, Bob



> Check out the use of the "external" keyword, and particularly how the
> WebDOM unit sets up properties as read/write/read-write. What you
> effectively do is tell the compiler what the various object
> interfaces/functions/procedures "look like". Also, because of this,
> external object interfaces don't have a "private" scope for
> variables/methods.
>

Bob,

<< Thanks Tim - I can see that the compiler will know where to look for the
DOM on the local PC (does it always assume IE?), but how do I tell it where
my external Javascript files are? Just stick them in the Framework
directory? >>

Well, that bit is still missing (deployment), so normally that is where you
would specify any external JS files that you want to include.  For now, you
can include them by putting them in the output directory alongside the
application JS, and then modifying the bootstrap.html in order to include a
reference to the JS file.

--
Tim Young
Elevate Software
www.elevatesoft.com