EPrints Technical Mailing List Archive

See the EPrints wiki for instructions on how to join this mailing list and related information.

Message: #06670


< Previous (by date) | Next (by date) > | < Previous (in thread) | Next (in thread) > | Messages - Most Recent First | Threads - Most Recent First

[EP-tech] Changes to EPrints


I left this list a long time ago, but I see the issue of the open source status has been raised, as was inevitable.


EPrints is still listed as a GNU package <https://directory.fsf.org/wiki/EPrints>. Getting my software officially on the FSF list was an achievement I remain deeply proud of. Unusually, the Free Software Foundation agreed to allow the copyright to remain with University of Southampton as they could be trusted to defend the free & open nature of the software. Any changes to the free and open nature of EPrints, the software I put years of my life into, have been made without any discussion with, or blessing from, me.





In other news, I've been working on our local EPrints repository for the first time in many years and have come up with a couple of features, and a fix, that may be useful to others.


1.
Debugging EPC files. Add this to a config.d/ file,

use Data::Dumper;
sub EPrints::Script::Compiled::run_dumper
{
        my( $self, $state, $data ) = @_;

        my $pre = $state->{session}->make_element( "pre" );
$pre->appendChild( $state->{session}->make_text( "TYPE: ".$data->[1]."\nVALUE: ".Dumper( $data->[0] ) ) );
        return [ $pre , "XHTML" ];
};

and then you can use

<epc:print expr="dumper(creators)" /> to look at the type and structure of a variable in an EPC file. It's a bit hokey, but handy when doing more complex staff.


2.
EPScript again; Subproperty() method. This code adds a method to the EPScript which lets you get at a single value from a compound field. Use in conjunction with <epc:foreach> over a multiple compound field. The type of the resulting value is of the subtype so the default rendering will be used making life much easier. In retrospect this is an obvious and missing feature that should have been added when I created EPScript in the first palce.

eg. Soton has a compound multiple dates field.

    <epc:foreach expr="$item{dates}" iterator="date">
<div class='uos-eprints-dv'><span class='uos-eprints-dv-label'><epc:print expr="$date.subproperty('date_type')" /> date:</span> <epc:print expr="$date.subproperty('date')" /></div>
    </epc:foreach>

Code:
sub EPrints::Script::Compiled::run_subproperty
{
        my( $self, $state, $objvar, $value ) = @_;

        if( !defined $objvar->[0] )
        {
$self->runtime_error( "can't get a property {".$value->[0]."} from undefined value" );
        }
        my $ref = ref($objvar->[1]);

if( $ref !~ m/::/ || ! $objvar->[1]->isa( "EPrints::MetaField::Compound" ) )
        {
$self->runtime_error( "can't get a subproperty from anything except a compound field value, when trying to get ".$value->[0]." from a $ref" );
        }
        my $field = $objvar->[1];
        if( $field->get_property( "multiple" ) )
        {
$self->runtime_error( "can't get a subproperty from a multiple field." );
        }

        my $fc = $field->get_property( "fields_cache" );
        my $sub_field;
        my @ok = ();
        foreach my $a_sub_field ( @{$fc} )
        {
                push @ok, $a_sub_field->{sub_name};
                if( $a_sub_field->{sub_name} eq $value->[0] )
                {
                        $sub_field = $a_sub_field;
                }
        }
        if( !defined $sub_field ) {
$self->runtime_error( "unknown sub-field of a compound: ".$value->[0].". OK values: ".join( ", ", @ok )."." );
        }
        $sub_field->set_property( "multiple", 0 );

        return [
                $objvar->[0]->{ $value->[0] },
                $sub_field ];
};


3.
Subroutine redefined warning messages. These appear to be part and parcel of some EPrints plugins and are annoying. Code shouldn't ship with "just ignore the warnings". If you are intentionally overriding a method in Perl you can remove the existing one first to get rid of a needless warning.
eg. if you need to override
sub EPrints::Badgers::render  {
 #stuff
}
you can place this before hand:
BEGIN { delete $EPrints::Badgers::{render}; }
to remove the default subroutine, then you'll not get those annoying warnings.


--
Christopher Gutteridge -- http://users.ecs.soton.ac.uk/cjg

University of Southampton Open Data Service: http://data.southampton.ac.uk/
You should read our Web & Data Innovation blog: http://blogs.ecs.soton.ac.uk/webteam/