Editing Talk:API:EPrints (section)

==== $dataobj->render ====

* ($xhtml, $title, $head_elements) = $dataobj->render; is ugly in      the way it returns the result
** CJG: I vote to make a new function with a better name & return values
** Can't just change what it returns as it's an   established library function
** CJG: Not sure what to name it to. render_page?
*** This would be confusing as it's not related to  the xhtml page function.
**** maybe render_page_parts?
*** CJG: Either way should return a hash or a ( body=>...., title=>...., head=>.... )
** TDB: Should this be:
$xhtml = $dataobj->render_head_elements;
$xhtml = $dataobj->render_title;
$xhtml = $dataobj->render_body;
*** CJG: That sounds sane, but the current eprint_render.pl function returns all 3 in one go! We could split it up in 3.2 default config, but make it also work with plain old eprints_render.pl -- actually, it feels like $c->{eprint_render} should become a hashref:
 $c->{eprint_render}->{body} $c->{eprint_render}->{title} etc... nice and extendable!
*** Seb: $parts = $dataobj->render_parts? $parts->{head} $parts->{title}  $parts->{body} I'd rather use a hash ref than a hash.... I'm not sure how perl handles returned values, but if done via the stack, it makes more sense to send back a ref (cf in C -> "object *").
**** CJG: The stack isn't significant in a high level function like this, only in lower ones like make_element. So % or \% is style, rather than opimisation.
*** Ben W: Thinking about the way that pages are built though, I'm not sure I want to get all those things at once, and function that return multiple things usually end up being a pain to remember or extend. How about this?
 # Build the <head> section
 $dataobj1->render_head;
 $dataobj2->render_head;
 
 # Build the rest of it
 $dataobj1->render_body;
 $dataobj2->render_body;
*** TDB: We currently have a half-replacement of eprint-render with a citation. I would rather have the 3.2 default to be XML that calls eprint_render. We can then add XML templates for "title" and "head" which also call eprint_render. (And just take the hit on the occasional triple call). The goal should be to remove Perl from the eprint page rendering - in future we'll have plugins that will poke bits into that page.