[Mondrian] Properties VS multiple member captions

[Roland Bouman]

"This is why I was wondering if maybe it might be a good idea to have a
feature that allows the definition of more than one caption per level. "

Well, "the Caption" is simply a property. An intrinsic one, but still, only
a property. There's nothing that says how it should be used.
Although most tool vendors take the hint and use it for a label in the UI :)
So, what difference does it make what property you use to fill that label?
it's up to the tool really.

If you like you can create custom properties called Caption1, Caption2,
...etc. and then you basically have what you want.
One could perhaps imagine an additional array data type, and a special MDX
accessor that does: Member.Properties("Captions").Item(1) or something like
that, but it doesn't really add more functionality.

(For the record, I am not proposing such a feature should be created - on
the contrary!)

I guess I'm saying, you already have what you want. All you need is user
input that tells you which properties the end user would like to use as
labels in the UI/output.

Best regards,

Roland

Roland

On Fri, Apr 24, 2015 at 3:44 PM, Diethard Steiner <
diethard.steiner at gmail.com> wrote:

> Thanks Roland for your reply! For the use case I illustrated before I was
> wondering if properties are really the right way to go. I’ve seen a few
> Mondrian schemas where it was implemented this way - and this might be
> because there was no better option. I do think properties have their valid
> use cases, however, displaying Jan or January or 1 is more like using a
> different format (or caption). This is why I was wondering if maybe it
> might be a good idea to have a feature that allows the definition of more
> than one caption per level. The advantage I see is that once such a feature
> is support in Mondrian and there is MDX support for it, we could just
> display that caption independently (instead of having to display the
> standard caption plus the member property). [Note: I am just talking about
> cases where there is a 1:1 relationship between the member key and the
> alternative caption].
>
>
> On 24 Apr 2015, at 14:18, Roland Bouman <roland.bouman at gmail.com> wrote:
>
> Personally, I think it is the job of the client tool to provide captions,
> and to provide the user with options that say which properties should be
> used in the user interface to label members.
>
> In fact this is already the case: many tools will use the intrinsic
> property MEMBER_NAME or MEMBER_CAPTION; it's just that most client tools
> don't bother to offer options for the end user to make a selection, let
> alone, specify a user-defined property.
>
> I don't see how Mondrian can dictate how properties are to be used to
> label things in the user interface.
>
> My 2cts.
>
> Roland.
>
> On Fri, Apr 24, 2015 at 2:57 PM, Diethard Steiner <
> diethard.steiner at gmail.com> wrote:
>
>> Good afternoon,
>>
>> Over the last few weeks I had quite an interesting discussion about a
>> date dimension and properties.
>>
>> Properties, as you might know, are mainly used to display additional info
>> about a member. And this info does not have to be unique to one member
>> (value/key). So e.g. price could be a property of product and the same
>> price could potentially show up for various products.
>>
>> There is however at least one interesting case where properties are used
>> to display alternative labels/captions: E.g. think of a date dimension
>> where month might be displayed as an Integer value, but using properties
>> you could also show Jan and/or January (2 additional properties that are
>> available in our imaginary Mondrian Schema). Now in this case the values
>> are unique for each member, meaning, Jan will only show up for 1 and not
>> for e.g. 2 as well. End user would might want to sometimes use the
>> abbreviated month name (e.g. Jan) in the report, sometimes the full name
>> and on rare occasions the integer version. However, the end user isn’t
>> interested in showing the key (the integer version of the month) when they
>> use any of the properties. The problem is that properties cannot be used on
>> their own (which makes sense when the values are not unique). So here
>> really we would have to create 2 additional hierarchies to independently
>> display the month abbreviation or the month full name, but this approach is
>> certainly far from ideal. So I was wondering, if there is a way to define
>> alternative captions for a member? (which means we would only have to
>> create one hierarchy which could cater for various needs). For a moment I
>> thought maybe I could just use a formatting mask to turn 1 into Jan or
>> January. This might work with a date dimension, but let’s think of a more
>> complex case, where these alternative captions can only be sourced from a
>> DB.
>>
>> I am looking forward to hearing your thoughts on this.
>>
>> Best regards,
>> Diethard
>>
>> _______________________________________________
>> Mondrian mailing list
>> Mondrian at pentaho.org
>> http://lists.pentaho.org/mailman/listinfo/mondrian
>>
>
>
>
> --
> Roland Bouman
> blog: http://rpbouman.blogspot.com/
> twitter: @rolandbouman
> linkedin: http://www.linkedin.com/profile/view?id=5142800&trk=tab_pro
>
> Author of "Pentaho Solutions" (Wiley, ISBN: 978-0-470-48432-6
> http://tinyurl.com/lvxa88) and "Pentaho Kettle Solutions" (Wiley, ISBN:
> 978-0-470-63517-9 http://tinyurl.com/33r7a8m)
>  _______________________________________________
> Mondrian mailing list
> Mondrian at pentaho.org
> http://lists.pentaho.org/mailman/listinfo/mondrian
>
>
>
> _______________________________________________
> Mondrian mailing list
> Mondrian at pentaho.org
> http://lists.pentaho.org/mailman/listinfo/mondrian
>
>


-- 
Roland Bouman
blog: http://rpbouman.blogspot.com/
twitter: @rolandbouman
linkedin: http://www.linkedin.com/profile/view?id=5142800&trk=tab_pro

Author of "Pentaho Solutions" (Wiley, ISBN: 978-0-470-48432-6
http://tinyurl.com/lvxa88) and "Pentaho Kettle Solutions" (Wiley, ISBN:
978-0-470-63517-9 http://tinyurl.com/33r7a8m)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.pentaho.org/pipermail/mondrian/attachments/20150424/7fe1f161/attachment.html