Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

allow multiple kinds per field #771

Closed
wants to merge 8 commits into
from

Conversation

Projects
None yet
4 participants
Member

mfrederickson commented Dec 17, 2013

addresses #613 by being able to specify that a field may display multiple kinds of content.

To see this in action, add some graphic content and some weather content, then (if you are using the default template for your screen) manually add an entry in the fields_kinds table of field_id 1, kind_id 3 and then preview your screen.

@bamnet bamnet was assigned Dec 17, 2013

mfrederickson and others added some commits Dec 17, 2013

@mfrederickson mfrederickson add new fields during import 0f59fd0
@mfrederickson mfrederickson fixture with new field 4a694f5
@zr2d2 zr2d2 Merge branch 'refs/heads/master' into mulitple_kinds_per_field
* refs/heads/master:
  Flux it, we're doing it live...
  refactor logic into model
  Trying to see if not doing a test involving Rack::Test::UploadedFile will help 1.8.7 pass
  update new location for closure compiler source
  fix #539 text autosizing
  add back mysql dependency
  Downgrade RubyZip to support ruby 1.8
  use capitalized file name
  Alter test to use package
  add the mysql dependency back
  clean up template#import
  create media from image zip entry
  add ruby zip and start reading uncompressed data
adde0af
@mfrederickson mfrederickson merging master into this to bring it up to date ad4cfff
@mfrederickson mfrederickson resequence migration so runs 3ed9ecd
Member

mfrederickson commented Dec 31, 2013

@bamnet any chance this can make it into 0.9.0?

Owner

augustf commented Dec 31, 2013

As we've had this pull for over a fortnight now, I think it's reasonable to bring it into our next release - be it 0.8.5 or 0.9.

Owner

bamnet commented Jan 3, 2014

If I understand this correctly, we'll have more Fields in the system since there would be separate fields to represent combinations... Graphics, GraphicsSidebar, Sidebar, SidebarTicker, etc. Two things jump to mind with the addition of more Fields:

  1. We shift the burden to template designers to understand this stuff. The people who make and package, templates should have to know as little as possible about the innards of Concerto to create beautiful templates for it. Also, by putting this on the template side it becomes an global choice that the BlueSwooshKaboodle template enables this functionality but BlueSwoosh regular does not.
  2. More fields make it harder for us to automatically reuse Subscriptions between Templates. Fields were added to V2 as an abstraction between the actual rectangle on the template and the subscriptions for that rectangle so you could switch template without having to redefine all of your Subscriptions. Switching between BlueSwooshClassic and BlueSwooshKaboodle would require a redefinition of the large center graphical area since the fields would be different.

I wonder if this approach could be rebuilt on the content side to accomplish the same thing. Since the content => kind mapping is hardcoded in each content type storing it in the DB only makes the lookups slightly faster. Ignoring speed, it could be moved to a method / attr_accessor on the content side and return multiple Kind values or be a can_render_in? method where something (Field? Kind? idk?) is passed.

Member

mfrederickson commented Jan 3, 2014

I can understand your wanting to minimize the number of fields. All of the example templates have all four fields, but the "these four and no more" perspective wont fit all use-cases. The power of templates is that they allow the users to present their screens the way they want to-- specifically what content shows where.

Designers are going to have to know some basics such as what the "canned" fields are and what type (kind) they map to [that's in the template xml already] and how subscriptions are mapped and carry over from template to template, and how to handle different scenarios like the first two mentioned below.

1️⃣ What if a user wants two different Text areas which show different RSS information? Since subscriptions are mapped to a field, if we don't add another field for the second Text area how will that be possible? At some point we are going to need to allow additional fields, aren't we?

2️⃣ What about the use-case where someone wants a main presentation area (that shows a combination of Graphics and Text), with the time and ticker at the bottom?

3️⃣ Just for completeness, this is the use-case that is handled already with the default template. Four positions, four fields.

🌟 Perhaps another solution would be to keep track of the field to kind mappings per template. This would preserve the reusable subscriptions functionality over a larger scope because template designers could say that the Graphics field mapped to the Graphics kind for 3️⃣ (which is the default anyway so that is transparent); and to the Graphics kind and Text kind for 2️⃣. However, for 1️⃣ there would still need to be an additional field, that would not have the subscriptions carried over for (unless you have multiple templates for that use case and have set up subscriptions for that new field already).

I'm not sure how the content side approach you mentioned would meet those first two scenarios because I don't quite understand, can you elaborate? Also, if you have weather content, for instance, as Graphic kind (because you want it to show in the main area in 2️⃣ as well as it's default Text kind, then how do you prevent it from showing up in both areas when the template is switched to a standard one like in 3️⃣? I would think this would be an undesired side-effect.

Owner

bamnet commented Jan 7, 2014

You're right, the content-side approach doesn't touch on 1️⃣ at all. My traditional answer to the duplicate fields question has been that you would create a secondary field, so your template would have the first common Graphics field that everyone knows and is fully reusable and it would have a second 'Graphics 2' field that is very uncommon. Switching templates would automatically work with the primary graphics position, but the secondary graphics information wouldn't translate. There might be a cleaner way to resolve this, but I think the approach should be multi-kind per field neutral (it should work with just 1 kind per field, or N).

The main presentation area for 2️⃣, with a mix of Graphics + Text content would be up to the content to resolve. Most of the Text content that we pulled into V1 was optimized for portrait orientation the area usually has and might not use the best screen real estate in a large landscape area (aka lots of line breaks and clipping the line length). As an example RSS, when displayed in the Graphics area, could show a much longer description that the sidebar (if we were truncating that) or it could be a subtle as centering the title instead of left-aligning it.

From an implementation perspective, we would ignore the Kind attribute in the Content table when selecting content to render. The where clause would grab all content, so the content to be shown in Graphics would include [Graphic 1, Graphic 2, Ticker 1, Ticker 2, Text 1, Big Text 2] and then we could filter that list to only include content that wanted to show in a Graphics field.

class Ticker
  def can_render_in?(field)
    return field.kind == Kind.where(:name=>Ticker)
  end
end

class HtmlText
  def can_render_in?(field)
    return field.kind == Kind.where(:name=>Text) || self.name.include? 'Big'
  end
end

contents = @subscription.feed.approved_contents.active # Note the lack of kind enforcement here
contents.delete_if? { |content| !content.can_render_in?(field)}

Which would leave us with just [Graphics 1, Graphics 2, Big Text 2] to be rendered in a Graphics position though the logic in the two models is obviously overly simplified.

Member

mfrederickson commented Jan 7, 2014

It sounds like in that implementation then that the developer chooses where types of content can render instead of the user.

In 3️⃣ the user wants two separate areas, but it sounds like maybe it would display the text in the graphics area. Of course you could isolate them with different feeds but then you'd lose the flexibility of being able to flip over to template 2️⃣ which you would be able to in the implementation I mentioned above. Right?

Owner

augustf commented Jan 14, 2014

@mfrederickson Do you think you have a good sense of what direction to take this in?

Member

mfrederickson commented Jan 14, 2014

I do, but I don't think Brian agrees. I was waiting to talk to him about it tonight/tomorrow.

Member

mfrederickson commented Jan 15, 2014

Just linking to #822 for visuals of 1️⃣, 2️⃣, and 3️⃣

Owner

augustf commented Jan 24, 2014

Is there anything else to be done or discussed on this request? After a month (and with the request having now fallen out of sync with master even), it's probably time to call the question on this one.

@zr2d2 zr2d2 Merge branch 'refs/heads/master' into mulitple_kinds_per_field
* refs/heads/master: (121 commits)
  reserved word changes closes #859
  add ordering to the individual queries
  Fixes #852 by not creating a backup file for sed -i
  Ok-more mucking with my path-trying again...
  Fixed local system libs for Gemfile
  Updated gems for 0.8.6
  Bump to 0.8.6.JulietJaguar.
  time parsing tweaks
  tweak time parsing
  Replace concerto-audio with concerto_audio...not sure why that was working...
  Add concerto_template_scheduling to seeds as disabled by default
  fix tz tweak to use times as local times
  Use Ruby 1.8.7 safe Time operations.
  set local zone to UTC for time tests
  use the user or system time zone on each request
  parse the start and ends times as if they are local
  Fixed an oversight of some i18n rubbish for #841
  add gems for scheduling for #835 and #576
  add gems for scheduling for #835 and #576
  add gems for scheduling for #835 and #576
  ...

Conflicts:
	app/views/field_configs/index.html.erb
cae94cd

@augustf augustf modified the milestone: 0.9.0 KiloBalrog Feb 25, 2014

@bamnet bamnet removed this from the 0.9.0 KiloBalrog milestone Mar 6, 2014

@augustf augustf added this to the 0.9.1 milestone Apr 4, 2014

@augustf augustf closed this Apr 9, 2014

@mfrederickson mfrederickson deleted the mulitple_kinds_per_field branch May 19, 2014

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment