Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Linking to datastream fcr:metadata in HTML UI #573

Closed
wants to merge 2 commits into from

Conversation

escowles
Copy link
Contributor

@Produces({TEXT_HTML, APPLICATION_XHTML_XML})
public Response describeHTML(@HeaderParam("Range") final String rangeValue) throws IOException, ParseException {
// if no prefer header is set, include child resources so they can be used for conditional link building
if ( prefer == null ) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure it's a good idea to have the HTML response and the RDF responses divergent. If I was debugging an application, pulled a response up in my browser, and saw something, I would expected to see it other places too.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are we OK with making EMBED_CONTAINS the default behavior if no Prefer header is provided?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would say absolutely not. It has the potential to be a moderate performance hit.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If the goal is simply to indicate what things are non-binary sources, couldn't we intercept the click event, fire off a HEAD request, and see what we're getting back (and make some decision based on that)?

That would have the added benefit of working for properties that point to binaries too.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What is your take on this, @escowles ?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm 👍 for including that information everywhere it is relevant, but I don't think it's that easy. Non-binary resources can show up:

  • as contained resources of a node
  • as LDP member resources
  • as objects of reference properties

I spent time last week trying to do just that, and it means redoing a large part of our RDF serialization tools. I don't see how a simple javascript query is that hard to do.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this current PR fundamentally flawed? I would vote for moving it forward as-is.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@cbeer (aka, captain-JS) can I tempt you with a beer to make the magic happen?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, I argue it is flawed by either doing the wrong thing, not covering all the possible scenarios, or both.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@awoods
Copy link

awoods commented Oct 26, 2014

Resolved with: 5e6bb87

@awoods awoods closed this Oct 26, 2014
@awoods awoods deleted the link-to-ds-metadata branch October 26, 2014 13:40
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants