> > I would love to hear more about course-scope fields.
A great example of the need for this is the LTI Consumer XBlock. Instructors need a way to configure the available LTI tools that should be embeddable in their course. For each tool, instructors want to enter the URL* and authentication credentials only once. Currently, the URL must be entered separately on each LTI Consumer XBlock, and the credentials are entered once via "advanced settings" in Studio and stored on a field of the course XModule <https://github.com/edx/edx-platform/blob/1798b1f1bc8/common/lib/xmodule/xmodule/course_module.py#L170> (which creates a weird coupling between the "Course" XModule and the LTI Consumer XBlock). 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. For a discussion XBlock, a course-scoped field could be "allow voting" which enables/disables the upvoting/downvoting feature on a per-course basis. There are a couple ways to implement course-scoped fields. One would be a new type of BlockScope <http://edx.readthedocs.io/projects/xblock/en/latest/fields.html#xblock.fields.BlockScope>, called CONTEXT or COURSE or something, halfway between USAGE and TYPE scopes. Then XBlocks can define fields that can be set at a course level, and could also save/load data at a course level ("your score is 3 compared to the current course average of 2"). 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. > what benefits course_view + course-scope fields have over XBlockTab + > course_view? I think: - course_view would generally result in a system where "things just work" for instructors - new tools/reports/components appear at the course level automatically when needed, compared to the other system where instructors need to explicitly add XBlockTabs - course_view would have a simpler UI - just need a way to toggle the course_view on/off for each XBlock type, compared to a UI for building out tabs as pages (though maybe for vertical/html tabs, that would still be necessary to implement; also, implementing a UI for course-scoped fields could be a lot of work) - I suspect upgrading, import, and export would be simpler with the course_view approach, compared to embedding blocks in the course structure. - There would be no need to run a one-time management command to, say, convert all discussion tab references to DiscussionForumTabXBlock usages. - I think it's important the courses from older versions of edX could be imported into newer ones, and if you've (for example) converted the discussion tab to be a discussion XBlock that gets stored into the course XBlock DAG somewhere, then you need some substantial import code to check when importing an older course, and create the new DiscussionForumTab XBlock as needed. With the course_view approach, you wouldn't necessarily have to do anything on import, and you'd just ignore mentions of "discussion" in the course tabs list. ** Depending on the tool, sometimes the URL changes for each particular component you want to embed, in which case it would be only the "base URL" that would be the same per unit.* -- Braden @OpenCraft <http://opencraft.com/> On Thu, Jun 30, 2016 at 2:11 AM, <[email protected]> wrote: > Hi all! > > I don't think it makes sense to add CAPA problems, drag and drop, etc. so >> those wouldn't be on the default list of blocks to add to a tab. > > > I've added a list of potential use cases for the feature to > https://openedx.atlassian.net/browse/TNL-2319 - one of the ideas I had is > to provide sandbox for complex problem types, like circuit/chem/protein > builder. So, authors *might *actually want adding CAPA problems from > "Advanced" list. But that's just my opinion, I don't have any significant > proofs. On the other hand I agree that it does not make any sense to add > simpler CAPA problems to a tab. > > One option is having a "tabs" type XBlock (much like the "course" XModule >> or the "chapter" XModule), and every child of it would be a separate tab in >> the courseware. > > > That's an option too. My initial idea was to still use "tabs" field in > "course"; each record in that field would point to a "course_tab" block, > and that block would have one or many child blocks. Roughly like that: > > course (CourseDescriptor) >> | >> + chapter >> | | >> | + sequential >> | | >> | + vertical >> | | >> | + html >> | + problem >> | >> + chapter ... >> + course_tab >> | | >> | + html (Forum instructions, docs, etc.) >> | + discussion_forum (XBlock implementing the Forum) > > | > > + course_tab >> | >> + html (XModule/XBlock representing the "Info" tab) > > > > That makes sense, but only if we also implement course-scope fields at the >> same time. > > > I would love to hear more about course-scope fields. Also, what benefits > course_view + course-scope fields have over XBlockTab + course_view? (Note: > looks like "course_view" is exactly the same as "course_tab_view" I used > earlier. IMO "course_tab_view" is a slightly better name, but I'll stick to > the terminology used by others for now). > > Regards, > Eugeny > @Opencraft <http://opencraft.com> > > On Thursday, June 30, 2016 at 8:11:50 AM UTC+3, Braden MacDonald wrote: > >> Adding my $0.02: >> >> Another approach that we've talked about in the past around this same >>> problem is that rather than having a specific tab type for housing an >>> XBlock, we'd allow XBlocks to expose a course_view, which the XBlock could >>> use to render any course-level content (perhaps configuration details, >>> perhaps something like the Discussions tab, perhaps other uses). Those tabs >>> could be rendered for any XBlock type that appeared in the course. >> >> >> That makes sense, but only if we also implement course-scope fields at >> the same time. (Which is something I really want to see). >> >> Would it be expensive to determine the set of XBlock types that appears >> in a course? >> >> Also, one downside of this is that it doesn't support the use case where >> an author might want to add a particular XBlock as a tab (e.g. a >> course-wide forum) but not add it to the course content (e.g. no inline >> discussions). Though one way around that would be to have a course advanced >> setting for "additional tab types", which is a list of XBlock types to >> render as tabs even though they're absent from the courseware. >> >> >>> adding a discussion block to this custom tab wouldn't work by default, >>> as it would render an inline discussion. The block would have to know that >>> it was being rendered 'outside the course', or it would need an advanced >>> setting, or there would need to be a different class of discussion block. >>> The last two options seem to me that they would be confusing for the author. >> >> >> I'm not advocating for this, but: *If *it were a different class of >> discussion XBlock (which we did for the solutions fork), I don't think that >> would be confusing because I think it would make sense to have a different >> list of XBlock templates presented to an author who clicks "Add component" >> to add a new XBlock to a tab context. e.g. I don't think it makes sense to >> add CAPA problems, drag and drop, etc. so those wouldn't be on the default >> list of blocks to add to a tab. Likewise, the inline discussion block >> wouldn't be an option to add to a tab, and the course-wide forum block >> wouldn't be an option to add to the course content. >> >> >> I've heard a few people ask about how this will look in the OLX. I think >> we also need to consider the related question of how it would look in the >> modulestore and the course DAG/tree. >> >> Currently, as far as I know, tabs are defined via a field called "tabs" >> on the root "course"-typed XModule: >> >> course (CourseDescriptor with various fields including "tabs") >>> | >>> + chapter >>> | | >>> | + sequential >>> | | >>> | + vertical >>> | | >>> | + html >>> | + problem >> >> >> If we use Cale's suggestion that "XBlocks to expose a course_view... >> Those tabs could be rendered for any XBlock type that appeared in the >> course", then we don't have to worry about much other than where to store >> course-scope fields, which is another topic (I think they should be >> attached to the root of the structure, i.e. the course). But if XBlocks can >> be arbitrarily added by authors as first-class tabs, then they'll need to >> be persisted to the modulestore and they'll more or less need to have a >> place in the course tree. One option is having a "tabs" type XBlock (much >> like the "course" XModule or the "chapter" XModule), and every child of it >> would be a separate tab in the courseware: >> >> course (CourseDescriptor) >>> | >>> + chapter >>> | | >>> | + sequential >>> | | >>> | + vertical >>> | | >>> | + html >>> | + problem >>> | >>> + chapter ... >>> + tabs >>> | >>> + html (XModule/XBlock representing the "Info" tab) >>> + discussion_forum (XBlock implementing the Forum) >> >> + vertical (Custom tab with custom title and potentially multiple >>> child XBlocks) >> >> >> Though I'm personally liking the "course_view" approach and course-scoped >> fields much more. >> >> >> -- >> Braden >> @OpenCraft <http://opencraft.com/> >> >> On Wed, Jun 29, 2016 at 2:36 AM, <[email protected]> wrote: >> >>> Per discussion on Slack architecture channel, OEP is not needed for this >>> kind of change. Instead an empty PR is sent: >>> https://github.com/edx/edx-platform/pull/12896 - it will eventually >>> contain implementation. >>> >>> This ML thread is mentioned on the PR, so I believe the discussion could >>> continue here, or move to PR, or just go in parallel in both places. >>> >>> Regards, >>> Eugeny >>> @Opencraft <http://opencraft.com> >>> >>> P.S. previous message is from me too - I accidentally posted it from my >>> personal email >>> >>> >>> On Wednesday, June 29, 2016 at 11:53:05 AM UTC+3, Колпаков Евгений wrote: >>>> >>>> Hi Andy, >>>> >>>> First of all, thank you for very thoughtful and detailed feedback! >>>> >>>> I think a good place to start would be to enumerate the different use >>>>> cases that this solution could help with. >>>> >>>> >>>> Makes sense, I'll try to list them on the >>>> https://openedx.atlassian.net/browse/TNL-2319 >>>> >>>> In general, having a custom tab that the author can add blocks to would >>>>> be very flexible, and much more powerful than the current static tab. In >>>>> fact, it might be better to replace the static tab with your new tab, >>>>> because it is straightforward for the author to add an HTML block to it, >>>>> and then they can easily extend it by adding videos or any other content >>>>> they might have. In some ways, it is as if they are adding a unit directly >>>>> as a tab, rather than within a section of the course. >>>>> >>>> >>>> Exactly! >>>> >>>> An important point to consider is that adding a discussion block to >>>>> this custom tab wouldn't work by default, as it would render an inline >>>>> discussion. The block would have to know that it was being rendered >>>>> 'outside the course', or it would need an advanced setting, or there would >>>>> need to be a different class of discussion block. The last two options >>>>> seem >>>>> to me that they would be confusing for the author. >>>> >>>> >>>> This problem is caused by the fact inline discussion and course >>>> discussion have quite different UI, dictated by different use cases. >>>> Solutions use two different discussion XBlocks (codenames DiscussionXBlock >>>> and DiscussionCourseXBlock) for inline and course discussions, and so far >>>> it worked for them - we can follow that approach, if all else fails. >>>> However, it looks like introducing "course_tab_view" I mentioned earlier >>>> would be able to solve the problem. In two words: XBlockTab will ask >>>> XBlocks to render "course_tab_view", and by default that view will just >>>> fallback to "student_view"; XBlocks that need to look different in a tab >>>> will override it. >>>> >>>> IMO for a feature like discussions it would be ideal to register that >>>>> it wants to automatically add a tab, rather than requiring the course >>>>> author to explicitly add a new XBlock. >>>> >>>> >>>> I'm not sure I fully understand this idea, so please correct me if I'm >>>> wrong. Is this about automatically adding a XBlock discussion tab to a >>>> course if discussion XBlock is installed into platform? I can see four >>>> issues with this approach: >>>> >>>> 1. Implicit action - it might be confusing to course authors to see >>>> new tab appearing out of the thin air. Also, to avoid having two >>>> discussion >>>> tabs we'll have to hide one - probably old discussion tab; in this case >>>> it >>>> might be not obvious what happened. >>>> 2. If I do recall right, XBlock is not supposed to import anything >>>> from platform, and base class for course tabs (CourseTab) lives in >>>> edx-platform. >>>> 3. No obvious update plan for existing courses - I wouldn't in life >>>> figured out that refreshing tab list can be achieved by updating >>>> "Advanced >>>> Module List". And it looks like it is the only way to make Discussion >>>> XBlock tab to appear in existing courses in this scenario, unless we go >>>> into trouble of creating a migration script/management command. >>>> 4. (Very minor) If generic XBlockTab is implemented (the one that >>>> allows adding any XBlock/XModule to a tab), having dedicated tab for >>>> discussion XBlock would be confusing. >>>> >>>> Generic XBlockTab + DiscussionXBlock have drawbacks too: >>>> >>>> 1. Authors must manually add it to a course - might not be a >>>> drawback at all. It requires a bit more interaction than current >>>> version, >>>> but (arguably) we could mimic current behavior by always adding >>>> XBlockTab + >>>> discussion XBlock when course is created. >>>> 2. Upgrade for existing courses is slightly less trivial - there >>>> are two options: either allow authors to opt-in for new mechanism and >>>> let >>>> them manually migrate courses, or automatically migrate everything with >>>> management command (but this options have the drawback of being >>>> non-obvious >>>> to course authors) >>>> 3. DiscussionXBlock needs to be updated to know it is in the tab - >>>> this could be done using "course_tab_view" >>>> >>>> So, IMO, XBlockTab + DiscussionXBlock would be a more elegant solution; >>>> it might require a bit more work from course authors (unless we take care >>>> of them by autocreating tab+XBlock), but also will provide them some >>>> flexibility (i.e. slap an HTML block with instructions on top of course >>>> discussion). >>>> >>>> Again, this is all a very valuable ideas, thank you or sharing! >>>> >>>> Regards, >>>> Eugeny >>>> @Opencraft <http://opencraft.com> >>>> >>>> среда, 29 июня 2016 г., 0:14:36 UTC+3 пользователь Andy Armstrong >>>> написал: >>>>> >>>>> Hi Eugeny, >>>>> >>>>> This is a much requested feature, so thanks for sending out the >>>>> proposal. FYI, there's a pre-existing ticket that I created a while back >>>>> in >>>>> JIRA: >>>>> >>>>> https://openedx.atlassian.net/browse/TNL-2319 >>>>> >>>>> I think a good place to start would be to enumerate the different use >>>>> cases that this solution could help with. In general, having a custom tab >>>>> that the author can add blocks to would be very flexible, and much more >>>>> powerful than the current static tab. In fact, it might be better to >>>>> replace the static tab with your new tab, because it is straightforward >>>>> for >>>>> the author to add an HTML block to it, and then they can easily extend it >>>>> by adding videos or any other content they might have. In some ways, it is >>>>> as if they are adding a unit directly as a tab, rather than within a >>>>> section of the course. >>>>> >>>>> An important point to consider is that adding a discussion block to >>>>> this custom tab wouldn't work by default, as it would render an inline >>>>> discussion. The block would have to know that it was being rendered >>>>> 'outside the course', or it would need an advanced setting, or there would >>>>> need to be a different class of discussion block. The last two options >>>>> seem >>>>> to me that they would be confusing for the author. >>>>> >>>>> IMO for a feature like discussions it would be ideal to register that >>>>> it wants to automatically add a tab, rather than requiring the course >>>>> author to explicitly add a new XBlock. This is how the XModule works today >>>>> using the CourseTab extension point: >>>>> >>>>> https://openedx.atlassian.net/wiki/display/AC/Adding+a+new+course+tab >>>>> >>>>> As Cale mentioned, we've been thinking about allowing XBlocks to be >>>>> able to provide course views for themselves (both course-level student >>>>> views, and course-level instructor views). I've written more about this >>>>> here: >>>>> >>>>> <http://goog_576435595> >>>>> >>>>> https://openedx.atlassian.net/wiki/display/AC/Feature+Plugins+for+edX+Platform >>>>> >>>>> I hope this is helpful. Let's keep the conversation going. >>>>> >>>>> - Andy >>>>> >>>>> On Tue, Jun 28, 2016 at 11:41 AM, <[email protected]> wrote: >>>>> >>>>>> Ok, concern noted, I'll keep it in mind. Also, if there are any >>>>>> written outcomes of "caused us more pain than they've been worth" it >>>>>> would >>>>>> be great if you could share them somehow. >>>>>> >>>>>> Actually, we might want to follow the approach StaticTab uses - it >>>>>> stores url_slug in policies.json and actual content in >>>>>> tabs/${url_slug}.xml >>>>>> - is that something similar to what you have in mind? >>>>>> >>>>>> Regards, >>>>>> Eugeny >>>>>> @Opencraft <http://opencraft.com> >>>>>> >>>>>> On Tuesday, June 28, 2016 at 6:15:51 PM UTC+3, Calen Pennington wrote: >>>>>>> >>>>>>> For OLX, I can see the content being exported to the `tabs` >>>>>>> directory, but I'm a bit concerned about where the links to those tabs >>>>>>> will >>>>>>> live. In general, having XBlocks that are detached from the course tree >>>>>>> has >>>>>>> caused us more pain than they've been worth, in the past, so I'd love to >>>>>>> see an explicit reference to the tab usage key somewhere (maybe from the >>>>>>> Course block?) >>>>>>> >>>>>>> -Cale >>>>>>> >>>>>>> On Tue, Jun 28, 2016 at 11:11 AM, <[email protected]> wrote: >>>>>>> >>>>>>>> Cale, >>>>>>>> >>>>>>>> >>>>>>>> - Usage_key - the same as normal blocks have. I don't think >>>>>>>> usage_key includes block's parent, so it won't be affected by >>>>>>>> adding it to >>>>>>>> a tab vs vertical. Is there any caveat I'm missing? >>>>>>>> - OLX - if I do recall right XBlocks in Units are stored in >>>>>>>> "vertical", one unit per file. For a tab it makes sense to reuse >>>>>>>> the same >>>>>>>> approach; the only question is where to put that tab XML file. At a >>>>>>>> glance >>>>>>>> it should be located in "tabs", as StaticTab stores it's contents >>>>>>>> there. >>>>>>>> But it is derived from how HTML module works, so we don't have to >>>>>>>> replicate >>>>>>>> it. I don't have final answer on this, but "tabs" folder seems like >>>>>>>> a >>>>>>>> correct place. >>>>>>>> - There might be three approaches: >>>>>>>> - It doesn't - "student_view" is always rendered - this is >>>>>>>> slightly simpler to implement and has more flexibility, but >>>>>>>> might be >>>>>>>> limited. >>>>>>>> - Convention-based - we define a new "predefined" view (i.e. >>>>>>>> "course_tab_view") to be used for course tab. This view might be >>>>>>>> "abstract", or can just default to "student_view". >>>>>>>> - Configuration based - export some decorator for XBlock to >>>>>>>> mark "course_tab_view" explicitly. >>>>>>>> >>>>>>>> To me, it looks like convention-based approach with "student_view" >>>>>>>> fallback is the most efficient one, so if there are no other >>>>>>>> considerations >>>>>>>> I would try implementing it first (and structuring the rest of >>>>>>>> conversation >>>>>>>> with that assumption in mind). >>>>>>>> >>>>>>>> Regards, >>>>>>>> Eugeny >>>>>>>> @Opencraft <http://opencraft.com> >>>>>>>> >>>>>>>> On Tuesday, June 28, 2016 at 5:10:45 PM UTC+3, Calen Pennington >>>>>>>> wrote: >>>>>>>>> >>>>>>>>> Eugeny, >>>>>>>>> >>>>>>>>> Another approach that we've talked about in the past around this >>>>>>>>> same problem is that rather than having a specific tab type for >>>>>>>>> housing an >>>>>>>>> XBlock, we'd allow XBlocks to expose a course_view, which the XBlock >>>>>>>>> could >>>>>>>>> use to render any course-level content (perhaps configuration details, >>>>>>>>> perhaps something like the Discussions tab, perhaps other uses). >>>>>>>>> Those tabs >>>>>>>>> could be rendered for any XBlock type that appeared in the course. >>>>>>>>> >>>>>>>>> Questions I have about your proposed implementation: >>>>>>>>> >>>>>>>>> - what will the XBlock usage_key would be? >>>>>>>>> - where will the XBlock content (scope.content) would be >>>>>>>>> stored in OLX? >>>>>>>>> - How does an XBlock define a view that's specific to the tab? >>>>>>>>> - For instance, I assume that the Discussion block would >>>>>>>>> have a different display in the tab than it would inline. >>>>>>>>> >>>>>>>>> -Cale >>>>>>>>> >>>>>>>>> >>>>>>>>> On Tue, Jun 28, 2016 at 9:41 AM, <[email protected]> wrote: >>>>>>>>> >>>>>>>>>> My current understanding is that XBlockTab will just provide a >>>>>>>>>> "place" where you can put any XBlock or component, so that it would >>>>>>>>>> be >>>>>>>>>> displayed in tab. >>>>>>>>>> >>>>>>>>>> Theoretically it would mean that any XBlock could be added there, >>>>>>>>>> and that XBlock would work exactly the same in tab or in unit. >>>>>>>>>> Practically >>>>>>>>>> - I don't know yet - there might be a need for an XBlock to >>>>>>>>>> implement some >>>>>>>>>> interface to be able to work in tab, and in that case only certain >>>>>>>>>> XBlocks >>>>>>>>>> will be available for tabs. But I would like to avoid that and have >>>>>>>>>> a truly >>>>>>>>>> generic solution. >>>>>>>>>> >>>>>>>>>> In two words: the suggested XBlockTab lives in edx-platform and >>>>>>>>>> only "hosts" XBlocks. >>>>>>>>>> >>>>>>>>>> Regards, >>>>>>>>>> Eugeny >>>>>>>>>> @Opencraft <http://opencraft.com> >>>>>>>>>> >>>>>>>>>> On Tuesday, June 28, 2016 at 4:30:00 PM UTC+3, Cristian Salamea >>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On Tue, Jun 28, 2016 at 8:13 AM, Peter Pinch <[email protected]> >>>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>>> How would this affect course import and export? >>>>>>>>>>>> >>>>>>>>>>>> I believe unrecognized blocks are ignored on import, but that >>>>>>>>>>>> may be harder to do with tabs, since they are specified in >>>>>>>>>>>> policy.json. >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> In fact question could be extended to: in future any xblock can >>>>>>>>>>> add a tab ? >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> I'd also want to make sure that there is some meaningful >>>>>>>>>>>> logging and error messaging to the user when a course is imported >>>>>>>>>>>> and the >>>>>>>>>>>> proper XBlockTab hasn't been installed. >>>>>>>>>>>> >>>>>>>>>>>> On Jun 28, 2016, at 9:06 AM, [email protected] wrote: >>>>>>>>>>>> >>>>>>>>>>>> Hello world! >>>>>>>>>>>> >>>>>>>>>>>> *Background*: OEP is a new (suggested) format for proposing >>>>>>>>>>>> changes to Open edX platform. More details: >>>>>>>>>>>> https://github.com/edx/open-edx-proposals/blob/master/oeps/oep-0001.rst >>>>>>>>>>>> >>>>>>>>>>>> *Idea: *Allow XBlocks to be displayed in a course tab (like >>>>>>>>>>>> Progress, Discussion, etc.) >>>>>>>>>>>> >>>>>>>>>>>> *Motivation: * >>>>>>>>>>>> >>>>>>>>>>>> - In order to completely pull out discussions from >>>>>>>>>>>> edx-platform. discussion XModule is (almost) converted to >>>>>>>>>>>> an XBlock <https://github.com/edx/edx-platform/pull/12582>. >>>>>>>>>>>> The next step would be to replace course discussion tab with >>>>>>>>>>>> discussion >>>>>>>>>>>> XBlock-based solution. >>>>>>>>>>>> - This might be useful for building instructor tools (example of >>>>>>>>>>>> a tool that could benefit from this >>>>>>>>>>>> >>>>>>>>>>>> <https://github.com/open-craft/problem-builder/blob/master/problem_builder/instructor_tool.py>). >>>>>>>>>>>> This is related to other thread on mailing list >>>>>>>>>>>> <https://groups.google.com/forum/#!topic/edx-code/Zd2sKQaMhHI> - >>>>>>>>>>>> kind of alternative implementation. >>>>>>>>>>>> >>>>>>>>>>>> *Tentative implementation details: * >>>>>>>>>>>> >>>>>>>>>>>> *tl;dr*: XBlockTab (working name) will be similar to existing >>>>>>>>>>>> StaticTab (powers "Custom Page" feature) and use nested XBlocks >>>>>>>>>>>> concept to >>>>>>>>>>>> allow using any XBlock (component?) in a Tab. >>>>>>>>>>>> >>>>>>>>>>>> Overall, it would work like that: >>>>>>>>>>>> >>>>>>>>>>>> - "Pages" page in Studio will have "Add XBlock Page" button >>>>>>>>>>>> added; this button will cause XBlockTab to be added to a course >>>>>>>>>>>> - In studio XBlockTab will expose UI for adding XBlocks and >>>>>>>>>>>> (most likely) other components (problems, video, etc.), similar >>>>>>>>>>>> to one >>>>>>>>>>>> found in course Outline editor (Unit page). At a glance it >>>>>>>>>>>> looks like it >>>>>>>>>>>> could be exact same UI, but it is not 100% clear yet. >>>>>>>>>>>> - Components added to an XBlockTab will be persisted to the >>>>>>>>>>>> modulestore using the same mechanism to allow nested XBlocks. >>>>>>>>>>>> - In LMS, XBlockTab will render its children (nested) >>>>>>>>>>>> components sequentially - much like "Unit" (aka vertical >>>>>>>>>>>> module). >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> I'm about writing an OEP this week, so feedback and ideas are >>>>>>>>>>>> very welcome. >>>>>>>>>>>> >>>>>>>>>>>> Regards, >>>>>>>>>>>> Eugeny >>>>>>>>>>>> @Opencraft <http://opencraft.com/> >>>>>>>>>>>> >>>>>>>>>>>> -- >>>>>>>>>>>> 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/ad852782-b1e2-46ba-85bc-8d93db72048a%40googlegroups.com >>>>>>>>>>>> <https://groups.google.com/d/msgid/edx-code/ad852782-b1e2-46ba-85bc-8d93db72048a%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/CFAAC85C-CE8E-4A56-819C-F1610A0C730A%40gmail.com >>>>>>>>>>>> <https://groups.google.com/d/msgid/edx-code/CFAAC85C-CE8E-4A56-819C-F1610A0C730A%40gmail.com?utm_medium=email&utm_source=footer> >>>>>>>>>>>> . >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> [image: Cristian Salamea on about.me] >>>>>>>>>>> >>>>>>>>>>> Cristian Salamea >>>>>>>>>>> about.me/ovnicraft >>>>>>>>>>> <http://about.me/ovnicraft> >>>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> 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/70e847c6-b42e-470f-8ea2-9ffba6d81e2f%40googlegroups.com >>>>>>>>>> <https://groups.google.com/d/msgid/edx-code/70e847c6-b42e-470f-8ea2-9ffba6d81e2f%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/4dd69f54-5ead-45ea-bf29-3b7ffce6be64%40googlegroups.com >>>>>>>> <https://groups.google.com/d/msgid/edx-code/4dd69f54-5ead-45ea-bf29-3b7ffce6be64%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/e68f5731-3dfd-43c6-a15f-a08babc0d51f%40googlegroups.com >>>>>> <https://groups.google.com/d/msgid/edx-code/e68f5731-3dfd-43c6-a15f-a08babc0d51f%40googlegroups.com?utm_medium=email&utm_source=footer> >>>>>> . >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> >>>>> *Andy Armstrong* >>>>> >>>>> edX | UI Architect | [email protected] >>>>> >>>>> 141 Portland Street, 9th floor >>>>> >>>>> Cambridge, MA 02139 >>>>> http://www.edx.org <http://www.edxonline.org/> >>>>> >>>>> [image: >>>>> http://www.e-learn.nl/media/blogs/e-learn/edX_Logo_Col_RGB_FINAL.jpg?mtime=1336074566] >>>>> >>>> -- >>> 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/ff1916be-7f37-4e5a-ab56-c39d89d661ba%40googlegroups.com >>> <https://groups.google.com/d/msgid/edx-code/ff1916be-7f37-4e5a-ab56-c39d89d661ba%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/b5b5952a-5899-492f-b676-c9a7743157a0%40googlegroups.com > <https://groups.google.com/d/msgid/edx-code/b5b5952a-5899-492f-b676-c9a7743157a0%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/CAEyJbEbdzmrBsf%3Dv-zMzytGpp9To_kKgCQN-UCN-Dsxgabg9Fw%40mail.gmail.com.
