When I use the Views 'Loop Wizard', I select the field(s) that I want to appear in the output. I must then customize the wizard output to add appropriate HTML/CSS code for each field where necessary.
If I have multiple views/layouts containing a given field, I have to add the same HTML/CSS code each time I use add that field to a view/layout which introduces opportunities to make coding errors/bugs.
Is it possible (now) to set, for a given field, default HTML/CSS that would be included in views/layouts?
For example:
1) I set up three custom fields: 'customfield1', 'customfield2' and 'customfield3';
2a) I want 'customfield1' to be rendered as a <div> element and assigned a CSS class of 'patron';
2b) I want 'customfield2' to be rendered as a <article> element and assigned a CSS class of 'patronarticle';
2c) I want 'customfield3' to be assigned a CSS class of 'patronrating';
If I included 'customfield1 in a view, the Loop Wizard would render the following:
[types field='customfield1' ][/types]
I would then need to customize this instance to the following:
<div class='patron'>[types field='customfield1' ][/types]</div>
This is not a difficult process for a single instance of one field. However, if the process needs to be repeating for many instances of several fields in multiple views, then even a small typing mistake can result in errors/bugs.
CSS and JS added to Views are applied to those Views only, or Views nested into it.
If you want CSS applied globally you best do it in the Theme's style sheet.
If you want to apply it on all Layouts, use the Layouts CSS/JS editor.
To add Classes or wrapping HTML you need to edit this manually.
Each View or Layout permits a different output and hence it needs to be added.
Hence you need to wrap your fields, there is no way to avoid that, manually.
But you can then apply the CSS thru a Them's Style Sheet or Layouts CSS editor.
We cannot make these things set global, as that will restrict the power of customization massively.
Beda:
Thanks for your detailed response.
I understand how to set the CSS at various levels within the Toolset elements, but that's not the issue.
Just to clarify, my suggestion is to allow Types to set the default HTML/CSS for a given field (as opposed to setting a global value that would be applied universally in all views/layouts).
If the wrapping HTML/CSS for a field in any specific view could be set initially based on that field's default value, the wrapping could always be modified at the view level in order to support customization.
As I said, the goal of the suggested change would be to reduce coding effort as well as reduce typing errors and related bugs.
Would it be possible to add a PHP filter to the functions.php file that would affect the Loop Wizard output? That is, before rendering the existing code for a given field (e.g. "[types field='customfield1' ][/types]"), would it be possible to interrogate the name of the field and apply the appropriate wrapping to the [types][/types] field structure? Just an idea.
JJ
I have filed this request, but I cannot guarantee we will implement this, for the reasons I outlined above.
Types alone is not thought to provide any style (or possibly less).
With conditionals like you suggest, you can kill a website if it gets many hits, and has a lot of different content rendered dynamically.
HTML conditional can become expensive in terms of performance and that is what we would use here.
Yes, you can construct PHP code like that, but we cannot provide it here. Also I am concerned it will stat to slow your site down with the time.
HTML should usually not be loaded "too" conditionally, means, if you load conditionally several layers of CSS, eventual JS and HTMl you not only slow the site but also will probably start to have conflicts with validators 8(If for example the HTML is arranged on the fly).
I filed the request and developers will consider this, but I do not think it will get implemented.
Please keep an eye on our Update Logs.
Thank you for understanding.
Beda:
Thanks for your response, but I think you may have misunderstood the scope of the change I am suggesting.
I am not suggesting that any additional logic be added to the processes which actively render HTML for a live page. My suggestion is limited to the process which creates (or edits) views at the single point where the Loop Wizard is used.
My suggestion is based on the premise that a given field is usually rendered on a website using consistent HTML/CSS elements. For example, a given custom text field would likely always be wrapped in a <p> HTML element and assigned a class of 'customtext1'. If selected in a View, the Loop Wizard currently renders simple code such as "[types field='customtext1' ][/types]". The developer must then manually add the appropriate HTML/CSS to get to code such as "<p class='customtext1'>[types field='customtext1' ][/types]</p>". If this field appeared in multiple Views, the developer would have to manually type the same code for this field in each View.
My suggestion is to modify the Loop Wizard logic to automatically add the HTML/CSS during the editing process so that the developer does not have to do it manually. The resulting code could still be edited by the developer in order to support detailed customization for a given View.
The main benefit of this would be that the HTML/CSS code for field 'customtext1' would be more consistent across all views but could be customized if necessary. Further, if a database contained many custom fields of various types, this approach would ensure that appropriate HTML/CSS would be associated with each one, which would reduce coding effort, increase consistency and minimize bugs/errors.
Thanks for your patience in considering this suggestion.
Yes, I understand this.
And it is the exact reason why most likely we will not implement it:
The developer must then manually add the appropriate HTML/CSS to get to code such as "<p class='customtext1'>[types field='customtext1' ][/types]</p>". If this field appeared in multiple Views, the developer would have to manually type the same code for this field in each View.
That also guarantees the freedom of the developer to do whatever he/she wants with it.
We provide the data, HTML has to be added. And it can be added very granularly.
But the request is filed, and our Developers will look into this detail.
Thank you for the exact descriptions of the request!
Beda:
I confess that I don't understand the rationale behind your strategy. For example, your CRED form editor contains a code generator which renders default HTML integrated with the [types][/types] shortcodes. This feature is available presumably to save the developer from the effort of adding repeating HTML structures within the form. Further, the generated HTML structures are dependent on the field being rendered, and can subsequently be modified by the developer.
As I see it, my suggestion is not significantly different than a feature you already offer in CRED.
So, why do you make the developer add HTML in one editor and yet generate HTML for him in a different editor?
I'm really trying not to be obtuse here, but I simply don't understand the thinking behind your explanation if you are trying to make the tool as user-friendly as possible, especially from a coding perspective.
