Tim,

We are missing the sessionStorage/localStorage variables in TWindow.

They should be define of TStorage type that should look like (if I get the syntax correct)

external TStorage = class
 public
   property length : integer; read;
   procedure clear;
   function key(n : integer) : String;
   function getItem(const key : String) : String;
   procedure setItem(const key : String; const value : String);
   procedure removeItem(const key : String);
end; // TStorage

Can I second this request, also I think we will need "Type" in that
class to specify whether the storage is Session or Local.

Chris Holland [Team Elevate]

On 13/12/2011 19:10, Ron Levy wrote:
> Tim,
>
> We are missing the sessionStorage/localStorage variables in TWindow.
>
> They should be define of TStorage type that should look like (if I get the syntax correct)
>
> external TStorage = class
>    public
>      property length : integer; read;
>      procedure clear;
>      function key(n : integer) : String;
>      function getItem(const key : String) : String;
>      procedure setItem(const key : String; const value : String);
>      procedure removeItem(const key : String);
> end; // TStorage
>

Ron,

<< We are missing the sessionStorage/localStorage variables in TWindow.

They should be define of TStorage type that should look like (if I get the
syntax correct) >>

Thanks, I'll check it out.  I'm happy to add anything to WebDOM that you
want, but I won't add it as being referenced in the framework unless it is
compatible with most browsers out there.

--
Tim Young
Elevate Software
www.elevatesoft.com

Thanks Tim,

Session Storage and Local storage are supported by most of the modern
browsers now.

Chris Holland
[Team Elevate]

On 13/12/2011 20:19, Tim Young [Elevate Software] wrote:
> Ron,
>
> << We are missing the sessionStorage/localStorage variables in TWindow.
>
> They should be define of TStorage type that should look like (if I get
> the syntax correct) >>
>
> Thanks, I'll check it out. I'm happy to add anything to WebDOM that you
> want, but I won't add it as being referenced in the framework unless it
> is compatible with most browsers out there.
>

<Can I second this request, also I think we will need "Type" in that
class to specify whether the storage is Session or Local.>

No need for that. It's the same interface. You know the difference by the property name you use.

Chris,

<< Session Storage and Local storage are supported by most of the modern
browsers now. >>

The basic plan of action was to do a solid HTML4 implementation, followed by
a code review for HTML5, adding the new bits to WebDOM.  That way, there's
some backward-compatibility in there and not as much pressure on customers
to enforce newer browser usage.

--
Tim Young
Elevate Software
www.elevatesoft.com

<The basic plan of action was to do a solid HTML4 implementation, followed by
a code review for HTML5, adding the new bits to WebDOM.  That way, there's
some backward-compatibility in there and not as much pressure on customers
to enforce newer browser usage.>

There is no enforcement of users to use the new functionality.

The correct way to do it is to do something like what modernizr (http://www.modernizr.com/) - does - it allows you to do feature detection and write your code to access these features if possible - or adds them.

HTML5 is the present and the future - (and just about any browser on any platform supports localStorage and sessionStorage nowadays) - so not having this functionality for backward compatibility is very limiting. It's a bit like having to Endure no-unicode in Delphi up to 2009...

Ron

> It's a bit like having to Endure no-unicode in Delphi up to 2009...

Some of us still don't have it and still don't want it

D2006 forever <vbg>

Roy

Hi Tim,

<The basic plan of action was to do a solid HTML4 implementation, followed by
a code review for HTML5, adding the new bits to WebDOM.  That way, there's
some backward-compatibility in there and not as much pressure on customers
to enforce newer browser usage.>

I think this is a good approach.

Ron,

<< There is no enforcement of users to use the new functionality.

The correct way to do it is to do something like what modernizr
(http://www.modernizr.com/) - does - it allows you to do feature detection
and write your code to access these features if possible - or adds them.

HTML5 is the present and the future - (and just about any browser on any
platform supports localStorage and sessionStorage nowadays) - so not having
this functionality for backward compatibility is very limiting. It's a bit
like having to Endure no-unicode in Delphi up to 2009... >>

I get it, I really do. It still doesn't change the fact that there are still
browsers running around in the wild that don't support the newer standards.
None of it affects how the base architecture of EWB works, and most of it
could be added in a very short period of time.

--
Tim Young
Elevate Software
www.elevatesoft.com