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

fragmentURI methods for working with single page apps #2

Closed
wants to merge 1 commit into
from

Conversation

Projects
None yet
3 participants
@mark-rushakoff
Contributor

mark-rushakoff commented Dec 28, 2011

This library looks really good except for the fact that it didn't offer much utility in working with single page applications (e.g. using Backbone Router or Sammy.js). You can work around this by extracting the fragment from the URI, making a new URI from that, modifying it, and plugging it back into the fragment of the original URI; or you could use the helper methods I added in this pull request.

Tests are included, but documentation isn't. If the code meets your standards, I will be happy to update the pull request with changes to the documentation files as well.

@rodneyrehm

This comment has been minimized.

Show comment
Hide comment
@rodneyrehm

rodneyrehm Dec 28, 2011

Member

I already have more requests lined up for fragment-abuse. Thank you for your input!

I currently have requests for three "competing" fragment-abuse "standards":

Google's abuse starts with #!, Fragment-Parameters start with #?, Backbone Routing has no simple identification I can see at the moment.

Are there any other "standards" URI.js should handle in one way or another?

Member

rodneyrehm commented Dec 28, 2011

I already have more requests lined up for fragment-abuse. Thank you for your input!

I currently have requests for three "competing" fragment-abuse "standards":

Google's abuse starts with #!, Fragment-Parameters start with #?, Backbone Routing has no simple identification I can see at the moment.

Are there any other "standards" URI.js should handle in one way or another?

@mark-rushakoff

This comment has been minimized.

Show comment
Hide comment
@mark-rushakoff

mark-rushakoff Dec 28, 2011

Contributor

I've only used Backbone for this situation -- Backbone is nice because it doesn't force you into any convention other than having a leading #. As far as I can tell, Sammy.js does the same.

I didn't cover having only fragment-parameters in my tests. I'm not sure whether that would work correctly without some changes. But I doubt that the presence of a ! would be restored correctly in a reassemble... so maybe fragmentURI should take an optional parameter specifying a prefix?

Contributor

mark-rushakoff commented Dec 28, 2011

I've only used Backbone for this situation -- Backbone is nice because it doesn't force you into any convention other than having a leading #. As far as I can tell, Sammy.js does the same.

I didn't cover having only fragment-parameters in my tests. I'm not sure whether that would work correctly without some changes. But I doubt that the presence of a ! would be restored correctly in a reassemble... so maybe fragmentURI should take an optional parameter specifying a prefix?

@rodneyrehm

This comment has been minimized.

Show comment
Hide comment
@rodneyrehm

rodneyrehm Dec 28, 2011

Member

I'm still uncertain how to handle this. Looking at your patch, It's nothing that can be done from the outside (for the time being). I'd like to think about fragment-abusal some more… (if anyone has any opinions on the matter, please chime in!)

Member

rodneyrehm commented Dec 28, 2011

I'm still uncertain how to handle this. Looking at your patch, It's nothing that can be done from the outside (for the time being). I'd like to think about fragment-abusal some more… (if anyone has any opinions on the matter, please chime in!)

@marcalj

This comment has been minimized.

Show comment
Hide comment
@marcalj

marcalj Dec 29, 2011

Mmm, probably a deparam function foo=bar&hola=adeu --> {foo: 'bar', hola: 'adeu'}. :)

In "search" or hash zone will apply...

marcalj commented Dec 29, 2011

Mmm, probably a deparam function foo=bar&hola=adeu --> {foo: 'bar', hola: 'adeu'}. :)

In "search" or hash zone will apply...

@rodneyrehm

This comment has been minimized.

Show comment
Hide comment
@rodneyrehm

rodneyrehm Dec 29, 2011

Member

I was actually thinking about fragment-abuse not being a standardized thing. Anyone could do anything with the fragment. Storing data, other URLs, counting kittens…
The "deparam" you're talking about is URI.parseQuery() - it would be a matter of minutes having fragment use that. But the point is, .addQuery() and .removeQuery() are first level citizens mutating the query string. We would have to add addFragmentQuery() and removeFragmentQuery() to allow the same for fragments. API explosion up ahead…

Member

rodneyrehm commented Dec 29, 2011

I was actually thinking about fragment-abuse not being a standardized thing. Anyone could do anything with the fragment. Storing data, other URLs, counting kittens…
The "deparam" you're talking about is URI.parseQuery() - it would be a matter of minutes having fragment use that. But the point is, .addQuery() and .removeQuery() are first level citizens mutating the query string. We would have to add addFragmentQuery() and removeFragmentQuery() to allow the same for fragments. API explosion up ahead…

@marcalj

This comment has been minimized.

Show comment
Hide comment
@marcalj

marcalj Dec 29, 2011

Oh, thanks :)
Good question... and something like: addQuery(data, 'fragment'); ?

marcalj commented Dec 29, 2011

Oh, thanks :)
Good question... and something like: addQuery(data, 'fragment'); ?

@rodneyrehm

This comment has been minimized.

Show comment
Hide comment
@rodneyrehm

rodneyrehm Dec 29, 2011

Member

addQuery(string_name, string_value, boolean_doNotBuild) and addQuery(object_data, boolean_doNotBuild) are the current signatures. this is getting messy :(

Member

rodneyrehm commented Dec 29, 2011

addQuery(string_name, string_value, boolean_doNotBuild) and addQuery(object_data, boolean_doNotBuild) are the current signatures. this is getting messy :(

@rodneyrehm

This comment has been minimized.

Show comment
Hide comment
@rodneyrehm

rodneyrehm Dec 30, 2011

Member

I've come to the conclusion, that fragment abuse is done in too many different ways. I don't see a singular API for the matter. I'm not going to push any fragment abuse into the "core" (unless it was "standardized" somewhere).

That said, I've added src/URI.fragmentURI.js and src/URI.fragmentQuery.js to demonstrate the process of enabling URI.js to do what you expect it to. I'll have to write some more doc on the matter, though.

This way anyone can do their own custom hash thingy… agree?

Member

rodneyrehm commented Dec 30, 2011

I've come to the conclusion, that fragment abuse is done in too many different ways. I don't see a singular API for the matter. I'm not going to push any fragment abuse into the "core" (unless it was "standardized" somewhere).

That said, I've added src/URI.fragmentURI.js and src/URI.fragmentQuery.js to demonstrate the process of enabling URI.js to do what you expect it to. I'll have to write some more doc on the matter, though.

This way anyone can do their own custom hash thingy… agree?

@mark-rushakoff

This comment has been minimized.

Show comment
Hide comment
@mark-rushakoff

mark-rushakoff Dec 30, 2011

Contributor

@rodneyrehm Offering an example of "here's one way you could handle fragment URIs" seems like a very reasonable compromise IMO. It directly addresses the two-part problem of "there's no standard way to handle fragment URIs" and "there wasn't an obvious place to extend URI.js to handle your own fragment URIs." It gets my vote of approval!

Contributor

mark-rushakoff commented Dec 30, 2011

@rodneyrehm Offering an example of "here's one way you could handle fragment URIs" seems like a very reasonable compromise IMO. It directly addresses the two-part problem of "there's no standard way to handle fragment URIs" and "there wasn't an obvious place to extend URI.js to handle your own fragment URIs." It gets my vote of approval!

@rodneyrehm

This comment has been minimized.

Show comment
Hide comment
@rodneyrehm

rodneyrehm Dec 30, 2011

Member

awesome… If you have some words to share for the docs please do so. :)

Member

rodneyrehm commented Dec 30, 2011

awesome… If you have some words to share for the docs please do so. :)

@rodneyrehm rodneyrehm closed this Dec 30, 2011

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment