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

Unique Id for Block #218

Open
cpennington opened this issue May 29, 2014 · 4 comments
Open

Unique Id for Block #218

cpennington opened this issue May 29, 2014 · 4 comments

Comments

@cpennington
Copy link
Contributor

Reported by @pmitros: "To construct useful XBlocks, I need access to a unique ID per element. Cale mentioned this is available in self.scope_ids.usage_id. This is good and useful, but entirely undocumented."

@nedbat: "Yes, let's add this to the list of useful factoids that can be retrieved from the information service, along with student name, course name, etc."

@cpennington
Copy link
Contributor Author

I'm not sure it makes sense to have general "information service". I'd rather be more specific/selective, and have services for info about the course, about the current user, and perhaps about the block. Although, simply exposing self.scope_ids.usage_id (or a function of that) as a known unique id (without getting a service involved) seems reasonable to me as well. In particular, the fact that that id is unique is a property of the general XBlock structure, rather than optional functionality that only some runtimes might provide.

@pmitros
Copy link
Contributor

pmitros commented May 29, 2014

I'd tend to agree with cpennington. This feels core. I'd rather have this available in the XBlock than in an external service. It's not really clear how to write a lot of the client-side code clearly, in particular, without having unique IDs if there are multiple of the same type of XBlock on the same page.

My personal preference would be towards something like self.usage or self.id. This would
(1) be concise and readable to use
(2) developers learning the framework could find it through introspection (.dict), rather than introspection on class members or looking for services
(3) we wouldn't be exposing the scope_ids data structure
(4) it could easilt be exposed in the string representation of the XBlock on the console when printing it, for debugging.

@taniwallach
Copy link

This issue is quite old, but in case someone finds it, the Fields API allows initializing a field with default = xblock.fields.UNIQUE_ID which sets a "scope" suitable UID.

See:

@cpennington, @pmitros - I assume that due to code from https://github.com/edx/XBlock/pull/249 this issue should be closed.

@pmitros
Copy link
Contributor

pmitros commented Jun 7, 2021

@taniwallach I believe @cpennington is now at Reify Health (and sports an awesome beard). I'm also no longer actively involved in Open edX development (and don't appear to have commit access anymore).

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

No branches or pull requests

3 participants