>
> If an XBlock requires some configuration in "course_view", config data
> will be stored as course-scoped fields (new feature); UI to set them up
> will be shown in Studio on "Pages" UI (???). This will likely require
> secondary "studio_course_view" (similar to existing studio_view)
As a long term goal, I think it'd make sense for most of those
course-scoped settings to be marked for inclusion in an auto-generated
editor UI (just as XModule usage fields are today, or XBlock fields with
StudioEditableXBlockMixin), and then we could replace the existing Studio
"Advanced Settings" page with a new UI that iterates over all enabled block
types and displays an editor for their scope-scoped fields (at least the
ones that also have User scope NONE).
The only concern I have about this implementation is that jquery.xblock
> dependent solution won't be able to use such course_views, as there are no
> actual XBlock created - we'll have to adapt jquery.xblock and/or APIs that
> back it up on edx-platform side.
That's a good point. We need to figure out what URL would represent the
request "Hey LMS, please render the *course_view* of XBlock type
*discussion* in course *CourseID* and return the result as JSON". The most
analogous current URL is the render-xblock-usage-as-JSON URL, which is
"courses/{course_key}/xblock/{usage_key}/view/{optional_view_name}". So
the question is if that view should have a UsageKey (almost definitely not,
though conceivably we could have a usage key with a standard block ID like
"course"). I think a reasonable option would be to use a BlockTypeKey, so
the URL to get the course_view as JSON would be
"courses/{course_key}/xblock/{block_type_key}/view/{view_name}", e.g.
"courses/course-v1:org+course+run/xblock/block-type-v1:xblock.v1:discussion/view/course_view".
I think the other option is a new type of Opaque Key that contains a course
ID and a block type but no ID - however I don't want to contribute to the
proliferation of key types if we don't have to.
Since the return value of that API would presumably be identical, I hope it
wouldn't be too hard to adapt jquery.xblock to be compatible.
--
Braden
@OpenCraft <http://opencraft.com/>
On Tue, Jul 12, 2016 at 5:16 AM, <eug...@opencraft.com> wrote:
> Ok, the discussion is kind of stopped here, so I'm going to sum up main
> points:
>
> - Looks like "course_view" + course-scoped fields provide more value
> in general, while my initial suggestion is tailored to single use case,
> seems simpler to implement, but maybe slightly harder to maintain.
> - Since discussions (my primary use case) are going to be rewritten
> soon it seems to make more sense to follow "course_view" approach.
> - Additional benefit is that "course_view" are relatively orthogonal
> to discussion rewrite, so we won't step on each other toes implementing
> them in parallel.
>
> So, suggested implementation is as follows (Braden and David, correct me
> if I'm wrong):
>
> - XBlocks will provide special "course_view".
> - LMS and Studio will use that view to render XBlock content as
> "course tab" page.
> - XBlocks providing course_view will be automatically displayed as tab
> when they are enabled in Advanced Settings - it won't require course
> authors to actually add an instance somewhere. However, they will be
> displayed in "Pages" UI, and allow hiding the tab.
> - If an XBlock requires some configuration in "course_view", config
> data will be stored as course-scoped fields (new feature); UI to set them
> up will be shown in Studio on "Pages" UI (???). This will likely require
> secondary "studio_course_view" (similar to existing studio_view)
>
> The only concern I have about this implementation is that jquery.xblock
> dependent solution won't be able to use such course_views, as there are no
> actual XBlock created - we'll have to adapt jquery.xblock and/or APIs that
> back it up on edx-platform side.
>
> Regards,
> Eugeny
> @Opencraft <http://opencraft.com>
>
> On Wednesday, July 6, 2016 at 7:47:06 PM UTC+3, Braden MacDonald wrote:
>>
>> 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 <da...@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/633dbbae-4ffc-4fb2-a2d5-04fc4c07e627%40googlegroups.com
> <https://groups.google.com/d/msgid/edx-code/633dbbae-4ffc-4fb2-a2d5-04fc4c07e627%40googlegroups.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/CAEyJbEbOBU26GuvxGnfMP%2BkTfY%3DDwEU_e9e6fVbgp3nGDX2FxQ%40mail.gmail.com.
