Bug #5282

EAC, EAD, DC, SKOS not defaulting to XML, and generated links rely on sf_format=xml

Added by Mike Gale almost 9 years ago. Updated almost 9 years ago.

Status:VerifiedStart date:06/25/2013
Priority:MediumDue date:
Assignee:Mike Gale% Done:

0%

Category:Import/ExportEstimated time:4.00 hours
Target version:Release 1.4.0
Google Code Legacy ID: Tested version:
Sponsored:No Requires documentation:

Description

Steps to reprodue

  1. View an authority record
  2. Click the "Export > EAC" link

Current behaviour
the links generate ?sf_format=xml on the end of them. If the ?sf_format=xml is not specified the user is shown an error page.

Desired behaviour
The link should be generated without the "?sf_format=xml" attribute e.g. http://atom.example.com/john-doe;eac

Specifying that XML should be used is unnecessary as this is the only way that AtoM can represent EAC data. For backwards compatiblity, "sf_format=xml" attribute should still be supported if specified.

EAC_sf.png - EAC export URL (53.3 KB) Dan Gillean, 07/04/2013 01:49 PM

SKOS_sf.png - SKOS export URL (49.4 KB) Dan Gillean, 07/04/2013 01:49 PM

History

#1 Updated by David Juhasz almost 9 years ago

  • Description updated (diff)

#2 Updated by Mike Gale almost 9 years ago

  • Status changed from New to In progress

#3 Updated by Mike Gale almost 9 years ago

<Sevein> default's sf output is a php template (when sf_format is not explicitly assigned in the url)
<Sevein> so if the controller is indexAction.class.php
<Sevein> it will try to load indexSuccess.php under templates/
<Sevein> as that option doesn't exist in that case, you could force the format within the template
<Sevein> the sfRequest object (passed to the execute method) has a method to set it
<Sevein> $request->setRequestFormat('xml');
<Sevein> that should do the trick
<Sevein> https://github.com/artefactual/atom/blob/1.x/apps/qubit/config/routing.yml#L50
<Sevein> ^ add sf_format: xml under the param section

#4 Updated by Jesús García Crespo almost 9 years ago

This is probably affecting to other modules in the application where XML is the only format available.

#5 Updated by Mike Gale almost 9 years ago

  • Subject changed from EAC not defaulting to XML, and generated links rely on sf_format=xml to EAC, EAD, DC, SKOS not defaulting to XML, and generated links rely on sf_format=xml

#6 Updated by Mike Gale almost 9 years ago

I looked around for the source of this issue for SKOS, which seems to be different. I think Jesús will know where it can be fixed so I'll talk to him about it tomorrow.

#7 Updated by Jesús García Crespo almost 9 years ago

  • Status changed from In progress to QA/Review

#8 Updated by Jesús García Crespo almost 9 years ago

  • Category set to Import/Export
  • Target version set to Release 1.4.0

#9 Updated by Dan Gillean almost 9 years ago

Default behaviour is still to include ?sf_format=xml at the end of the listed exports. Note that grabbing the URL without the added ?sf... afterwards, and then opening it in a different tab, will take a user directly to the export for SKOS - but in the case of DC, for example, without the addition of the ?sf suffix, the URL is the same as the display record - so the user is not directed to the XML but to the showscreen for the record. This is apparently because ;dc is used for both the edit template, and the export format - so there is no way to differentiate the two. Presumably the problem would be the same for MODS export vs. MODS edit template.

#10 Updated by Jesús García Crespo almost 9 years ago

  • Status changed from Feedback to QA/Review

Dan, I've fixed these two links to exports in EAC and SKOS in commit:c195a3ce05a1fdc7481dbf48d9b11759a843fd22.
Also, commit:c0b6ec6 fixes the problem in DC. MODS is ok.

#11 Updated by Jesús García Crespo almost 9 years ago

  • Estimated time set to 4.00

#12 Updated by Dan Gillean almost 9 years ago

  • Status changed from QA/Review to Feedback

1) SKOS seems to work but I wanted to verify the behaviour: here is a sample output: http://YOUR ATOM/~USER/index.php/new-westminster;sfSkosPlugin <--- is this the expected outcome? Looks fine to me, though it would preferable if it simply said ";skos" I think.

2) Attempts to export Dublin Core still produces ?sf_format=xml

3) Attempts to export EAC produces a 500 internal server error if it is NOT in qubit_dev mode (ie "/index.php/"). If dev mode is used, the export works as expected.

#13 Updated by David Juhasz almost 9 years ago

Dan Gillean wrote:

3) Attempts to export EAC produces a 500 internal server error if it is NOT in qubit_dev mode (ie "/index.php/"). If dev mode is used, the export works as expected.

Usually, when you experience an error when dev mode is off, but the error doesn't occur when dev mode is on, it means you have old data in your symfony cache. Do clear cache and try again, this will usually fix the problem.

#14 Updated by Dan Gillean almost 9 years ago

Okay, tested again and the EAC issue works fine. However, questions remain regarding DC and SKOS. David, can you comment on 1) in comment 12 above, re: expected output for SKOS?

#15 Updated by Jesús García Crespo almost 9 years ago

  • Status changed from Feedback to QA/Review

Dan, I've done the fix with ;skos as you suggested.
DC export needs ?sf_format=xml, sorry I can't change that easily.

We could change our routes to something like: /foobar and /foobar.xml but that would require a bigger overhaul.

#16 Updated by David Juhasz almost 9 years ago

Thanks Jesús. I think keeping the sf_format=xml for DC is acceptable due to the amount of work required to change it.

#17 Updated by Dan Gillean almost 9 years ago

  • Status changed from QA/Review to Verified

Also available in: Atom PDF