yes, that sounds good to me.


On Jan 9, 2013, at 10:35 AM, Joe Blaylock <notifications@github.com> wrote:

> In main/templates/content_groups/downloadable_style.html:
> 
> >      <ul class="unstyled course-list">
> >      {% for child in children %}
> >          {% cycle 'zebra_light' 'zebra_dark' as stripecolor silent %}
> >          <li class="course-list-item {{ stripecolor }}">
> > -            <span style="float: left;"><strong>{{child.title}}</strong></span>
> > +        <span style="float: left;"><strong><a href="{{child.url}}">{{child.title}}</a></strong></span>
> So ContentGroup.display_style isn't actually being exposed in the UI anywhere at the moment, so respecting the user's preference seems like a low priority compared to actually soliciting it. In the original request that led to the existence of .display_style, there was an assumption that everything would be button-style except for exams. Since then, subsequent requests have accumulated to make the current behavior, which is that everything is list-style except files. So there's some need for clarity around this:
> 
> @jinpa, does that seem like the right state of affairs, that everything is list-style except files? Or should it, indeed, be a preference set in the item creation and item edit dialogs? And if a preference, I guess list-style display is the default?
> Whichever way is right will imply some work, to canvas the ContentGroup displays and make sure that the defaults for .display_style are correct, that they're being respected, etc.
> In general I agree with you @jbau. Usually when I'm rewriting things, I'm first trying to make the new feature I was asked for work in the context of what's there, then looking for opportunistic refactorings. I'd prefer for there to be a lot less attribute tuple and list generation and passing in general, and was thinking about just passing target object references around when I introduced the ref attribute on child item references in get_group_item_data and friends. I'd love to dig in and flatten data structures. I'm not certain if that should hold up this ticket, though. Without asking anybody, I've been assuming that the data structures that feed the templates grew so hairy because we didn't previously have something like the |byKey: filter, and also inertia.
> 
> So what I'd like to do is this:
> 
> I'll update the branch to twig on display_style rather than child.name in the template and re-push. Then we get this in.
> @jinpa gives me her idea about preferred default behavior for list versus button mode
> I make a ticket to go through and fix the ContentGroup templates to do the right thing, and to add item display style settings if they're desired
> I make a ticket to re-visit get_course_materials to see how much mileage can be gotten from exchanging dictionaries of object references or minimally massaged metadata for the existing data structures (probably a lot).
> That sound ok?
> 
> —
> Reply to this email directly or view it on GitHub.
> 
>