> > I think that we can get much of the same effect in a simpler way by using > the course scope for explicit default values stored under a different field > name or names (e.g. a course scoped field named "defaults"). That way, we > don't have to worry about weird inheritance interactions at all, or > wondering where the value of a certain field really came from.
I agree. I didn't say this explicitly, but I was assuming that we would use some sort of namespacing like that to avoid conflicts between different types of scopes. We wouldn't want confusion or any chance of unintentionally overriding field values. As a side note, one thing I want to be careful of in this discussion is the > "Tab" naming convention. > +1, which is why I do prefer "course_view" instead of "course_tab_view". Though it's worth pointing out as well that some people are interested in using XBlocks in contexts that are not courses, such as content libraries, XBlock SDK workbench scenarios, "microcourses", LTI consumers, blog posts, etc. But I know that these semantic questions are part of the reason we haven't had course-scoped fields yet, so I'm in favor of creating something simple for the main use case (courses) rather than trying to make something really generic and complex. -- Braden @OpenCraft <http://opencraft.com/> On Wed, Jul 6, 2016 at 9:21 AM, David Ormsbee <d...@edx.org> wrote: > On Thu, Jun 30, 2016 at 3:04 PM, Braden MacDonald <bra...@opencraft.com> > wrote: >> >> What I think would be much better would be if the LTI XBlock could just >> declare a course-scoped field called "lti_providers" which contains a list >> of LTI providers (name, URL, credentials). Then authors configure that >> once, and it gets applied to all LTI Consumer XBlocks in the course, with >> no duplication of data and no need to authors to enter things like the >> "URL" or "lti_id" every time they want to add another instance of an LTI >> tool in the course. >> > > Huge +1 for a course scope. The CourseModule is a dumping ground of all > kinds of settings info for different block types, just because there is no > other place to store that kind of information today. > > I also completely agree with your points about favoring a course view for > the data migration aspect. > > I think it would also be important to allow the default value of a normal >> usage-scope field to be inherited (default is the same for all blocks of >> that type in a course), but still overridable per usage. This would allow >> instructors to do things like say "All problems in this course should allow >> 5 attempts", but change that on a per-block basis as necessary. Currently, >> AFAIK, there is no way for instructors to change some setting like that for >> all blocks in a course. >> > > I'd shy away from having content and usage scoped fields arbitrarily > inherit from course scoped ones. While it's a powerful idea, I think that > there's potential for confusion there, particularly when interacting with > fields that are inherited from parent to child already. Right now, if you > set "max_attempts" to 5 on the root course module by editing the XML, it > will inherit down into all of the leaves. Allowing arbitrary overrides > might mean that a Capa problem gets a max_attempts attribute set on it > because it was inherited down from a sequence that had a course-scoped > field of the same name. It also adds complexity because for the first time, > we'd have the same field name mapping to multiple scopes. > > I think that we can get much of the same effect in a simpler way by using > the course scope for explicit default values stored under a different field > name or names (e.g. a course scoped field named "defaults"). That way, we > don't have to worry about weird inheritance interactions at all, or > wondering where the value of a certain field really came from. > > All that being said, I really feel like grading policy stuff should be in > its own API (say a runtime service), just because it would help us with > more dynamic content. But that's another big discussion, and probably not > something we're going to get around to for a while. > > As a side note, one thing I want to be careful of in this discussion is > the "Tab" naming convention. Tabs are a UI implementation detail, and they > don't necessarily carry over to things like Mobile. When we talk about > tabs, we're talking about a number of logically different things: the root > of the courseware DAG, things that are still course content but aren't > necessarily under the root, course level block views that don't directly > tie to def/usage scoped fields, admin functionality like the instructor > dashboard, etc. It would be good if we could refine our vocabulary for > these concepts, and not constrain ourselves to a UX decision made during > the prototype days of 2012. > > Take care. > > Dave > > -- > You received this message because you are subscribed to the Google Groups > "General Open edX discussion" group. > To view this discussion on the web visit > https://groups.google.com/d/msgid/edx-code/CAO_oFPyeCRUCjL%2BjC3AcjUaD_sMR245TcDt%2Bjot0eDyBsTgy0w%40mail.gmail.com > <https://groups.google.com/d/msgid/edx-code/CAO_oFPyeCRUCjL%2BjC3AcjUaD_sMR245TcDt%2Bjot0eDyBsTgy0w%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > -- You received this message because you are subscribed to the Google Groups "General Open edX discussion" group. To view this discussion on the web visit https://groups.google.com/d/msgid/edx-code/CAEyJbEZHnjd%2BREEc29%3Dr39SR8A9AND5XUsCiNUZ5%2BetjGrGTVg%40mail.gmail.com.
