WEBLINGO Break Point

In Builder one was able to load the weblingo and put a break so the code would spit out variables.In CS105IDE I am doing it the hard way as in put a :schedule.debugbreak() and hope to remember to take it off when I am done.

I found a thread where Hugh says he has been doing just that

https://knowledge.opentext.com/knowledge/cs.dll?func=ll&objId=49466444&objAction=viewincontainer

Considering that thread is almost 6 months I would like to request

An easier way to debug.I tried opening up the file in eclipse IDE the entire path to the html folder in my module and it would not break.
The way to treat code not just as ospace.Currently we have a source control system where we back up our ospace and the .os file we manually end up copying the INI and html, support and any properties files we use.
When you import an existing module the CSIDE does ask you whether you want html,support etc but if you edit that code in CSIDE it is not thrown to the server location.I also could be doing something wrong because I know when I change something in an .os file it knows how to build and put the changes to the server so going by that same token wouldnt it know how to copy the html as well?

How many non partner companies out there like ours have started using CSIDE for oscript development ? Perhaps I am just old and pampered by my navigation of the old ide but certainly I have been struggling.Some times it is eclipse throwing huge errors,bad code will get compiled and get thrown to the server so now it wont start up those kinds. Do not take my posting as negative I love OSCRIPT and I just hope later iterations have products that we can use a little more easily...

Find more posts tagged with

Comments

Mark_Sherry

I can think of two possible things you're possibly doing:

Generate objects, scripts etc. on the fly at run-time. The objects are ephemeral, and are regenerated each time CS is run.
Generate objects, scripts etc. in an unlocked OLL according to a template, as a way to avoid lots of scut work in Builder.

The first approach still works in 10.5.0. The OS built-ins still work as they always have, and there's nothing stopping you from generating things on the fly.

The second approach doesn't work, but is also no longer necessary. You can just create OS files programatically using your favourite programming language (even OScript) using regular file IO. I've got a half-baked template engine implementation using Java's StringTemplate library which one day might make its way into CSIDE. It took me an afternoon to write, and can generate multiple objects in multiple packages based off of a common set of inputs and a template defined in an XML file.

Modifying text in an existing object is trickier. Obviously if you know exactly what you're looking for you can do appropriate search/replace, and forward-thinking when designing templates can make it easier by inserting deliberate unique strrings to search for (e.g. "/* Add new widget entries here */"). I'm hoping we can provide better tools in the future.

Chris Meyer

Hi Mark,

I'm doing a bit of both. Indeed, the generation of scripts at runtime continues to work with 10.5. It's the later point of generating code directly on the OLL that I'm now concerned with.

I'd be curious to see that template engine implementation and how you use it to generate code. But as I wrote earlier in the thread, I continue to work with Builder for the simple sake that I need to support CS10 as well as CS10.5. I'm trying to prepare myself for the future when this is no longer possible. Eventually I'll need to find other ways of doing this.

Thanks for your feedback,
Chris

Chris Meyer

Hi Mark,

Quoted Mark Sherry on 09/01/2014 08:27 PM:

I had to think about this a little longer. The difficulty in my scenario is that my inputs are the result of various OScript functions, subsystems, and features and functions on the subsystem items. It's dynamic and flexible, but requires OScript to be executed to generate the code.

That said, perhaps there is some type of hybrid solution where I run the code generation in the Module Explorer view and it writes the .os files in the source directory (I think you were suggesting this using standard file IO?). Otherwise, I could do it in the Module Explorer view just as I've been doing it with Builder up to now. Hopefully this view and the ability to run scripts in the IDE never goes away...

Thanks
Chris

Chris Meyer

I'm working more with the OScript Explorer view and realized my question is more general.

In Builder we often had 0Setup()-type scripts for setting feature values. For example, the 0Setup script in WebNodeCMD looks something like this:

//  Set required permissions mask..fPerms = $PModify + $PDelete

In WebModule we set the dependencies and version like this...

For the dependencies:

function Void SetDependencies()    .fDependencies = { \        { 'kernel', 10, 0 }, \        { 'webnode', 10, 0 } \        }end

For the version:

function Void SetVersion()    .fVersion = { "10", "0", "r", "0" }end

Is there a functional equivalent in the OScript Explorer view in CSIDE? If not, then what is the correct approach?

Thanks

Darcy_Casselman

Quoted Chris Meyer on 10/31/2014 11:32 AM:

I'm working more with the OScript Explorer view and realized my question is more general.

In Builder we often had 0Setup()-type scripts for setting feature values.

Is there a functional equivalent in the OScript Explorer view in CSIDE? If not, then what is the correct approach?

Short answer: no. You can no longer modify your source code with OScript from within CSIDE. In most cases, though, this is no longer necessary. We have allowed assoc literals and long strings that eliminate the need for maybe 90% of 0 Setups. So, for example,

Quoted Chris Meyer on 10/31/2014 11:32 AM:

For the dependencies:

function Void SetDependencies()    .fDependencies = { \        { 'kernel', 10, 0 }, \        { 'webnode', 10, 0 } \        }end

Becomes

        public List fDependencies = {        { 'kernel', 10, 0 },        { 'webnode', 10, 0 },    }

... as a feature declaration and you can delete SetDependencies(). Likewise...

Quoted Chris Meyer on 10/31/2014 11:32 AM:

For the version:

function Void SetVersion()    .fVersion = { "10", "0", "r", "0" }end

Becomes

    public List fVersion = { "10", "0", "r", "0" }

Note those feature declarations should already be in your source code as of import so you can just delete the old Set scripts.

[quote]

//  Set required permissions mask..fPerms = $PModify + $PDelete

In WebModule we set the dependencies and version like this...

[/quote]

Feature declarations are somewhat limited in that you cannot have non-static expressions or any run-time values. So globals are not allowed. We don't yet have build-time constants in OScript, unfortunately. In the meantime, we recommend putting the magic numbers in your feature declaration and adding a comment to remind you where they came from. So the above would be...

    public Integer fPerms = 65536 + 8 //$PModify + $PDelete

(And you should probably be using the | operator rather than +).

Chris Meyer

Hi Darcy,

Thanks for your answer. I suspected this feature or something equivalent was no longer available (at least in the OScript explorer view). Unfortunately, I'm still working in that 10% space where I need this. If you're interested to know why... and perhaps you see another way to do this?

I'm doing a lot of OOP style programming in OScript using the Frame data type. One of my requirements is to know if an instance is of a particular class (i.e., like the instanceof operator in Java). This doesn't exist in OScript, so I wrote the class hierarchy (as a list) to a feature, which can be tested as follows:

function Boolean isInstanceOf( String className )    return ( className in .fClassHierarchy )end

The fClassHierarchy is generated by something similar to the 0Setup scripts we've been discussing. This works well, but I'm now stuck on supporting it on CSIDE 10.5. I'd rather not hardcode it; it's meant to be auto generated.

I suppose I could rewrite the isInstanceOf() method to traverse up the hierarchy (using OS.Parent()) and return true if it comes across className. This seems inefficient to me. Alternatively, I could somehow populate fClassHierarchy at system start. Any suggestions?

public Integer fPerms = 65536 + 8 //$PModify + $PDelete (And you should probably be using the | operator rather than +).

Of course... but I think I copied that from one of the default WebNodeCMDs.

Thanks!
Chris

Mark_Sherry

Or you could do a lazy recursive initialization (warning: completely untested code):

public function List getClassHierarchy()	if type( this ) == FrameType		if !(.fClassName in .fClassHierarchy)			// This init code will only run if the first parent with an .fClassName feature hasn't initialized yet.			List hierarchy			Object parent			for parent in Frame.Parents( this )				if isFeature( parent, 'getClassHierarchy' )					hierarchy = { @hierarchy, parent.getClassHierarchy() }				end			end				.fClassHierarchy = hierarchy		end		return .fClassHierarchy	else		if IsFeature( this, 'fClassName' ) && IsFeature( this, 'fClassHierarchy' )			if !(.fClassName in .fClassHierarchy)				if IsFeature( .OSParent, 'getClassHierarchy' )					.fClassHierarchy = { @.OSParent.getClassHierarchy(), .fClassName }				else					.fClassHierarchy = { .fClassName }				end			end			return .fClassHierarchy		else			return {}		end	endendpublic function Boolean isInstanceOf( String className )	if !(.fClassName in .fClassHierarchy)		.getClassHierarchy()	end	return className in .fClassHierarchyend

Most of the time, you'll incur the extra expense of two feature look-ups, and a call to 'in'. Otherwise, it will go to compute its own ancestry, caching and making use of cached values along the way so that every object in the hiearchy only gets initialized once.

A lot of the code could be simplified with the use of a fInitialized feature which is explicitly set to false on every object we want to add to the hiearchy. I assume that frames are considered to be instances, and objects classes, so (a) you never have a frame with another frame as a parent, (b) frames never have class names that contribute to the hiearchy, and (c) we have single inheritance. Multiple inheritance makes things messier, since you either need to have an fInitialized slot on each frame (set to false), or explicitly check the fInitialized status of each parent on each call to isInstanceOf.

Or, in the long run, write something that parses the OS files, and injects a feature that lists the ancestors of each object. Essentially, it would be like the current 0Setup, but manipulating code rather than the OScript objects directly, and probably written in something other than OScript.