NaturalHistoryMuseum / scratchpads2

Scratchpads 2.0
http://scratchpads.org
GNU General Public License v2.0
199 stars 83 forks source link

weight module #3076

Closed informatics-dev closed 11 years ago

informatics-dev commented 11 years ago

Description:

This is needed for some views on the ICZN site - and probably should be available to others too.

informatics-dev commented 11 years ago

Comment by Alice Heaton

Any reason to weight rather than nodequeue ?

informatics-dev commented 11 years ago

Comment by Edward Baker

Not for this case- but I guess there might be a case where you want to order a large number of nodes - or set weight on import. Does nodequeue allow for this?

informatics-dev commented 11 years ago

Comment by Alice Heaton

In general I would favor Node Queue: all types of problems to do with weighting, sorting, promoting, highlighting can be solved elegantly by using Node Queue.

It does add an extra layer of components: you need to create queues, and views that display those queues (though the latter can be generated automatically).

However it's much more versatile than Weight: by creating queues you solve the problem of ordering (as Weight does), but you also solve the problem of selecting a sub-set of nodes from a larger set (Which i realize is not the issue here, I'm thinking about how useful either module would be in the future). And you can have the same node in any number of queues, which is not possible with Weight.

Node Queue does provide an API so importing is not a problem.

I don't know how well Node Queue fares with large numbers of nodes - though I don't think that is the problem it is trying to solve. The problem it is trying to solve is about manually ordering/selecting nodes. As it is manual, it is generally a small number.

In what case would we want to order large number of nodes though ? It is unlikely large number of nodes would have been ordered manually - most likely this ordering would have been automatic. If it's automatic, then there must some algorithm that was initially used to create the ordering. I would think it's probably best to capture the information that leads to the order we want, rather than capture an arbitrary weight.

informatics-dev commented 11 years ago

Comment by Eli Sarnat

Will the weight module allow images to be weighted within a list? For example, in order to have the right images show up in the taxon overview page, I'm having to modify the species slideshow view to only display images from a particular gallery, then applying 'stick at top of lists' to a subset of those, but it's not perfect. If there were a way to assign weights to these images it would really be a lot easier and more effective.

informatics-dev commented 11 years ago

Comment by Ben Scott

I agree with Alice: node queue is a better mechanism for this than weight.

Eli, weighting could help a bit with the display of images on the taxon pages, but does have the drawback that the weight would affect everywhere that image is used throughout the site.

Instead, how about we add auto-generated node queues to the taxon pages? And for the home page image selection.

informatics-dev commented 11 years ago

Comment by Simon Rycroft

Can we defer the decision on this until Ben and I are back from Beijing. Whatever solution we go with will probably need to work with multiple entity types, and not just nodes.

informatics-dev commented 11 years ago

Comment by Eli Sarnat

No rush here.

informatics-dev commented 11 years ago

Comment by Simon Rycroft

In the end, the decision was made to go with the Weight module. The permissions have been set so that all Scratchpads 2.0 sites can now use it.

informatics-dev commented 11 years ago

Comment by Simon Rycroft

Assigning to Support Team so that they're aware of the changes.

informatics-dev commented 11 years ago

Comment by Laurence Livermore

There is some documentation (http://help.scratchpads.eu/w/Enabling_Weight_Settings_on_Content_Types) for the Weight settings which work as expected.