[Koha-devel] Sorting alphabetically the subfields in additem

[Salvador Zaragoza Rubio]

What I see in the version downloaded from the git current development
branch is that the fields and subfields are
stored in hash data structures so they are randomly accessed if you
don't sort them with some method, just what's
been done recently:

.
.
.
380: foreach my $tag (sort keys %{$tagslib}) {
381: # loop through each subfield
381:   foreach my $subfield (sort keys %{$tagslib->{$tag}}) {
.
.
.

After processing them, the data is stored in an array so they are showed
sorted afterwards:
555: push (@loop_data, \%subfield_data);

In this implementation the subfields are passed (lexically sorted) to
the template for displaying purposes.
So I think is fixed.
Anyway I'll look into the database solution.




El 19/08/2010 12:13, MJ Ray escribió:
> Salvador Zaragoza Rubio <salvazm at masmedios.com>
>   
>> Maybe the right thing to do instead of changing code everyone would
>> be for the koha developers to add a subfield in the marc structure
>> indicating the order you want to display the subfields.  It would
>> imply adding a field in the database and change code to sort through
>> this field. I think this would be the perfect solution as everyone
>> could order in the desired manner as Michael Hafen did.
>>     
> Plesae can someone more familiar with cataloguing look at additem.pl (or
> answer from memory) and say why the fields are ordered as they are?
>
> I didn't see how the subfields are "in a random manner", but there are
> a couple of random numbers generated by sub generate_subfield_form.
>
> The current ordering might be random, accidental or it might have some
> reason (performance, or even a dangerous undeclared dependency) that
> the reordering may impact.  Anyone know for sure?
>
> Thanks,
>   



-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5527 bytes
Desc: S/MIME Cryptographic Signature
URL: </pipermail/koha-devel/attachments/20100819/8cc8b068/attachment.bin>