Hi,
I’ve implemented a local fancier version of “Elements/ShowUserVerbose” -
one that shows the username but then has a tooltip attached to it that
shows more info about the user when you hover over it.
This worked fine initially but then I noticed a problem - the "ShowUser"
element is used in multiple contexts. For example, it’s also used in
Elements/SelectUsers to generate the options in a multiple select. In
this situation I just want a simple name and my override mucks things
up.
I can think of two solutions to this so I thought I’d canvas people as
to which would be the more likely to be adopted upstream if I provided a
patch:
A) Introduce a “ShowUserFancy” element which is used in cases where
there is opportunity to enhance the HTML produced but who’s default
action is just to drop through to ShowUser (ie gives me a more specific
hook to override)
B) Add a “Context” parameter to the ShowUser calls so that I can tell if
it’s in the plain page or in a form element etc. (ie gives me the
necessary info in my override to make a formatting decision)
C) Abandon my attempt to do fancy things 
Which would people prefer?
Any whilst I’m on the subject, I noticed a few places where a username
was rendered directly rather than through ShowUser; the most obvious of
these is in the title part of each transaction of a ticket; is there
any reason why this shouldn’t go through the component too? It’s one of
the places I’d like to hook my fancy popup into.
Thanks,
Olly
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
D) You can use the Mason request object to figure out where you were
called from and then "do the right thing."On Tue, Jul 1, 2008 at 9:54 AM, Olly Stephens Olly.Stephens@arm.com wrote:
Hi,
I’ve implemented a local fancier version of “Elements/ShowUserVerbose” -
one that shows the username but then has a tooltip attached to it that
shows more info about the user when you hover over it.
This worked fine initially but then I noticed a problem - the “ShowUser”
element is used in multiple contexts. For example, it’s also used in
Elements/SelectUsers to generate the options in a multiple select. In
this situation I just want a simple name and my override mucks things
up.
I can think of two solutions to this so I thought I’d canvas people as
to which would be the more likely to be adopted upstream if I provided a
patch:
A) Introduce a “ShowUserFancy” element which is used in cases where
there is opportunity to enhance the HTML produced but who’s default
action is just to drop through to ShowUser (ie gives me a more specific
hook to override)
B) Add a “Context” parameter to the ShowUser calls so that I can tell if
it’s in the plain page or in a form element etc. (ie gives me the
necessary info in my override to make a formatting decision)
C) Abandon my attempt to do fancy things 
Which would people prefer?
Any whilst I’m on the subject, I noticed a few places where a username
was rendered directly rather than through ShowUser; the most obvious of
these is in the title part of each transaction of a ticket; is there
any reason why this shouldn’t go through the component too? It’s one of
the places I’d like to hook my fancy popup into.
Thanks,
Olly
–
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
List info: The rt-devel Archives
D) You can use the Mason request object to figure out where you were
called from and then “do the right thing.”
I’d support a flag to ShowUser which says “you’re being used somewhere
html isn’t acceptable”
It needs a better name than that.> On Tue, Jul 1, 2008 at 9:54 AM, Olly Stephens Olly.Stephens@arm.com wrote:
Hi,
I’ve implemented a local fancier version of “Elements/
ShowUserVerbose” -
one that shows the username but then has a tooltip attached to it
that
shows more info about the user when you hover over it.
This worked fine initially but then I noticed a problem - the
“ShowUser”
element is used in multiple contexts. For example, it’s also used in
Elements/SelectUsers to generate the options in a multiple select.
In
this situation I just want a simple name and my override mucks things
up.
I can think of two solutions to this so I thought I’d canvas people
as
to which would be the more likely to be adopted upstream if I
provided a
patch:
A) Introduce a “ShowUserFancy” element which is used in cases where
there is opportunity to enhance the HTML produced but who’s default
action is just to drop through to ShowUser (ie gives me a more
specific
hook to override)
B) Add a “Context” parameter to the ShowUser calls so that I can
tell if
it’s in the plain page or in a form element etc. (ie gives me the
necessary info in my override to make a formatting decision)
C) Abandon my attempt to do fancy things
Which would people prefer?
Any whilst I’m on the subject, I noticed a few places where a
username
was rendered directly rather than through ShowUser; the most
obvious of
these is in the title part of each transaction of a ticket; is there
any reason why this shouldn’t go through the component too? It’s
one of
the places I’d like to hook my fancy popup into.
Thanks,
Olly
–
IMPORTANT NOTICE: The contents of this email and any attachments
are confidential and may also be privileged. If you are not the
intended recipient, please notify the sender immediately and do not
disclose the contents to any other person, use it for any purpose,
or store or copy the information in any medium. Thank you.
List info: The rt-devel Archives
List info: The rt-devel Archives
Todd Chapman wrote:
D) You can use the Mason request object to figure out where you were
called from and then “do the right thing.”
Thanks Todd; I hadn’t actually thought of that option but it’s a good one. Not sure it will work though; there’s nothing to stop a component from using ShowUser in multiple contexts - haven’t looked to see if any do - so it would be an imprecise solution.
Jesse Vincent wrote:
I’d support a flag to ShowUser which says “you’re being used somewhere
html isn’t acceptable”
It needs a better name than that.
Cool. I’ll add this to my TODO list then (both thinking of a name and creating a patch)
Olly
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
There is nothing to keep you from figuring out the complete call chain
and doing the right thing for each situation.On Tue, Jul 1, 2008 at 4:11 PM, Olly Stephens Olly.Stephens@arm.com wrote:
Todd Chapman wrote:
D) You can use the Mason request object to figure out where you were
called from and then “do the right thing.”
Thanks Todd; I hadn’t actually thought of that option but it’s a good one. Not sure it will work though; there’s nothing to stop a component from using ShowUser in multiple contexts - haven’t looked to see if any do - so it would be an imprecise solution.
Jesse Vincent wrote:
I’d support a flag to ShowUser which says “you’re being used somewhere
html isn’t acceptable”
It needs a better name than that.
Cool. I’ll add this to my TODO list then (both thinking of a name and creating a patch)
Olly
–
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.