Re: db:execute context

--===============0934642597==
Content-Type: multipart/alternative; boundary="0-801739904-1163606765=:87850"
Content-Transfer-Encoding: 7bit

--0-801739904-1163606765=:87850
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

Thanks for suggestions,

 I completely understand your design decision, but from the other hand=20
 it is also usefull to have in db:execute tag an access to parameters and=
 variables which are in function context like you have done eg. in for-ea=
ch tag where you also create new variable but still has access to others =
variables.

Sometimes function variables I would like to use inside db:execute are qu=
ite complex documents , which I wouldn't like/can't pass through SQL quer=
y.

Anyway I found it quite annoying that I have to do such strange things to=
 pass parameters to db:execute tag. And we have to do this quite frequent=
ly.

At the moment you use two different notation to access db variables {$xx}=
 and function variables <o:_eval select=3D"$xxx">, but internally you sto=
re both variables in the same place RuntimeContext.variables (as a result=
 you can access db variables also using <o:_eval select=3D"$xxx"> notatio=
n).  Maybe in db:execute you could create seperate container/variable jus=
t for db variables and {$xx} tag would access variables only in such cont=
ainer. You could add this container to RuntimeContext.variables as a sing=
le variable along other function variables  and remove it when db:execute=
 finishes  (exactly as for o-foreach).

I guess that in such case it would be not possible anymore to access db v=
ariables using <o:_eval select=3D"$XXX">, but as I understand suggested n=
otation is {$xxx} anyway. =20

As I think about it longer maybe it would be even better solution if we a=
ccess db variables like <o:_eval select=3D"$db/xxxxx"> where $db would be=
 the name of variable defined in db:execute tag (like in o:foreach tag).=20
In such case we could access db variables even in nested queries even if =
they return columns with the same name.


Tomasz




[email protected] wrote: Hi Tomasz,

I'll try give a quick answer to this -

With the o:XML db extensions, all local and type variables (ie all variab=
les!) are out-of-scope within the result template of a SQL query. Only th=
e db result set values are available, as variables. This is by design, in=
 order to avoid conflicts. Otherwise local variables and type variables m=
ay be accidentally reassigned, which could get very confusing. If you thi=
nk this is not the way it should be, pls advice as to your preferred solu=
tion!

The workaround you've found is not a bad one, though you can make it a li=
ttle easier for yourself using attribute value substitution:

   =20
       =20
       =20
           =20
           =20
                NOW I CAN ACCESS here parameter param1  and variable var1=
.
           =20
       =20
   =20

remember that string values have to be quoted, eg with the db:quote() fun=
ction:

         =20
               NOW I CAN ACCESS here parameter param1
         =20


hope this helps!

 __________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around=20
http://mail.yahoo.com=20
--0-801739904-1163606765=:87850
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

Thanks for suggestions,<br><br>&nbsp;I completely understand your design =
decision, but from the other hand <br>&nbsp;it is also usefull to have in=
 db:execute tag an access to parameters and variables which are in functi=
on context like you have done eg. in for-each tag where you also create n=
ew variable but still has access to others variables.<br><br>Sometimes fu=
nction variables I would like to use inside db:execute are quite complex =
documents , which I wouldn't like/can't pass through SQL query.<br><br>An=
yway I found it quite annoying that I have to do such strange things to p=
ass parameters to db:execute tag. And we have to do this quite frequently=
.<br><br>At the moment you use two different notation to access db variab=
les {$xx} and function variables &lt;o:_eval select=3D"$xxx"&gt;, but int=
ernally you store both variables in the same place RuntimeContext.variabl=
es (as a result you can access db variables also using &lt;o:_eval select=
=3D"$xxx"&gt; notation).&nbsp; Maybe in
 db:execute you could create seperate container/variable just for db vari=
ables and {$xx} tag would access variables only in such container. You co=
uld add this container to RuntimeContext.variables as a single variable a=
long other function variables&nbsp; and remove it when db:execute finishe=
s&nbsp; (exactly as for o-foreach).<br><br>I guess that in such case it w=
ould be not possible anymore to access db variables using &lt;o:_eval sel=
ect=3D"$XXX"&gt;, but as I understand suggested notation is {$xxx} anyway=
.&nbsp; <br><br>As I think about it longer maybe it would be even better =
solution if we access db variables like &lt;o:_eval select=3D"$db/xxxxx"&=
gt; where $db would be the name of variable defined in db:execute tag (li=
ke in o:foreach tag). <br>In such case we could access db variables even =
in nested queries even if they return columns with the same name.<br><br>=
<br>Tomasz<br><br><br><br><br><b><i>[email protected]</i></b> wrote: H=
i Tomasz,<br><br>I'll try give a quick
 answer to this -<br><br>With the o:XML db extensions, all local and type=
 variables (ie all variables!) are out-of-scope within the result templat=
e of a SQL query. Only the db result set values are available, as variabl=
es. This is by design, in order to avoid conflicts. Otherwise local varia=
bles and type variables may be accidentally reassigned, which could get v=
ery confusing. If you think this is not the way it should be, pls advice =
as to your preferred solution!<br><br>The workaround you've found is not =
a bad one, though you can make it a little easier for yourself using attr=
ibute value substitution:<br><br>    <br>        <br>        <br>        =
    <br>            <br>                NOW I CAN ACCESS here parameter p=
aram1  and variable var1.<br>            <br>        <br>    <br><br>reme=
mber that string values have to be quoted, eg with the db:quote() functio=
n:<br><br>          <br>               NOW I CAN ACCESS here parameter pa=
ram1<br>          <br><br><br>hope this
 helps!<br><p>&#32;__________________________________________________<br>=
Do You Yahoo!?<br>Tired of spam?  Yahoo! Mail has the best spam protectio=
n around <br>http://mail.yahoo.com=20
--0-801739904-1163606765=:87850--

--===============0934642597==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
o-xml mailing list
o-xml-zRfLyl9bSvv/[email protected]
http://lists.pingdynasty.com/mailman/listinfo/o-xml

--===============0934642597==--