I'll see if I can answer those points;
flogoya wrote:
I'm having a very hard time understanding your explanation. I know it is very complete and it seems to be very well explained, but still I'm not getting it, sorry :(
Thats OK, what I'm trying to describe is a bit "weird" and it relies on a couple of disparate things all working together in sync to get the result.
But the result I am getting is that on an object EDIT page, that I can introduce a READ ONLY (i.e. display only) value on the screen that can be "anything"
(and when I am saying "anything", I almost mean that, I have used this to display calulated values based on the current object (similar to a calcu;lated attribute
but where the calculation is much more complecx than we can achieve we the stock calculated attribute method), to dsplay explanative text values containing hyperlinks,
summary information from related objects). I can easily see how I could even extend the method so that I could call web-services and display completely external
data on screen ; basically "anything" that you can write a piece of pararameter-driven code to return.
--
flogoya wrote:
Let me explain far more my situation: I have 5 dependant lookups. For the first four, I created a custom object where I associated values from lookup1 with values from lookup2. Then for dependant lookup3 I created a new custom object where I associated values from lookup2 with values from lookup3, and the same I did with lookup4.
Now the only lookup left that I have has only two values: Critical - Not Critical. But I have to associate these with the lookup4, which has more than hundreds of values.
OK this is where I am a bit confused by your use-case, are these new "custom objects" just existing to maintain some static data-relationships? Or are they
actual objects that you are allowing the end-use to maniulate in some way in Clarity? (if the former then I don't see the need to be creating these
as custom objects).
flogoya wrote:
My questions:
1. I should first create a parameterised NSQL lookup (I understand a dynamic lookup) that would take the object id as a parameter and would execute sql and returns anything as the display text and always returns 1 as the key value. - I don't understand this. Definitely I got very confused trying to relate this with my situation.
OK what I'm saying here is that my "display only" attribute is built using a lookup ; the actual attribute on the underlying Clarity object ALWAYS contains
a dummy value of "1", but then we associate the attribute on the object with the parameterised lookup (which takes the object id as the patrameter) and
then in the NSQL logic in the lookup I can construct my value of "anything" (see above for definition of "anything") based on the object id.
Why this works is that Clarity sees the attribute (value "1") then goes to the lookup to workout what the "display value" for "1" is - but the NSQL logic
in th elookup used the parameter object id to determine what that display text should be for THIS object (rather than for "1") and returns that value
as the matching value for "1" in the lookup.
flogoya wrote:
2. When you say: 'create a dummy attribute as a lookup - one per "thing" that you want to display -' do you mean I need to create a dummy attribute for 'Critical' and another one for 'Not Critical'?
So "NO" thats no what I mean - I mean you need a dummy attribute/parametrised lookup per read-only attribute that you want to display.
flogoya wrote:
If I want an NSQL to show any value on a dynamic lookup I need to have this value already on the database, right? I mean, I would onlbe doing a selection and placing it on a field on the general project properties (for instance)
Not neccessarily (but the value existing somewhere on the database would be a normal usage for the method) - as long as you can programtically construct
the value in the NSQL based on the parameter object id (or even in a database function that the NSQL uses) then thats all we need.
flogoya wrote:
My main problem is that I don't have this association already made. I only have the values from the previous lookup, and based on the value selected, Clarity would determine if it is critical or not.
The "logic" about whether you value is "Critical" or "Non-Critical" is what I mean by the programtic logic in the statement above - I have no idea
how YOU would calculate that, but you can just code that calulation (however simple OR complex it may be) into the lookup.
flogoya wrote:
I tried using a process but I don't know how to set the condition since when I want to select the values from the lookup (lookup4) this one is a dynamic lookup and the list of values is not displayed.
The ADVANTAGE a process solution has over my dummy attribute/lookup solution is that the process would actually persist you calulated value on the
Clarity database, my solution is only ever calulated at display-time in the GUI and on on the Object EDIT screen.
flogoya wrote:
I'm only trying to avoid to create a custom object just to make the match between hundreds of values with its respective state: critical or not critical.
OK, as I say above I'm not really sure that I understand you custom object requirements at all ; if this is not "user data" then you can just "code it".
:wacko: