Change HS API to support lineage storage provided by implementations [#492068]

Comment #1

Wim Leers

Ghent 🇧🇪🇪🇺

CreditAttribution: Wim Leers commented 18 July 2009 at 11:23

Status:

Postponed

» Closed (won't fix)

HS is just a widget and does not and should not and will not provide data storage itself. I'm sticking with that. If you want to have the ability to remember lineages with multiple parents (as you explained clearly in follow-up #4 of #476656), then it is up to the underlying module to support that. IMO, it should be considered a bug in Taxonomy, not a bug in HS, that this is impossible.

Log in or register to post comments

Comment #2

crea CreditAttribution: crea commented 18 July 2009 at 13:40

Status:

Closed (won't fix)

» Active

I understand that you want to clear issue queue, but atleast try to read carefully :)
I didn't mean that HS should store it itself, it's reasonable that HS provides widget and widget only. However, once there is module supporting storing lineages, HS will need modification too, since HS will still calculate lineage old way and get wrong results displayed in dropbox. So this problem can't be solved purely outside of HS. That's why I suggested to change API so HS atleast would become aware of the actual lineage, so HS wouldn't calculate lineage but get provided lineage out of storage (while storage module would be provided outside of HS as part of HS API implementation).

Log in or register to post comments

Comment #3

Wim Leers

Ghent 🇧🇪🇪🇺

CreditAttribution: Wim Leers commented 18 July 2009 at 16:41

Category:	task	» feature
Status:	Active	» Postponed

Oh, sorry, I didn't understand you that way — I had not even thought of that!

But you're absolutely right, of course. Thanks for insisting :)

This should be implemented in the next major version of HS.

Log in or register to post comments

Comment #4

Bilmar CreditAttribution: Bilmar commented 16 December 2009 at 07:33

I am in need of this new feature as I am trying to create the following relationship where 'Station 2' is located on both Train Line A and Train Line B. I am using hierarchical select views exposed filter to select Station 2 for the search of nodes, but using HS when I select [Train Line A]=>[Station 2] a third level opens with Station 2 in the box and the second level (which should have Station 2) is blank and the search does not work. Looks like [Train Line A]=>[ *blank* ]=>[Station 2]

Train Line A
-Station 1
-Station 2
-Station 3
Train Line B
-Station 4
-Station 2
-Station 5

However, if I do not use HS and just use a regular dropdown for the views exposed filter search, the search result works showing all nodes that are selected with Train Line A or Train Line B or Train Line A=>Station 2 or Train Line B=>Station 2 (note: term lineage is saved). Does this mean that there is an issue with HS and not core taxonomy as suggested above as it works when I don't use HS?

HS is such an AWESOME module and it would be great if I could use it in the Views exposed filter search.

Log in or register to post comments

Comment #5

YK85 CreditAttribution: YK85 commented 3 February 2010 at 10:37

subscribing - I'm coming from #678828: Term with multiple parents breaks HS

Log in or register to post comments

Comment #6

Bilmar CreditAttribution: Bilmar commented 3 February 2010 at 14:43

Below are screencasts showing the issue (from #678828: Term with multiple parents breaks HS)

http://www.screencast.com/users/trupal218/folders/Jing/media/f1f13a59-b1...
http://www.screencast.com/users/trupal218/folders/Jing/media/0d0ffd56-45...

Regards

Log in or register to post comments

Comment #7

crea CreditAttribution: crea commented 10 February 2010 at 16:56

If someone decides to work on this, that module could help: http://drupal.org/project/lineage
Definitely worth to inspect it deeper and maybe join forces.

Log in or register to post comments

Comment #8

rburgundy CreditAttribution: rburgundy commented 16 February 2010 at 05:47

+1 subscribing

Log in or register to post comments

Comment #9

YK85 CreditAttribution: YK85 commented 17 February 2010 at 02:16

Status:

Postponed

» Active

http://drupal.org/node/678828#comment-2579304 states the maintainer will be looking into supporting this in the coming weeks (very exiciting!). I am setting the status to Active at this moment to get the attention of those following the HS queue. Thanks

Log in or register to post comments

Comment #10

klonos

he/him

English

90% Melbourne, Australia - 10% Larissa, Greece

CreditAttribution: klonos commented 28 February 2010 at 21:32

@Wim: status update please?

Log in or register to post comments

Comment #11

Wim Leers

Ghent 🇧🇪🇪🇺

CreditAttribution: Wim Leers commented 28 February 2010 at 22:46

I stated I'd be looking into fixing that other issue, which is in fact *not* a duplicate of this issue (see my comment). I did that.
I don't think it'd be very useful to implementing this feature right now.

To be honest, HS is a mess right now internally. The extremely poor state of Forms API's support for advanced form elements such as Hierarchical Select is the primary culprit, but so is my lack of dedication/time to maintain a clean structure in HS' codebase. It has grown organically and it shows. I'd prefer to implement this feature in HS 4 and not in HS 3, because HS 4 will be redesigned from the ground up and this feature could be taken into consideration in the design stage.

Nevertheless, I'm definitely willing to add support for it in HS 3 if there's enough interest. What changes to the HS API do you propose, crea?

Log in or register to post comments

Comment #12

crea CreditAttribution: crea commented 28 February 2010 at 22:57

Well introduce a hook that performs CRUD on individual lineages. HS JS somehow would have to provide ordered items to AHAH callbacks otherwise correct lineage is lost as soon as user presses "add". If there's hook, HS interfaces with that hook instead of guessing lineages. If there's no module implementing the hook, fallback to previous behaviour (store items and calculate lineages)