[mru] passing globals back to itself

I keep running into this and still haven't found a solution. To get
around it, I usually just export the data and import it again later
when I need it. I don't think it's elegant and I think should be
unnecessary, I'll do it if i have to, but here is where I always get
tripped up: My complete apps works perfectly in Uncompiled. As soon as
I compile it...there is no joy.

This app has forms and <a href... tags to re run itself via
s.documenturl.

Example:

<a href="{ s.documenturl $ 'action=edit_rec'}">

or

<form method="post" action="{ s.documenturl $ 'action=edit_rec' }">

There are many other options that get passed with the URL, no need to
list them here.

Any var passed through this method works but any global vars in the
forms get clobbered.

Is there something I need to do environment wise? Maybe using the
following command, etc?

<MIVA STANDARDOUTPUTLEVEL =

What happens to the vars when the script is exited/re-entered?
Obviously, uncompiled, the env retains in memory, compiled, they're
for lack of better terminology "forgotten," at least in my scripts.

TIA
--
Best regards,
IDS mailto:[email protected]

[mru] passing globals back to itself



Hi IDS,

I don't really understand what you mean, but I can tell you one thing =
for
sure: Compiled or uncompiled, variables should NEVER stay in memory (at
least on Unix nothing should stay in memory once the script is exited).
Common ways to pass them with the POST method are via MvHIDE (or regular
html hidden fields), or a bit more secure stored in a database or =
textfile.=20

One potential issue that you might experience is that newer versions of
Empresa handle form variables as arrays, while old uncompiled scripts =
passed
them directly (I think prior to Empresa/Mia v3.92). This however only
becomes an issue if you have several variables with the same name, or if =
you
use special characters in the formname (see Adam's post about it).

But again, I am not entirely sure if I understood you right...=20

Markus



-----Original Message-----
From: [email protected] [mailto:[email protected]] On =
Behalf
Of IDS
Sent: Donnerstag, 31. M=E4rz 2005 22:23
To: [email protected]
Subject: [meu] [mru] passing globals back to itself

I keep running into this and still haven't found a solution. To get =
around
it, I usually just export the data and import it again later when I need =
it.
I don't think it's elegant and I think should be unnecessary, I'll do it =
if
i have to, but here is where I always get tripped up: My complete apps =
works
perfectly in Uncompiled. As soon as I compile it...there is no joy.

This app has forms and <a href... tags to re run itself via =
s.documenturl.

Example:


<a href=3D"{ s.documenturl $ 'action=3Dedit_rec'}">

or

<form method=3D"post" action=3D"{ s.documenturl $ 'action=3Dedit_rec' =
}">

There are many other options that get passed with the URL, no need to =
list
them here.

Any var passed through this method works but any global vars in the =
forms
get clobbered.

Is there something I need to do environment wise? Maybe using the =
following
command, etc?

<MIVA STANDARDOUTPUTLEVEL =3D

What happens to the vars when the script is exited/re-entered?
Obviously, uncompiled, the env retains in memory, compiled, they're for =
lack
of better terminology "forgotten," at least in my scripts.

TIA
--
Best regards,
IDS mailto:[email protected]

passing globals back to itself



Hello MvMarkus,

You're understanding. Thanks. I'm going to try MvHide.

This script (app) uncompiled worked as expected on (Li)Unix server.
Maybe the expectations are wrong?

So, the same server, uncompiled as compiled, the only difference,
version of Empressa and compiling.

If MvHide doesn't help, I look back at that thread...all var names are
different.

extended scope question: In the old days I always had success passing vars,
hidden or otherwise, from screen to screen, like OINF thru OPAY in MM.
I had to change that in 4.12 when I had to utilize system modules to
retrieve data. That was MM. Now this app was developed under 4.12,
where MM wouldn't take adv of that technique, but yet my app, and not
the first one, I've written quite a few since,( and few compiled ). So
Empressa VM was or wasn't the first parser to clamp down on that
method?

Thanks,

Scott
IDS

Thursday, March 31, 2005, 12:37:00 PM, you wrote:

M> Hi IDS,

M> I don't really understand what you mean, but I can tell you one thing for
M> sure: Compiled or uncompiled, variables should NEVER stay in memory (at
M> least on Unix nothing should stay in memory once the script is exited).
M> Common ways to pass them with the POST method are via MvHIDE (or regular
M> html hidden fields), or a bit more secure stored in a database or textfile.

M> One potential issue that you might experience is that newer versions of
M> Empresa handle form variables as arrays, while old uncompiled scripts passed
M> them directly (I think prior to Empresa/Mia v3.92). This however only
M> becomes an issue if you have several variables with the same name, or if you
M> use special characters in the formname (see Adam's post about it).

M> But again, I am not entirely sure if I understood you right...

M> Markus



M> -----Original Message-----
M> From: [email protected] [mailto:[email protected]] On Behalf
M> Of IDS
M> Sent: Donnerstag, 31. März 2005 22:23
M> To: [email protected]
M> Subject: [meu] [mru] passing globals back to itself

M> I keep running into this and still haven't found a solution. To get around
M> it, I usually just export the data and import it again later when I need it.
M> I don't think it's elegant and I think should be unnecessary, I'll do it if
M> i have to, but here is where I always get tripped up: My complete apps works
M> perfectly in Uncompiled. As soon as I compile it...there is no joy.

M> This app has forms and <a href... tags to re run itself via s.documenturl.

M> Example:


M> <a href="{ s.documenturl $ 'action=edit_rec'}">

M> or

M> <form method="post" action="{ s.documenturl $ 'action=edit_rec' }">

M> There are many other options that get passed with the URL, no need to list
M> them here.

M> Any var passed through this method works but any global vars in the forms
M> get clobbered.

M> Is there something I need to do environment wise? Maybe using the following
M> command, etc?

M> <MIVA STANDARDOUTPUTLEVEL =

M> What happens to the vars when the script is exited/re-entered?
M> Obviously, uncompiled, the env retains in memory, compiled, they're for lack
M> of better terminology "forgotten," at least in my scripts.

M> TIA
M> --
M> Best regards,
M> IDS mailto:[email protected]

passing globals back to itself



Well, looks like MvHide isn't doing the trick. Unless I'm not using it
correctly. I've placed it just before the closing </form> tag. And,
only once with all the required vars I need. MvHide seems to be a
useless tag, unless I'm missing something.

Looks like I'm in it to use a temp db and track with session IDs?
Sound right? Any other ideas?

TIA

Scott
IDS

Thursday, March 31, 2005, 1:24:06 PM, you wrote:

I> Hello MvMarkus,

I> You're understanding. Thanks. I'm going to try MvHide.

I> This script (app) uncompiled worked as expected on (Li)Unix server.
I> Maybe the expectations are wrong?

I> So, the same server, uncompiled as compiled, the only difference,
I> version of Empressa and compiling.

I> If MvHide doesn't help, I look back at that thread...all var names are
I> different.

I> extended scope question: In the old days I always had success passing vars,
I> hidden or otherwise, from screen to screen, like OINF thru OPAY in MM.
I> I had to change that in 4.12 when I had to utilize system modules to
I> retrieve data. That was MM. Now this app was developed under 4.12,
I> where MM wouldn't take adv of that technique, but yet my app, and not
I> the first one, I've written quite a few since,( and few compiled ). So
I> Empressa VM was or wasn't the first parser to clamp down on that
I> method?

I> Thanks,

I> Scott
I> IDS

I> Thursday, March 31, 2005, 12:37:00 PM, you wrote:

M>> Hi IDS,

M>> I don't really understand what you mean, but I can tell you one thing for
M>> sure: Compiled or uncompiled, variables should NEVER stay in memory (at
M>> least on Unix nothing should stay in memory once the script is exited).
M>> Common ways to pass them with the POST method are via MvHIDE (or regular
M>> html hidden fields), or a bit more secure stored in a database or textfile.

M>> One potential issue that you might experience is that newer versions of
M>> Empresa handle form variables as arrays, while old uncompiled scripts passed
M>> them directly (I think prior to Empresa/Mia v3.92). This however only
M>> becomes an issue if you have several variables with the same name, or if you
M>> use special characters in the formname (see Adam's post about it).

M>> But again, I am not entirely sure if I understood you right...

M>> Markus



M>> -----Original Message-----
M>> From: [email protected] [mailto:[email protected]] On Behalf
M>> Of IDS
M>> Sent: Donnerstag, 31. März 2005 22:23
M>> To: [email protected]
M>> Subject: [meu] [mru] passing globals back to itself

M>> I keep running into this and still haven't found a solution. To get around
M>> it, I usually just export the data and import it again later when I need it.
M>> I don't think it's elegant and I think should be unnecessary, I'll do it if
M>> i have to, but here is where I always get tripped up: My complete apps works
M>> perfectly in Uncompiled. As soon as I compile it...there is no joy.

M>> This app has forms and <a href... tags to re run itself via s.documenturl.

M>> Example:


M>> <a href="{ s.documenturl $ 'action=edit_rec'}">

M>> or

M>> <form method="post" action="{ s.documenturl $ 'action=edit_rec' }">

M>> There are many other options that get passed with the URL, no need to list
M>> them here.

M>> Any var passed through this method works but any global vars in the forms
M>> get clobbered.

M>> Is there something I need to do environment wise? Maybe using the following
M>> command, etc?

M>> <MIVA STANDARDOUTPUTLEVEL =

M>> What happens to the vars when the script is exited/re-entered?
M>> Obviously, uncompiled, the env retains in memory, compiled, they're for lack
M>> of better terminology "forgotten," at least in my scripts.

M>> TIA
M>> --
M>> Best regards,
M>> IDS mailto:[email protected]

[mru] passing globals back to itself



On Thu, 31 Mar 2005 12:23:00 -0800, IDS <[email protected]> gave utterance
to the following:

> I keep running into this and still haven't found a solution. To get
> around it, I usually just export the data and import it again later
> when I need it. I don't think it's elegant and I think should be
> unnecessary, I'll do it if i have to, but here is where I always get
> tripped up: My complete apps works perfectly in Uncompiled. As soon as
> I compile it...there is no joy.
>
> This app has forms and <a href... tags to re run itself via
> s.documenturl.
>
> Example:
>
> <a href="{ s.documenturl $ 'action=edit_rec'}">
>
> or
>
> <form method="post" action="{ s.documenturl $ 'action=edit_rec' }">

For a start, if you are using POST for a form, then it is far more elegant
to send all the data via POST rather than sending the action via GET.
therefore: <form method="post" action="{s.documenturl}">
<input type="hidden" name="action" value="edit_rec" />
or even
<form method="post" action="">
(I'm not sure if this is strictly legit but it works and avoids having the
? at the end of the resulting URL).


> There are many other options that get passed with the URL, no need to
> list them here.
>
> Any var passed through this method works but any global vars in the
> forms get clobbered.
>
> Is there something I need to do environment wise? Maybe using the
> following command, etc?
>
> <MIVA STANDARDOUTPUTLEVEL =
>
> What happens to the vars when the script is exited/re-entered?

Unless passed back as hidden form variables (or cookies), they are
destroyed. Miva, like http: is stateless, and each process terminates as
soon as it has finished outputting a page.

> Obviously, uncompiled, the env retains in memory
No, it doesn't.
The usual options are to explicitly write hidden form variables or to use
the <MvHIDE> shortcut.
Because uncompiled miva has no means to correct the xhtml-invalid output
of MvHIDE (upper-case INPUT and no terminator), I developed the following
library function:

<MvCOMMENT>
=============================================
14) hide(varlist)
This is an XHTML friendly replacement for MvHIDE
=============================================
</MvCOMMENT>
<MvFUNCTION NAME="hide" PARAMETERS="vars" STANDARDOUTPUTLEVEL="{g.thc}">

<MvASSIGN NAME="l.vars" VALUE = "{glosub(l.vars,' ','')}">
<MvASSIGN NAME="l.numvars" VALUE = "{len(l.vars) -
len(glosub(l.vars,',','')) + 1}">

<MvWHILE EXPR = "{l.i LT l.numvars}">
<MvASSIGN NAME="l.i" VALUE = "{l.i + 1}">
<MvASSIGN NAME="l.j" VALUE = "{gettoken(l.vars,',',l.i)}">
<MvIF EXPR="{'=' IN l.j}">
<MvASSIGN NAME="l.value" VALUE = "{gettoken(l.j,'=',2)}">
<MvIF EXPR="{'.' IN l.value AND miva_variable_value(l.value)}">
<MvASSIGN NAME="l.value" VALUE = "{miva_variable_value(l.value)}">
</MvIF>
<MvASSIGN NAME="l.j" VALUE = "{gettoken(l.j,'=',1)}">
<MvELSE>
<MvASSIGN NAME="l.value" VALUE = "{miva_variable_value(l.j)}">
</MvIF>
<MvASSIGN NAME="l.name" VALUE = "{glosub(glosub(l.j,'l.',''),'g.','')}">
<MvEVAL EXPR="{'<input type="hidden" name="' $ l.name $ '" value="'
$ l.value $ '" ' $ g.xmlterm $ '>'}">
</MvWHILE>

</MvFUNCTION>

A typical call to it might be <MvDO FILE="{g.util}" NAME="l.ok"
VALUE="{hide('g.sid,g.email,action=edit_rec,url=l. file')}"> - which will
result in four valid hidden form elements. (g.xml is defined as '/' during
page initialisation if I'm using xhtml)

Note the last two entries in the parameter string: I can assign a scalar
value directly rather than having to assign it to a global and then hide
it, and the last item puts the value of a local variable into the value
attribute.

--
Richard Grevers
Between two evils always pick the one you haven't tried