In need of CSR rule advice

[Paul Hardy]

I was wondering if anyone can point me to a good solution for this:

I have a CSR rule for a custom tag that puts a javascript object on a page.
It's set up so I can place multiple tags on the same page each producing a
unique jscript object. However I need to supply a master css link for all
objects , along with a css link for each object. I have no problem with a
css link for each object as it's named the same as the specific object. I
place the css link in the head by using the <CSR:section name=head>.

My question is:

How can I place the Master css link which defines master properties for all
the objects ONLY once. Is there a way to test (during compile) if the link
or string was already written to the head? That way, the custom tag is
maintenance free and I can just place the tag as many times as I need on the
page without manually coding the css links.

Should I simpy declare a variable...something like cssOn and test for it
like $D(cssOn) .. or is there a better way?

Any help is appreciated...

Paul H

[Marvin Tener]

Your idea of declaring a variable is just fine.

To be a little cleaner there is defined during CSP page compilation a
variable %compiler (ref to %CSP.CompilerContext) that can be used to store
name/value pairs like
if '%compiler.Get("cssOn") {
set %compiler.Set("cssOn",1)

Marvin

"Paul Hardy" <pha...@surefiresys.com> wrote in message
news:40098...@info2.kinich.com...

[Paul Hardy]

Marvin,

Thanks for the reply. I will try your suggestion. I like the cleaner
"approach" ;)

Paul

"Marvin Tener" <te...@intersys.com> wrote in message

[Gertjan Klein]

"Marvin Tener" <te...@intersys.com> wrote:

>To be a little cleaner there is defined during CSP page compilation a
>variable %compiler (ref to %CSP.CompilerContext) that can be used to store
>name/value pairs like
> if '%compiler.Get("cssOn") {
> set %compiler.Set("cssOn",1)

The %CSP.CompilerContext class' documentation states:

"This class is used internally by Caché. You should not make direct
use of it within your applications. There is no guarantee made about
either the behavior or future operation of this class."

Has this changed? Even if it has, doesn't the CSP compiler *also* use
this object? An if so, how do we prevent name clashes (i.e., we use a
name that in the future ISC also decides to use)? Is there a range
reserved for users, e.g. everything starting with "z" or "Z"? Or will
ISC guarantee to only use names starting with "%" (as seems the case
now)?

Gertjan.

--
Gertjan Klein

[Paul Hardy]

I have another problem i can't seem to figure out.

How do you go about adding the OnPreHTTP method within the CSR:Rule
properly? I have tried placing the method within the section=HEAD, Outside
the section tags, tried "runat=server", "runat=compiler". I also tried
csr:section name="OnPreHTTP".

I notice that I can get the ClassMethod OnPreHTTP to show in the compilation
of the Rule Class, but when the tag is placed on a csp page, the compilation
of the page never contiains the method! The same goes for any on-page
methods! Any other code is fine. Does anyone know what I'm doing wrong?
I'm puzzled. Thanks in advance..

Paul


"Marvin Tener" <te...@intersys.com> wrote in message

[Peter Cooper]

Paul

Yikes !!
why do you need to do this??

If you really want to study Object.csr in <cachesys>\dev\csp\rules

you will see things like
Set code = lots of COS commands

Do AddMethod^%apiCDL(handle,JSmethodname)
Do SetMethod^%apiCDL(handle,JSmethodname,$$$cMETHlanguage,"cache")
Do

SetMethod^%apiCDL(handle,JSmethodname,$$$cMETHcodemode,$$$cMETHCODEMODECODE)
Do SetMethod^%apiCDL(handle,JSmethodname,$$$cMETHimplementation,.code)
Do SetMethod^%apiCDL(handle,JSmethodname,$$$cMETHreturntype,"")
Do SetMethod^%apiCDL(handle,JSmethodname,$$$cMETHclassmethod,1)
Do SetMethod^%apiCDL(handle,JSmethodname,$$$cMETHdescription,"Called
to render JavaScript code that is required for form
<var>"_%form_"</var>.")


csr:section will not work - it creates a method "OnPage"<sectionname>

What I have done in the past is to create a master class with a n
OnPreHTTP and then inherit this

but this will not work if you need to change the code in OnPreHTTP

again comes back to what do you want to achieve

Peter

[Paul Hardy]

Yea Pete,

Yikes is right! I really am just doing this for testing, I was just
confused by the logic of how the class methods were getting compiled and
really was looking for the answert to better understand it. The OnPreHTTP
method I will use is will be inherited in my final code like you mentioned.
I was just curious why it compiled like it did. There are a few variables
based on %request I was having problems with, that I need in the head of
the csp page.. I was purely looking to define some there for testing. I
suppose I'll just change some code around to overcome this.. Thanks for
pointing me to the info to study. I appreciate it.

Paul

"Peter Cooper" <p...@xisltd.demon.co.uk> wrote in message
news:bpjl00prvtu8jtvjs...@4ax.com...

[Peter Cooper]

Paul

<snip />

> that I need in the head of the csp page..

Watch out for the logic here
no matter where the OnPreHTTP method is placed in the text of the
source file it gets called at a particular place -

it can be at the top, middle,bottom of the source
but it always gets compiled to be called in the same place

The is true of all the standard callbacks

so if you set a var in the OnPreHTTP it is available throught the page
eg

<html>
<head>
<title> the time is #(theTime)#</title>
</head>
<body>
the body
</body>

<csp:method name="OnPreHTTP" return="%Boolean">
set theTime=$zdt($h,3)
</csp:method>

</html>

there is no undef when the title gets rendered

Peter

[Peter Cooper]

Gertjan

Very good questions re ISC use if vars - Someone (I think George
James) had a go about this a while ago

The issue is quite extensive
SQL code
Class Compiler Stuff
and now CSP Compiler stuff

It's even more important that dev tightens up the new'ing of vars -
there are still many places that leave vars hanging around or
trampling on your own vars

As for the docs - I guess I must trust Marvin's suggestion - he is the
CSP lead after all - but it does need to be followed thru to the docs

Peter


On Sun, 18 Jan 2004 11:52:26 +0100, Gertjan Klein <gkl...@xs4all.nl>
wrote:

[Bill McCormick]

I find it much easier to implement the OnPreHttp method via a super
class used by the csp application. You should still be able to scan
variables and trigger different behaviors - even calling generated methods.

--
Bill McCormick
Web/Objects Support Manager
InterSystems Corporation
bmc...@intersys.com

[Marvin Tener]

Some parts of %CompilerContext should remain internal. I will document that
%compiler.Get and %compiler.Set are for application use. All names used in
%compiler.Get/Set by ISC begin with csp or %.

Marvin

"Peter Cooper" <p...@xisltd.demon.co.uk> wrote in message

news:p93m005r0pmgijpu4...@4ax.com...

[Paul Hardy]

Yes I agree Bill and thats what I do for my application. The code I'm
working on is for a componant I have developed for my app, which I'd like to
distribute to the Cache community when I get all the bugs out. So I was
trying to define variables independantly of my app or better understand how
to keep it separate. I have overcome the whole problem now and it's looking
good!

I have created a DHMTL scrollable, pageable datagrid which directly binds to
Cache resultsets without page refreshes. It has a ton of features along
with a slick GUI to configure everything...

I will post screenshots or demo links shortly...

Hopefully you guys will like what I have created and maybe some of you csp
developers will get good use out of it as I currently am.. I actualy could
use a few beta testers if anyone is interested(send me an email)..

Paul


"Bill McCormick" <bmc...@intersystems.com> wrote in message
news:400b5...@info2.kinich.com...

[Peter Cooper]

Paul

Sounds good....

just a comment
If you capture OnPreHTTP et al for your own use then you are going to
close off developers that use these features themselves (like me)

If you need to set vars up here then suggest you provide some sort of
call back or link into so people can do their own thing plus use yours
as transparently as possible

maybe document it like


"if you need to use my SuperWidget then you must
do ##class(SuperWidget),init()
in the OnPreHTTP"

Peter

[Paul Hardy]

In the configurator for the grid, you can specify any Super's PreHTTP Method
run before the grids! The Grid itself will sit in an dynamically created
iframe. Its source page requires PreHTTP to get some vars.. But like said
you can specify any Super Class who's PreHTTP you need to run before the
grids. Such as a security check or what not...

Paul

"Peter Cooper" <p...@xisltd.demon.co.uk> wrote in message

news:934o00d56mjfe0doh...@4ax.com...

[paul perrin]

Is such a procedural approach is required?

In a language that supports multiple inheritance, defining a class (or its
subclasses) in such a way that if a subclass inherits a superclass via more
than route, then still only one instance of the superclass exists for a
subclass instance is a basic requirement (and ISTR fully supported in COS).

I would expect this mechanism to be exploitable in the situation you
describe - if your page is a class and it has several properties (fields)
that inherit from a common superclass (that contains the javascript
validation code) then if defined correctly the page class should
instantiate(/render) only one instance of that superclass (and thus only one
instance of the javascript it contains).

Declarative vs Procedural programming again - "class render thyself".

Paul /)/+)

"Paul Hardy" <pha...@surefiresys.com> wrote in message
news:40098...@info2.kinich.com...

[Paul Hardy]

Its all taken care of now.. I did it a different way.. was just tryuig to
understand the logic.. thats all..

Thanks

"paul perrin" <pperr...@hotmail.com> wrote in message
news:400c7...@info2.kinich.com...