Download & Extend

Need ability to allow links in header to be functional

Project:Views Accordion
Version:6.x-1.x-dev
Component:Code
Category:feature request
Priority:normal
Assigned:Unassigned
Status:active

Issue Summary

In one of our uses of the module we require the ability to allow the lined fields in the header to still be able to be clicked.

I would like to see this as an option on can enable or disable in the view as needed. I see this as a simple check box in the style settings.

To this end I have created the attached patch file that adds this functionality.

AttachmentSize
views_accordion-enable-header-links.patch2.63 KB

Comments

#1

Opps, I just noticed I have the patch backwards... attached here is the CORRECT file...

AttachmentSize
views_accordion-enable-header-links.patch 2.63 KB

#2

Thanks for the patch cap60552, will review it as soon as my schedule allows for me to work peacefully on the issue queue again.

#3

Status:active» needs review

#4

Status:needs review» fixed

Reading the patch, it looks ok to me. However, this patch was not rolled against the latest dev of the module, so it fails to apply, specifically on the js file.

Since this is a simple patch, I went ahead and re-rolled it for our latest dev, find it attached.

I have committed this already, should be available in the dev version in a while. Thanks!

AttachmentSize
views_accordion-743224.patch 3.2 KB

#5

Status:fixed» closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

#6

Thank you for the function, only:

it would be nice having a link in the header, if you click on it, that it does not open/close the node.

I am not sure where to place the :not(a) in the code.

#7

Status:closed (fixed)» needs review

OK, I've gone ahead and taken a look at this funkytraffic, please test the attached patch, in as many browsers as you can (IE, chrome, safari, ff is already tested), since I am checking for .originalTarget.tagName, and I'm not sure this is available on all browsers.

AttachmentSize
galleryformatter-743224-2.patch 1.92 KB

#8

OK, ignore the last patch, I've found out that originalTarget.tagName breaks in chrome. The attached patch uses ev.target.nodeName, which works both on FF and Chrome. We need to test this in IE and safari at least for this patch to get in, can you help here?

AttachmentSize
galleryformatter-743224-2-1.patch 1.92 KB

#9

Works great in FF 3.6

This was a fast reply!

Will test it in IE and Safari on W7, wait a minute.

#10

Test on Windows 7 - XAMPP running with Safari 5.02 an IETester for IE 6,7 & 8.

Works great!

Will upload it to dasdossier.de/magazin later.Look at the sidebar there.

#11

Status:needs review» fixed

Thats good news funkytraffic, it even works on ie6, that's a good sign.

I've already committed the patch to CVS, so the latest dev version of the module will have it when the package generator rebuilds de tarball. Thanks for testing!

#12

Status:fixed» closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

#13

Status:closed (fixed)» active

When clicking on a link the accordion still activates. I propose to catch that it was a link that was clicked so that the accordion is not popped down and that the link's destination begins to load. Right now, the destination begins to load, but the browser sits on the current page for a bit and the accordion pops down, which seems to throw off users since they don't expect the link to show them content on the current page AND go to a new one. It's reasonable to think that if a user clicks a link they want to navigate away and aren't concerned with the content exposed by the accordion. Thoughts?

#14

Does anyone else see a need for such functionality? I'm surprised there were no responses given this module is "Actively maintained."

#15

Yup, no response because people have a life to take care of besides giving free code and support to the world.

That said, I do see that as something that would be nice to have, I would accept patches implementing it properly.

#16

>Yup, no response because people have a life to take care of besides giving free code and support to the world.

True. Is this meant to be rude though? It comes off that way.

I would've submitted a patch, but I merely asked for an opinion on whether this was desirable functionality. Why submit a patch before I know if this is desirable functionality or not? Should I go ahead with this, learn your code, and submit a patch? Seems very easy to do...

#17

Like I said, I would accept (good) patches in this direction.