Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: Request Tracker: Devel

a fancy ShowUser - not quite possible

 

 

Request Tracker devel RSS feed   Index | Next | Previous | View Threaded


Olly.Stephens at arm

Jul 1, 2008, 6:54 AM

Post #1 of 5 (355 views)
Permalink
a fancy ShowUser - not quite possible

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: http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-devel


todd at chaka

Jul 1, 2008, 8:57 AM

Post #2 of 5 (339 views)
Permalink
Re: a fancy ShowUser - not quite possible [In reply to]

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[at]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: http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-devel
>
_______________________________________________
List info: http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-devel


jesse at bestpractical

Jul 1, 2008, 9:51 AM

Post #3 of 5 (342 views)
Permalink
Re: a fancy ShowUser - not quite possible [In reply to]

On Jul 1, 2008, at 6:57 PM, 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."
>

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[at]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: http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-devel
>>
> _______________________________________________
> List info: http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-devel
>

_______________________________________________
List info: http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-devel


Olly.Stephens at arm

Jul 1, 2008, 1:11 PM

Post #4 of 5 (344 views)
Permalink
Re: a fancy ShowUser - not quite possible [In reply to]

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.


_______________________________________________
List info: http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-devel


todd at chaka

Jul 1, 2008, 7:53 PM

Post #5 of 5 (330 views)
Permalink
Re: a fancy ShowUser - not quite possible [In reply to]

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[at]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.
>
>
>
_______________________________________________
List info: http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-devel

Request Tracker devel RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact lists@gossamer-threads.com
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.