nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

profiling derived attributed are not returned as set

medini_1057227803

Hi,

I have defined a derived profiling attribute which is supposed to return a set:

self.mediniGetTracedElements(hazard::PlainItem)-> select(e | not e.oclAsType(hazard::PlainItem).name.matches('\\w+_FNID_\\d{4}'))->asSet()

It resolves the traced PlainItems which do not match a specific regex.

In the form editors, multiple outcomes are returned by this attribute.

However, in the console the attribute only returns the first element of the set.

Also when I use the attribute in other defined profile attributed, it also returns the first element.

Is it the expected behaviour?

How can we have a set also in the console?

Thanks

Find more posts tagged with

medini

medini legacy

Accepted answers

medini_1023909254

Hi Mohammad,

somehow it looks like something is going wrong with the resolution of the profile properties. I did some testing and it seems that everything works as expected in case an explicit access to the properties is done using getProfilePropertyValue() - i.e. using self.getProfilePropertyValue('user_allocated_items') instead of self.user_allocated_items

Can you check that on your side?

Eckhardt

All comments

medini_1024169437

Hi Golanbari,

which console do you refer to, the OCL console window?

Strange that the result is different in that case though.

Jan

medini_1005899080

Hi Jan,

yes, it is the console. Also if you create a new profile property refering to this user property, only one (the first) Element is shown.

Sven

medini_1024169437

Hi Golanbari, Sven,

I could not reproduce the console issue, however, I could reproduce that the new referring profile prop just shows the first,

strange it doe snot work if the second is an OCL property but it works if it is a JS property.

Seems to be a defect I would say

Jan

medini_1024169437

Sven, which version are you using, could you post that here please?

Jan

medini_1057227803

medini analyze 2022 R1
Build: 22.1.0.220105152335-bf79609

medini_1057227803

I also tried the javascript. For comparison:

My simple OCL profiling (user_allocated_items):

self.mediniGetTracedElements(hazard::PlainItem)

My simple javascript profiling (user_allocated_items_js):

self.mediniGetTracedElements(Metamodel.hazard.PlainItem)

Both of them show a list of traced elements in the form viewer. But in the OCL console, they show just one element, though a different one (not the same element is returned, probably due to some weird ordering difference).

HOWEVER:

When the same profiling attribute is used in a javascript script file (.js file), they return the a list of elements (which is correct).

My simple script.js:

console.log("size {0}", selection[0].user_allocated_items.size());
console.log("size {0}", selection[0].user_allocated_items_js.size());

and the result is:

size 2
size 2

Saber

medini_1024169437

I figured the same. Could you please now try to - instead of using them in a JS file - create two more other property that use self.user_allocated_items resp. user_allocated_items_js, one in JS the other in OCL?

Jan

medini_1057227803

Now it is even worse

It seems that ocl cannot resolve the type but the js can.

Is there any solution for that? our project relies on such attributes and it is now practically impossible to determine where it is correct and where it is wrong ..