Hi Braden, I am struggling with this thought as well. Did you have any way to strive this idea ?
Thanks Tam On Tuesday, February 10, 2015 at 3:24:26 AM UTC+7, Braden MacDonald wrote: > > Cale, that sounds good to me. Do you have any further thoughts on what > find-or-create would look like? Does it need to be more efficient than a > block implementing its own "find" by walking it's .children property with > runtime.get_block()? Because a simplistic implementation could work with > just the existing child access that already exists, and adding a new > "add_child" method that's a thin wrapper around modulestore.create_child(). > > Also would this be an XBlock service or just a method on the runtime > that's only available in Studio? > > -- > Braden MacDonald > @OpenCraft > > On Thu, Feb 5, 2015 at 1:47 PM, Calen Pennington <[email protected] > <javascript:>> wrote: > >> My thoughts on this have always been that studio would essentially expose >> to an XBlock a hook to allow the XBlock to trigger the find-or-create of a >> new child. So, the XBlock would have control over how, and studio could >> present an interface for finding existing problems. >> >> Alternately (or additionally), the Studio runtime could expose a method >> for creating a new xblock of a particular type, and the parent XBlock could >> call that, modify the fields, call .save(), and then add that blocks >> usage_key to it's own list of children. >> >> -Cale >> >> On Thu, Feb 5, 2015 at 4:31 PM, Braden MacDonald <[email protected] >> <javascript:>> wrote: >> >>> Hi Andy, >>> >>> Letting the XBlock define its children via XML is by no means a hard >>> requirement, but it seemed like most efficient approach at the time the >>> mentoring block was first designed (but using "light" XBlock-like children >>> instead of real XBlock children), and perhaps still is. >>> >>> I actually raised similar questions to your in an internal discussion at >>> OpenCraft - here is Xavier's reply verbatim: Using first-class XBlock child >>> editing in Studio "is actually something I'd like to think of in the long >>> term, as editing XML isn't very convenient for the users. Using the Studio >>> editing capabilities to edit the XBlock structure is very tempting - but I >>> also think we are pretty far away from being able to do something intuitive >>> with the current state in Studio. For example, there is no way to create >>> new children within an XBlock, only to display children already contained >>> in an XBlock. Also, I'm not fully convinced this should be Studio's >>> responsibility - it seem like creating children and the interface to do >>> that might differ depending on the XBlock (creating entries in a poll isn't >>> the same as adding points on a map – both could be valid types of children >>> though). It might make more sense control the creation of children from >>> within the XBlock itself, using widget libraries for shared interface >>> elements." >>> >>> If you want to see an example of the XBlock XML we're talking about, >>> there's >>> one here >>> <https://github.com/open-craft/xblock-mentoring/blob/b6f6a9716/mentoring/templates/xml/mentoring_default.xml>. >>> >>> As you can see, the children of the mentoring block also have children, and >>> the blocks also sometimes need to reference each other by ID or name. >>> >>> Thanks! >>> >>> -- >>> Braden MacDonald >>> @OpenCraft >>> >>> On Thu, Feb 5, 2015 at 12:06 PM, Andy Armstrong <[email protected] >>> <javascript:>> wrote: >>> >>>> Hey Braden, >>>> >>>> Can you explain more of your reasoning as to why the XBlock needs to >>>> have an XML definition which includes the definitions for all of its >>>> children. Having a single XML string that represents all of the children >>>> seems to make it very onerous for a Studio author to create such a block. >>>> This is especially true if the mentoring XBlock wants to include some of >>>> the more complex xblocks as children, such as ORA peer assessments or >>>> content experiments. >>>> >>>> I would have expected that you would instead create each child as a >>>> first class XBlock which you would then edit independently. In Studio this >>>> would behave more like the content experiment xblock that allows the user >>>> to add any children of their choice to the block. If the user is creating >>>> the course by hand in XML, it would also be much simpler for them to edit >>>> each child separately, rather than trying to define the children inside a >>>> string in the parent block. >>>> >>>> Is the problem that the XML needs to define how the layout of the >>>> mentoring block works, and so it isn't as straightforward as just having a >>>> set of children? >>>> >>>> I'd be very happy to discuss this in more detail so just let me know >>>> how I can help. >>>> >>>> Thanks, >>>> >>>> - Andy >>>> >>>> On Thu, Feb 5, 2015 at 2:35 PM, Braden MacDonald <[email protected] >>>> <javascript:>> wrote: >>>> >>>>> *TL;DR: in Studio, there seems to be no way for an XBlock to >>>>> instantiate new XBlocks from XML* >>>>> >>>>> >>>>> We are in the process of converting the "mentoring" XBlock >>>>> <https://github.com/open-craft/xblock-mentoring> to have native >>>>> XBlock children. Much like the <problem_demo> block in the XBlock SDK, we >>>>> want the block to be composed of smaller XBlocks such as <question>, >>>>> <html>, <answer>, etc. >>>>> >>>>> The block currently has a String field, xml_content, which lets course >>>>> authors edit the XML defining the mentoring block and all of its >>>>> children, >>>>> much like the advanced editor of capa problems. >>>>> >>>>> However, while the re-engineered block is now working perfectly in the >>>>> SDK, it is not yet working in Studio. I can't figure out how the XBlock >>>>> can >>>>> ask the runtime to assign its children based on the xml_content. >>>>> >>>>> In our studio_submit() ajax handler, if I try parsing the XML and then >>>>> calling self.runtime.add_node_as_child(...) on each node found in the >>>>> XML, it fails because it depends on id_generator.create_definition() >>>>> which >>>>> doesn't seem to be implemented. I tried implementing it but it became >>>>> whack-a-mole where each attempted fix caused a new issue elsewhere. >>>>> >>>>> I also considered breaking the XBlock abstraction and using >>>>> self.runtime.modulestore.add_child() followed by updating the child's >>>>> fields with the XML data, but the XBlock API has no way for an >>>>> instantiated >>>>> XBlock to set its fields from an XML node - the parse_xml method always >>>>> attempts to create a new block, which won't work in Studio or the LMS. >>>>> >>>>> For now we would be happy with a way to instantiate XBlock children >>>>> from XML at runtime even if there is no persistence of the children, >>>>> though >>>>> that would be ideal. >>>>> >>>>> Any advice? >>>>> >>>>> Thanks!! >>>>> >>>>> -- >>>>> Braden MacDonald >>>>> @OpenCraft >>>>> >>>> >>>> >>>> >>>> -- >>>> >>>> *Andy Armstrong* >>>> >>>> edX | UI Architect | [email protected] <javascript:> >>>> >>>> 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/09945ff9-8f0a-4810-92f9-b1406020864d%40googlegroups.com.
