Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
This patch introduces semantic views. This is mostly the code from the semantic views module. I guess this needs some clearnup.
I also copied the documentation.
Comment | File | Size | Author |
---|---|---|---|
#34 | 740686-semantic-views.patch | 35.19 KB | merlinofchaos |
#32 | 740686-semantic-views_1.patch | 32.26 KB | dagmar |
#30 | 740686-semantic-views.patch | 32.06 KB | dawehner |
#29 | 740686-semantic-views.patch | 32.52 KB | merlinofchaos |
#27 | views-740686-semantic-views.patch | 5.67 KB | dawehner |
Comments
Comment #1
dawehnerAdd Tag.
Comment #2
merlinofchaos CreditAttribution: merlinofchaos commentedMy immediate thought is that the items in row-style-options.jpg could actually be on the fields themselves? That way *all* styles could support that?
Comment #3
merlinofchaos CreditAttribution: merlinofchaos commentedSecondly, what I think would be most useful is if the semantic options would mostly be on the base row/style classes, and a 'semantic' setting could be in the plugin definition which would make it very simple to let plugins say "I support the semantic rules" and turn on the UI for those. One of the problems people have experienced with the semantic style is that they get very sad when they want to use semantic options with a table and they cannot.
Comment #4
Anonymous (not verified) CreditAttribution: Anonymous commentedmerlinofchaos:
My instinct was also to put the element and class attributes on the fields as well, but I decided against it for a few reasons.
1. UI. Picking the tags and classes is easiest when you can see and change all of the fields together.
2. Inheritability. Fields, sorts, arguments and relationships tend to be the things I don't override as much as I override display, style and row style options.
3. Hierarchy. As an example, think of a view with a page display and a block display. By default, Drupal themes block titles with h2.title. Node teasers are also themed with h2.title. If I want to use fields for both of these displays, I may want to use h3.title around node titles in the block display and use h2.title or node row style with teasers on the page display.
But it also makes sense to put this onto field handlers. A lot of rewriting gets done there already, too, with links, altering output and token replacement.
Thanks dereine for starting this work!
Comment #5
Anonymous (not verified) CreditAttribution: Anonymous commentedYar! Merlinofchaos knows best. I'm fiddling with a view right now and I now see the indisputable merit of his idea.
The view has 3 displays. Each has one field, but in each display the field is different (field_image, field_video, field_audio). Without overriding the row style options on each display, the output is always broken for TWO of the displays. The field names are used in the semantic views row style options for the default display, but the field name for the default is only valid for one of the displays. The other displays are looking for different field names in the row style options!
Sheesh now I'm consternated. I need to document this in Semantic Views.
Comment #6
merlinofchaos CreditAttribution: merlinofchaos commentedComment #7
q0rban CreditAttribution: q0rban commentedsubscribe.
Comment #8
dawehnerEven this is not a big argument but i suggest to not use this on field level, too, because i wouldn't expect it there.
For me everything beside the left column is related to the sql query. The left is for settings and style and some general query settings.
Comment #9
Anonymous (not verified) CreditAttribution: Anonymous commentedDereine and I have arranged to meet up in IRC on Saturday at 1500 GMT. That's 1000 (10 a.m.) Chicago time. We'll be in #drupal-views. Please join us for a brainstorming session... this is a tricky issue to figure out, so any surplus brains will help.
Comment #10
q0rban CreditAttribution: q0rban commentedI don't think I'll be able to make that session, but my 2 cents: I think it makes sense to be at both the row level and the field level. I'm torn about whether this should actually be in the views UI though, as there are already so many options there. It would have to be done differently than it currently exists in semanticviews though, b/c having all that stuff exist at the field level for every field will just be insane.
Going to be thinking about this.
Comment #11
dawehnerDamn
I was sure you wanted to change the 1800 GMT
I'm sorry
Comment #12
Anonymous (not verified) CreditAttribution: Anonymous commentedSo far, the best ideas seems to be to return to the unformatted row style that I formed the basis of Semantic Views.
I'm pasting the default views view fields template from views 2 here:
The most viable sane idea so far is to expose these properties through the field handler options:
element_type
class
This would have the effect of allowing any output style to be "semantified" -- tables, grids, lists, etc.
Current Semantic Views features would be re-created by overriding the views-view-fields.tpl.php and removing the outer wrapper and the separator.
I have mixed feelings about this, but I think the benefit of semantifying more output styles is a good one. I also don't have a more reasonable proposal...
Comment #13
dawehnerThere are two hard tasks
* Don't brake existing templates/css
* Keep the inline feature
So what i did:
* i just changed the class of the wrapper of the content of the field.
* Everything else happens on the preprocess, and in the field handler.
Comment #14
dawehnerIntegrate semantic with table style.
Minor cleanups.
This does only introduce the fields class, not the row classes.
Any idea/comment is welcomed, beside +1/subscribing :)
Comment #15
BenK CreditAttribution: BenK commentedVery cool. Sorry to do a subscribe, but I need to keep track of this thread! :-)
Comment #16
dawehnerThis has to be checked for security, but the patch could still get a review.
Comment #17
achtonSubscribing. So important patch, this.
Comment #18
dawehnerBefore:
After:
This is not perfect.
Updated patch: Fix storage of the element
Comment #19
dwwApparently, this is the better solution to what I was trying to accomplish with #918782: Allow CSS class specifically for the list markup in the list style plugin. Haven't looked at any patches, but the concept sounds good. ;)
Comment #20
klonossubscribing...
Comment #21
tim.plunkettSub.
Comment #22
lpalgarvio CreditAttribution: lpalgarvio commentedsupport all kinds of Styles and Row Styles like was said before...
to avoid the problem of inheritance, placement, etc, put the Semantic styling inside a new UI entry, the Field Styles - this would include the styling put on Style (View Style) and the styling put on Row Style.
additionally, rename Style to Views Style to avoid confusions.
Style settings would contain:
View Style
Row Style
Field Style --> containing all the semantic view styling.
CSS class
Theme
would also require removing any custom setting of CSS/class styling for Fields (since they would be now in Field Style).
Comment #23
dagmarAfter review the patch, I would like to share this code, It is a bit different from #18, due it allows users to use [replacements] inside classes (like 'rewrite the output of this field').
This may be a performance problem, and we should take care about this if this patch is included.
Related to #13
Ok, I agree, however new semantic capabilities may require users recreate their templates. I mean, this update should not destroy existent templates, but semantic classes will only be available for default views 3 templates. (and new overrides)
Related to #14
In my opinion, allow [tokens] for row classes would be great, however I don't see a clear way to do this, but maybe we can do some rework on tokens management of views to achieve this task. Also we need a new UI for this task.
Related to #16: I included a check_plain for the element_type.
Changing status to get some new reviews.
Comment #24
dawehnerCool to see some progress
We could save some time here when we store the tokens per row in a static.
What about renaming semantic_cells to semantic_classes? This would help a bit to understand it better.
Comment #25
dagmarMarking #945326: Extend field grouping class naming as a duplicate of this issue. There are some nice ideas too.
Comment #26
BrightBoldSubscribing, as my Semantic Views 7.x joy was just dashed by realizing that the view I wanted to semantify is draggable, and I have to choose one or the other. So it would be great to have this kind of integration.
Comment #27
dawehner* Fixed the concatenation of the classes for tables.
* Manual testing works fine.
* Caching the render tokens isn't that easy as i thought.
Comment #28
merlinofchaos CreditAttribution: merlinofchaos commentedUpping to critical. This is the next alpha blocker in line.
I expanded significantly on this patch:
I made the element selectable from a list, rather than something you enter. I think it's okay to limit to a basic set of elements. The classes are still selectable.
Comment #29
merlinofchaos CreditAttribution: merlinofchaos commentedComment #30
dawehnerManual testing worked fine: labels, wrapper classes, row classes for style plugins.
I like the fieldsets around the field settings, it gives a strong visual "hook".
Reading the patch didn't offered something, beside it's genius.
Converted grid in the patch.
Perhaps the title/description of the row-class field for grids should be converted to "column" to describe the behavior a bit better.
Comment #31
dagmarAwesome to see this. I have tested the patch and it seems to be working fine. There are some inconsistencies when Row Style is not 'Fields':
I mean, if you select 'Node' as row style, the option 'row class' in the style options should be hidden, due if you put row-[nid], the replacement will not be performed.
Comment #32
dagmarOk, after talk with dereine via IRC, forget what id said in #31.
For other side, argument replacements are not working.
In the attached patch, basically I have changed all the:
with
Comment #33
merlinofchaos CreditAttribution: merlinofchaos commentedDocumentation doesn't match reality here.
Cut & paste documentation not matching reality.
I did this a bunch. I think it would be cleaner to use classes arrays and implode at the end, which would prevent needing to have the if checks on ' '.
Also on several of these it's possible to have no class at all, so we need to be sure to check that possibility in each case. This is now true on the field, field label and field wrapper, and also true on table field and field and field wrapper.
Can someone test this using old templates? While the new functionality should not work, the old templates should continue to function as they already have. Can anyone verify this is true for me? Just copy views-view-fields and views-view-table templates (and I guess list and unformatted and grid) into your theme directory before applying the patch and be sure to clear cache.
Comment #34
merlinofchaos CreditAttribution: merlinofchaos commentedCleaned up some code comments. After review, I think this is in pretty good shape.
Comment #35
ericduran CreditAttribution: ericduran commentedThis is pretty cool.
We can also add a couple of the new tags in the get_elements function. Maybe header, footer and section. Section seems like the most generic one that can be added if anything.
Comment #36
dawehnerWhat about adding a variable of the availible elements?
* tested unformatted style
* tested table style
* tested grid style
* tested wrapper element
* tested label element
* tested element
* tested wrapper element-class
* tested label element-class
* tested element-class
So this looks fine.
Comment #37
merlinofchaos CreditAttribution: merlinofchaos commentedsection is an HTML 5 element. I'm still not sure how we're going to handle HTML 5, but I would like to have a unified way of doing so before I start adding anything HTML 5 to Views.
Other X-HTML elements that make sense can be added to the list trivially.
Comment #38
klonosIs this committed to both branches (6.x & 7.x)?
Comment #39
bcn CreditAttribution: bcn commented@38
http://drupal.org/cvs?commit=459074 = 6
http://drupal.org/cvs?commit=459202 = 7
Thanks for this. Iz nice.
Comment #40
klonosThanks for taking the time to reply Noah ;)
Comment #41
jponch CreditAttribution: jponch commentedsubscribe.