Running a workspace on a non-dev system?

[Stokes]

Is there anyway you can run a workspace on a non-development system?

What I need to do is find out a method version for a particular method that is in error on a clients site that does not have a development licence. What I have done is designed a workspace script as shown here:

Code: Select all

constants Class_Name = "Iterator"; Method_Name = "next"; vars crMethod : Method; crObject : Object; trMethods : MethodNDict; crType : Type; trObjectArray : ObjectArray; pbFound : Boolean; begin create trMethods transient; create trObjectArray transient; currentSchema.allClasses().copy(trObjectArray); foreach crObject in trObjectArray do if crObject.getName = Class_Name then crType := crObject.Type; crType.getMethods(trMethods); foreach crMethod in trMethods do if crMethod.name = Method_Name then write "Modified info for: [" & Class_Name & "::" & Method_Name & "]"; write crMethod.getPropertyValue("_modifiedBy").String & " " & crMethod.getPropertyValue(SchemaEntity::modifiedTimeStamp.name).String; pbFound := true; break; endif; endforeach; if pbFound then break; endif; endif; endforeach; if not pbFound then write "Class and/or method not found, please check your spelling: [" & Class_Name & "::" & Method_Name & "]"; endif; epilog delete trMethods; delete trObjectArray; end;

If I could run this somehow then it would solve any issues.

Altering the exception handler to pass back this information is an option I have considered but this would be too much of a change to the clients site to do this.

[allistar]

If you add that method to an existing class (the Application subclass perhaps) and import it into the site's database, then you can run the method with jadloadb using the executeSchema= executeClass= executeMethod= syntax. Once done you can remove the method using a jcf file.

I'm not familiar with the variable naming convention that has prefixes "cr", "tr", "pb". What do they stand for?

[BeeJay]

It looks like all you're after is the last compiled by user/timestamp details. Assuming that's all you want to see, you could run a jadclient.exe extract using a UNL file to extract just that method. There won't be any source, due to encrypted schemas, but you should still be able to see the last compiled user/timestamp details in the extract file.

For example, your batch file would look something like the following, with the relevant adjustments for your installation directory names, scm/ddb/unl file names, and your schema name:

Code: Select all

set BinPath=C:\Jade\bin set SysPath=C:\Jade\system set IniFile=C:\Jade\system\jade.ini %BINPATH%\jadclient.exe path=%SYSPATH% ini=%INIFILE% server=singleUser schema=JadeSchema app=JadeBatchExtract endJade File "TheSchemaFileName.scm" "TheSchemaFileName.ddb" "TheUNLFileName.unl" TheSchemaName pause

And the "UNL" file would contain something like the following, with the relevant adjustments for your class/method names:

Code: Select all

Method TheClassName theMethodName

Hope that helps.

Cheers,
BeeJay.

[BeeJay]

I just realised that the example batch file was for running in singleUser mode. If your client is running a DbServer node, then you could potentially run the jadclient extract in multi-user mode to minimise the impact on the users, or run it singleUser against a copy of their production database restored onto another machine from their most recent backup... the 2nd option would have the added benefit of testing their backups are suitable for recovery in the event of a media/server failure on their production hardware.

Cheers,
BeeJay.

[Stokes]

Thanks, they are both excellent ideas. I think extracting the method sounds like a good plan and that would be a bit cleaner than having to load a method on and delete it off. Will give it a go and let you know how I get on.

Just regarding the variable naming convention:

I'm not familiar with the variable naming convention that has prefixes "cr", "tr", "pb". What do they stand for?

tr = transient reference
pb = Boolean (primitive Boolean)
ps = String
pi = Integer
pdc = Decimal
pr = Real
cr = persistent reference (not sure why it is cr, I think that it might be because pr was Real)

I like the prefix for 2 reasons - 1) You know just by looking at it, if it is a property or reference. If it is a property then you know straight away what type it is. 2) When inspecting objects all types are grouped on a class, so all the Decimals for example will start with pdc so you know where to look straight away.

If you had a property on a class called "number" for example. This could be anything (Integer, Decimal, Real, String) but putting piNumber instead tells you this is an Integer.

[BeeJay]

How do you handle when the type of a property needs to change, which would mean the prefix needs to change, but you don't want to lose the value in the property for existing persistent instances?

ie: If you change the prefix then the property name has changed and Jade will consider it a delete of the old property and an add of a new property.

Do you leave the prefix "wrong" so you don't lose data, or do you have to make sure you include a pre-upgrade jcf rename of the property as part of the release?

It's for that sort of reason that I prefer not to use prefixes like this, especially when people are too lazy to change the name when they change the type. It's not very often that I look at code where I couldn't simply mouse over the part of code in question to see that additional information in a tooltip for the odd occasion where the name of the property/variable isn't sufficiently descriptive. If it is meaningfully named, quite often you don't really need to know the implementation details such as the type anyway. I guess it may potentially be useful if you're looking at a dead tree printout or a stack dump of an exception, but I can't think of the last time I ever physically printed out method source. Actually, I think the only time I've ever done this with Jade was when I was trying to reproduce a problem someone was reporting with the method printing feature in Jade from back in my days in Jade Support. For me personally, I prefer the cleaner look of code that doesn't have artificial prefixes added as the code is then more easily readable as it more closely resembles standard English text, whereas having prefixes like this adds additional noise to the code that means more effort is required to read the underlying code.

Having said that, for some reason it does seem "ok/beneficial" to use prefixes for controls on forms, but that is because you would often run into conflicts where you'd want to use the same "name" for a label and it's associated data entry control.

eg: labFamilyName and txtFamilyName

Cheers,
BeeJay.

[murray]

I'm not a fan of Hungarian notation (prefixes). A good name should indicate the purpose of the named item and improve readbility of the code. As BeeJay said, finding the type information is trivial in an IDE. Jade is already limited by the 30-character length constraint, so the prefixes waste space. Prefixes get in the way in other ways, e.g. a reference to an AppName object would end up being crAppName.

[Dr Danyo]

Beejay / Murray, times like now that this forum needs a "like" system.

[Stokes]

They are all great points thanks for the feedback!

I find reading the code with these prefixes easy because that is how I learnt Jade.

How do you handle when the type of a property needs to change, which would mean the prefix needs to change, but you don't want to lose the value in the property for existing persistent instances?

If this happened I would just create another property. But I must be lucky as this hasn't happened to me yet.

e.g. a reference to an AppName object would end up being crAppName.

In this case the reference would be called "appName" and if you pushed "Cntrl 1" on a class that had this reference you wouldn't know if it was a reference or a property until you selected it. But if it had crAppName then you would know it was a reference. I think this might have changed in Jade 7 where it shows a picture next to the reference or property

[BeeJay]

Actually, in Jade 7 it's even better than that. You don't even need to press Ctrl+1, or any of the other Ctrl+ options, you simply need to start typing and auto-complete shows a list of options that match what you've typed. Moving the selection using DownArrow, or UpArrow, shows all the details about the selected item in a tool tip, as per the following screen shots:

A reference of type C2 is selected in the auto-complete list

Jade7 IDE #1.png (7.23 KiB) Viewed 10591 times

A string attribute is selected in the auto-complete list

Jade7 IDE #2.png (9.82 KiB) Viewed 10591 times

The best part about auto-complete is how little you now need to type in the IDE to write the desired code, normally after a couple of keypresses the property/method/constant/variable/translatablestring that you want to use is now listed, or indeed quite often selected, and you can type the next relevant character such as Space or . or , or : or ( or [ etc and it will put the currently selected item in the auto-complete list into the editor and then the character that you typed.

The worst part is once you get used to it, if you're having to do some work in a 6.3 environment, say to produce a "hotfix" for an older version of your product, it's a real pain not having auto-complete and having to revert to "Ctrl+1/2/3/4" respectively to get the desired "properties/methods/constants/parameters & local variables" in a selection list.

Cheers,
BeeJay.