Wish List - Executing a raw comand

rocketman

This is a feature I discovered many years ago as a 4D programmer which I think would be really useful in AwareIM. I think the command was called "Execute" though that doesn't matter.

Essentially it's a "Get out of jail" facility for supervisors/developers. It popped up a text box which allowed the developer to enter some raw code which it would then execute.

So for example instead of writing a process which I will use possibly once and then have to test and publish, I could simply use the execute command to fix some data in the system

So I would EXECUTE then type in "Find Members Where Members.ChargeScheme is undefined" (Execute would bring and hold Members in context). Then

EXECUTE again and I would type "Members.ChargeScheme='Normal'

Job done - painlessly

What do you think?

BobK

I Like It.

1 suggestion: allow multiple commands in 1 EXECUTE, so you do not have to run EXECUTE multiple times.

pbrad

Hi,

It seems to me that there are already at least two ways that you could achieve what you are describing.

Cheers,
Pete

rocketman

Oh, do tell all Pete

pbrad

Yeah, I figured that one would come back and bite me in the ass. I'm just headed out to a meeting but will give a couple of examples later today.

Pete

rocketman

Somehow using SET right?. any examples would be appreciated. (i know I can do the query from the standard menu. Question (i assume yes) is the resulting query set held in context?

pbrad

Hi,

Tom Ford is really the grand master at this but basically you build a process that uses variables that can be set at runtime by building a non-persisted object(s) and calling that(those) objects as part of the process. I.E.: FIND Object1 WHERE NonPersistedObject.Attribute1... (You can provide secondary non persisted objects or dynamically populated secondary fields in the first non persisted object based on the selection of the first field. The first field is dynamically fed with a list of the available objects that you might want to query).

Tom would probably argue that you use fields in system settings in order to retain the last used selections but you can go either way. Once you have the desired objects in context you can use SET or similar methods to manipulate the data. Again, you can limit the SET selections using another non-persisted object to build the SET statement.

I think that the trick is to consider non-persisted business objects or system setting attributes or even LoggedInUser attributes as highly flexible and powerful variables that can be populated in any number of ways and have rules applied to them. With a little bit of thought and planning, you can create very flexible 'generic' or 'all purpose' processes that are easily manipulated at runtime to achieve the desired results.

I'm afraid that I don't have time to put an example together for you but hopefully this may be an approach that will work for you and my explanation makes some kind of sense.

Cheers,
Pete