kev
<snip>
> - the compiler keeps it in memory from the last include call.
It's cos all CSP is compiled with [no procedureblock]
have to go back to the good ol M new command
new param
set param=%request.Get("param")
>
>
>I have now started ( forcing ) to include page with ALL parameters
>declared whether there is a default or not
Actually how are you passing the parameters
you should do it
<csp:include page="somepage.csp?p1=1&p2=2...." />
or is there some other way?
ahha - I now see
the csp:include with parameters sets the tings in the %request object
and they stay there both between calls and in fact for the whole
duration of page delivery
this is one thing I do not like about csp:include
so how about a couple of work arounds
in the csp page have #(##class(someclass).somemethod(p1,p2,p3...))#
and somemethod returns a string that is the JS - will work if <32k
length
>
>and that reminds me, I must log that one.
>
>
>one last thing, I had about 150 pages to change because the .INC no
get hold of DW and just do a search and replace site wide !
>longer works, (and that in my eyes is a bug) -
Weeell I think the bug was in earlier versions - the gatway did
anyting other than csp/cls
but csp:include is a directive to the class compiler - I suspect that
this was considered a bug(?) and corrected(?)
or at least inconsistent with the gateway
> if ISC change the way it
>works, then declare it in the release notes ! ! !
agree 110%
>All of my includes
>contained NOTHING but javascript, so there was no interpretation to be
>don, but it still did NOT display the contents.
Out if interest why do an include just for JS - you can use
<script src="scripts/xis.js" language="javascript" />
and get IIS/apache to server the thing
also cuts down on bandwidth as the browser will cache it
Peter
>
>
>kev
