Perl array and ASP session variable

[Udo Schmitt]

Hi!

I am useing ASP with PERL and would like to write an array into a session
variable. In the Doku I read this should be possible, but I don´t know to
implement it.
This line:

$Session->{'MyVariable'} = @array;

writes the number of elements of the array into the session variable.

How does it work correkt?



Ciao

Udo

 

[Chris Johnson]

Hi!

I am useing ASP with PERL and would like to write an array into a session
variable. In the Doku I read this should be possible, but I don´t know to
implement it.
This line:

$Session->{'MyVariable'} = @array;

writes the number of elements of the array into the session variable.

How does it work correkt?

I think you're wanting a reference to an array. If that's the case, you
want:

$Session->{'MyVariable'} = \@array;

 

[Matt Garrish]

I think you're wanting a reference to an array. If that's the case, you
want:

$Session->{'MyVariable'} = \@array;

Not if it's the MS flavour; you can't store a reference to anything inside a
session variable (which may not be true for Apache::ASP, but I've only used
the former).

Matt

 

[Chris Johnson]

Not if it's the MS flavour; you can't store a reference to anything inside a
session variable (which may not be true for Apache::ASP, but I've only used
the former).

Well then I've no idea. As far as I know that's the only way to store
an array in a scalar.

 

[Udo Schmitt]

Well then I've no idea. As far as I know that's the only way to store

an array in a scalar.

Session is an object - maybe it's possible to store the array into the
object (?).

U.

 

[Matt Garrish]

Session is an object - maybe it's possible to store the array into the
object (?).

$Session is a perl object, but the actual session is an ASP implementation
(which only takes scalar values, not references). You can't persist a perl
data structure from one call to the next without resorting to your own
session maintenance. You might consider:

$Session->{'myarray'} = join('|', @data);

and then on subsequent postbacks:

my @data = split(/\|/, $Session->{'myarray'});

Matt

 

[Aaron Baugher]

Well then I've no idea. As far as I know that's the only way to
store an array in a scalar.

Storable.pm will let you store a complex data structure in a scalar.
Maybe then ASP would let you save that scalar, which could then be
retrieved and converted back into the original structure (array, in
this case) with Storable.

 

[Matt Garrish]

$Session is a perl object, but the actual session is an ASP
implementation (which only takes scalar values, not
references). You can't persist a perl data structure from one
call to the next without resorting to your own session
maintenance.

I seem to remember this being true myself in the IIS4 days, and
I expected it to remain true.

However, I tested it, using the following ASP pages on an IIS6
server:

### test1.asp
<%@ language=PerlScript %>
<% $Session->{myarray} = [qw( one two three )]; %>
<p>array saved. <a href="test2.asp">fetch</a>.</p>

### test2.asp
<%@ language=PerlScript %>
<%= "<p>retrieved: @{ $Session->{myarray} }.</p>" %>

The output of test2.asp is: "retrieved: one two three"

So, dunno if this is a change in IIS, or in ActiveState's
PerlScript, or just my faulty memory. But it appears you can,
indeed, assign a perl array ref to an ASP session variable and
successfully dereference it. I don't have time to test hashrefs
as well, but I would expect them to work the same.

It appears you can store arrays, but not hashes (at least not without
flattening), which might have been what bit me in the butt and made me
assume refs were out. Thanks for the update!

That said, I'm not a fan of loading up the session variable with data. As
I'm sure you know, the two big problems are: 1) maintaing state when more
than one server is involved; and 2) the lack of scalability if you cram each
session full of data.

Matt

 

[Robin]

Hi!

Is there a better solution to save data over a session? I am useing
forms and two asp scripts which will be called alternatly - and this
two scripts are needing the same data.

Ciao

Udo

 

[Karlheinz Weindl]

Well then I've no idea. As far as I know that's the only
way to store an array in a scalar.

Session is an object - maybe it's possible to store the
array into the object (?).

$Session is a perl object, but the actual session is an ASP
implementation (which only takes scalar values, not
references). You can't persist a perl data structure from one
call to the next without resorting to your own session
maintenance.

I seem to remember this being true myself in the IIS4 days, and
I expected it to remain true.

However, I tested it, using the following ASP pages on an IIS6
server:

### test1.asp
<%@ language=PerlScript %>
<% $Session->{myarray} = [qw( one two three )]; %>
<p>array saved. <a href="test2.asp">fetch</a>.</p>

### test2.asp
<%@ language=PerlScript %>
<%= "<p>retrieved: @{ $Session->{myarray} }.</p>" %>

The output of test2.asp is: "retrieved: one two three"

So, dunno if this is a change in IIS, or in ActiveState's
PerlScript, or just my faulty memory. But it appears you can,
indeed, assign a perl array ref to an ASP session variable and
successfully dereference it. I don't have time to test hashrefs
as well, but I would expect them to work the same.

It appears you can store arrays, but not hashes (at least not without
flattening), which might have been what bit me in the butt and made me
assume refs were out. Thanks for the update!

Yes, it's true that you can only store arrays (aside of scalars of
course) into session variables. Same applies to application variables
btw. No hashes, no Perl references!

Also true that you can, in fact _must_ , do this by passing an array
reference.

Reason for that being a weird ASP internal mechanism that takes your
reference and flattens your array into a scalar session variable
(variant array in VB speak), if it does identify as an array. It never
stores references, not even ones to (native) ASP objects.

So, since ASP does the serialization for you:
If one flattens a hash into an anonymous array who's reference you pass,
you can easily store and retrieve hashes as well (keeping in mind that
ASP will always return an array).

You can even (courtously) 'de-reference' an individual array value
directly from the session variable by using Perl's arrow notation, but
you are highly discouraged trying to modify them that way e.g.

$Session->{myarray}->[$someindex] = $somevalue;

(I haven't tried it but believe them in not letting you get that far to
fiddle into a flattened array.)

Karlheinz

 

[Matt Garrish]

Is there a better solution to save data over a session? I am useing
forms and two asp scripts which will be called alternatly - and this
two scripts are needing the same data.

Better solution to what? Please quote some context.

I assume you mean to storing in $Session? If the data is not critical to
anything (i.e., it doesn't matter if it gets tampered with), there's no
reason not to just write it out to hidden input fields. Just don't rely on
the data staying valid between requests and always double-check that it is
valid. The benefit is that you don't have to store the information on the
server, which means less in memory.

It's also nice to think that sites should work perfectly for you if you turn
off cookies, but that's a pipe dream (few do). If you want to require your
more anal users to turn them back on, you can use that method, but again
it's open to tampering.

On the server side you could store the information to a database rather than
keep it in memory. The overhead is slightly higher than using a session but
you can have one database sitting on a separate server on the backend that
all your servers can access.

There's also no reason not to use sessions. It can be quite handy for
keeping people from tampering with information you don't want tampered with.
You can set the id to identify the person with in your database and never
send it to the user, for example. I think the general rule of thumb is that
session should only be used for data that really needs to persist for the
duration of the user's visit (i.e., don't store form data in it that's just
going to a database at some point or that you feel like collecting in
stages).

None of this has much of anything to do with Perl in particular, though, so
if you want more information I would suggest posting your question to
comp.infosystems.www.authoring.cgi.

Matt