Arjens suggestions brings back the "cnsnnts nl(y) wndrfl" good old unix times. But as in unix: for a non-insider, it's far from intuitive As I think it's hard to beat the LIN/COL heritage, so we have to find a 3-letter-word for collection: Right now in the data model, uniface suggests the postfix "COLL" for interface name, but it competes with "OCC" postfixing the occurence interface name: so what about "OCC" and "LOC" (or "AOC" from "All Occurences")

Suggestion CLM for column CLC for collection Trying to make things unique, based on consonants

gianni said Hi Ingo, As a quick thinking I prefer COL for COLUMN...so what about CLL for collection ? As a separate thinking I was faithful to 3 letters shortnames for long time...since few years I moved to 4... :-) Cheers from Italy...Gianni  

ThanX Gianni I will use CLL Greetings from good old germany Ingo

Hi Ingo, As a quick thinking I prefer COL for COLUMN...so what about CLL for collection ? As a separate thinking I was faithful to 3 letters shortnames for long time...since few years I moved to 4... :-) Cheers from Italy...Gianni

And I got another "conflict" when try to name things I'm currently building a framework for handling SOAP-request. There are several services dealing with entities, on each entity there are collection occurences operations. So far so good ... As Uniface could name globale procedures only by 16 characters, I have to shorten some of of this name. But then I run into a conflict for the abbreviation for "collection".

Any idea for naming this "things" TIA Ingo

istiller said BUT But what about handles and structures? One can't pass handle and structs as part of a UIL, as UnifAce do not proper convert between string and handl/struct. The first handle to exchange with another component and you can forget about strings/UIL So there is a need for special operations with parameter of type handle resp. struc

 Instead of a UIL (Uniface List) you could use Struct parameters. A Struct can handle (AFAIK) all the available Uniface data types. One catch: I believe handles can only be "stored" in Structs since Uniface 9.7.01.

BTW: I could not get UnifAce to return a collection handle via operation parameter (between two components) If we use globale variables of type handle, that's no problem. Any one experienced the same problem?

 I currently have no (good) explanation for this. I would need to do some tests. But did you define the Collection Operation(s) on Model level or just in the component? AFAIK the collection and occurrence operation(s) are not automatically added to the component signatures (for details see here and here). Maybe this could be a possible explanation for the behavior you're seeing. Just an idea. Hope this helps. Daniel Uniface Support

Hi Zdeněk, hi Gianni Thanks for your answers. And we did it the same way, we do have four "string" parameters

1. VAL_IN     ;  UIL input   (UIL=UnifaceItemList, maybe nested)
2. VAL_OUT  ;  UIL ouput
3. PARA        ;  UIL control parameter
4. GDA         ;  UIL for global data (like session infos, last errors, ...)

To this point, we don't have to change an signature even if we change the structure of the input BUT But what about handles and structures? One can't pass handle and structs as part of a UIL, as UnifAce do not proper convert between string and handl/struct. The first handle to exchange with another component and you can forget about strings/UIL So there is a need for special operations with parameter of type handle resp. struc Ingo BTW: I could not get UnifAce to return a collection handle via operation parameter (between two components) If we use globale variables of type handle, that's no problem. Any one experienced the same problem?

gianni said Hi Ingo, what about: X_OPNAME[_SPECIFIC] X = prefix helping developer to immediately identify the origin of the operation like: T for Templates, G for Globals (Includes, Model, ...) and C for Component OPNAME = what the operation is globally doing SPECIFIC = (optional) like in your example the two different PRINT operation will be specific to different specific needs Hope it helps... Gianni

I forgot something! Sorry... All operations use uniface lists as params...something similar to sochaz: MY_OPERATION_NAME(params_in, params_out, controls_inout); params_in are input params, params_out are output params while controls_inout are environment variables needed to correctly execute MY_OPERATION_NAME without using external references. Now it's all... Gianni

Hi,   just quick answers: 1. in 95% we do not use English to name the operations/entries/global procedures etc... :-) 2. we solved this problem by starting to use id-lists as parameters... hopefully the consequences are obvious here...  Ok... here is an example: for standard operation in a service component, there are always 5 parameters defined as string: data in, parameters in, data out, parameters out, message out. The first 4 parameters are always idlist (which may contain sublists of course). The last parameter is reserved for error message, just a simple human-readable... oh... end-user readable string. In your example, there would be only one operation OP_PRINT and you can send a different data. Or you can send exactly the same data, but in the "parameters in" parameter you would send the type of operation, or type of data or whatever you need to influence the behavior of that operation. Of course, should you need a new behavior, there is no change in the signature (this was really very very very appreciated in the times we were using those .dol and .urr files). Regards, Zdeněk Socha

Hi Ingo, what about: X_OPNAME[_SPECIFIC] X = prefix helping developer to immediately identify the origin of the operation like: T for Templates, G for Globals (Includes, Model, ...) and C for Component OPNAME = what the operation is globally doing SPECIFIC = (optional) like in your example the two different PRINT operation will be specific to different specific needs Hope it helps... Gianni

istiller said Hi Zdeněk, hi Gianni ... BUT But what about handles and structures? One can't pass handle and structs as part of a UIL, as UnifAce do not proper convert between string and handl/struct. ...

Hello Ingo, we don't use handles. :-) We have tried, but there are too many problems with them. So we keep using named instances, which is string and it's very easy to pass them as parameter. I don't see any benefit in handles over named-instances. All in all its always just "handle" to a component instance and since our application is quite "old", it's impossible to change everything to handle... and it's much easier to have only one approach. And as for structures... well... we don't use structs. :D We use them maybe in 2 components? Since it's quite easy (and the only way) to convert data from Uniface to json for example. But internally, we use lists and id-lists. The situation is quite similar to handles. Don't see much benefits. As long as structs has limited usage (for example it can't be passed to a 3GL component), there is no reason to use them. So, all in all... our "handles" are strings and "structs" are in fact idlists, so strings, too - we have no problem passing this as parameter to anything (be it Uniface component or 3GL or Oracle SQL or PL/SQL or anything). Kind regards, Zdeněk Socha