I'm redesigning the templates for our online store (Using Castle Monorail with the NVelocity view engine) but want to provide the old layout to certain users.
I've started out adding a variable to the PropertyBag that determines the version the user should get and set the layout to 'BaseLayout.vm' which looks like this:
#if($StoreVersion == 2)
#parse("VersionTwo/DefaultLayout.vm")
#else
#parse('VersionOne/DefaultLayout.vm')
#end
This works OK for the layout and I can technically use this approach in every template file, but this seems a bit long winded. Is there a better way I can mechanize this?
Instead of having a layout that "forwards" conditionally to other layouts, you can put the condition in code and set the LayoutName property in the controller.
I would crate a controller filter and override the layout name to be rendered based to your logic
Related
Disclaimer: I inherited a Drupal 7.44 site with no experience in Drupal at all.
The business is trying to make a new webform and they want it to look exactly like an existing one. After looking around I found that the webform has a template tied to it. From the docs it seems I'm supposed to create more template files with the format webform-form-[nid].tpl.php where [nid] is the webform node id.
We have multiple environments that all changes must go through - dev, test, and finally prod. Wouldn't the node id be different in every environment for newly created webforms? Also, if I want to apply the same template to multiple webforms, do I really need to make multiple identical template files?
I also found some CSS styling for the existing webform and it looks like .webform-client-form-25 button.webform-submit and such. That 25 is the node id. I have little CSS experience, but this feels really bad. I don't want to copy blocks of CSS, changing node ids over and over. What's the proper way to assign generic, reusable CSS classes to webforms? I saw "Custom classes" under "Manage Display" when editing the form, but it didn't seem to change the actual HTML of the form. Was I on the right track though, should I just read some docs about it?
You are absolutely right, these detailed selectors do not make sense for reusable layouts.
Each webform HTML form gets a default class of .webform-client-form (that's generic) and an id including the webform's nid #webform-client-form-<nid>.
So, you could change #webform-client-form-25 to the class mentioned above. Please be aware, that this will affect all webforms then.
To set layout settings to several, but not all webforms, you need to give these webforms some class to distinguish them from the rest. Sadly, the Webform module itself doesn't provide an option to do that, but you can add a form alter hook in your theme's template.php:
function mytheme_form_alter(&$form, &$form_state, $form_id) {
$affected_forms = array('webform_client_form_25', 'webform_client_form_37', [...]);
if (in_array($form_id, $affected_forms)) {
$form['#attributes']['class'][] = 'my-custom-class';
}
}
With .my-custom-class you can then define CSS just for the group of webform forms listed in $affected_forms.
As for the template files, Webform itself states:
This file may be renamed "webform-form-[nid].tpl.php" to target a specific webform on your site. Or you can leave it "webform-form.tpl.php" to affect all webforms on your site.
So, again, it doesn't provide an option out-of-the-box, but you can create theme suggestions in your template.php by extending $vars['theme_hook_suggestions'] in a page preprocess function.
When using HTML form renderer in DRF, can anyone think of a nice way to auto generate some indication of "required" field in DRF, by hook or crook? I mean before I submit the form, some indication on the field that it is required - the Browsable API it will show right in the form what the error is but only after submitting.
Whether I am using technique as shown here for browseable API with field level HTML forms (instead of just raw/JSON form):
django-rest-framework - autogenerate form in browsable API?
Or I am using TemplateHTMLRenderer with a call to render_form as discussed in docs here:
http://www.django-rest-framework.org/topics/html-and-forms/#rendering-forms
I don't see a simple way to make my required fields rendered as required. So say we have like
#models.py
class Foobar(model.Models):
foo = models.CharField(max_length=100, blank=True, default='')
bar = models.CharField(max_length=100, blank=False)
The best I can think of is making my own template/snippet for each type of field "required-text-field.html", "required-checkbox.html", etc and using the style declaration in the serializer as shown here:
http://www.django-rest-framework.org/topics/html-and-forms/#field-styles
That's assuming I am understanding this, have not played with it yet to see.
But I would love to see a way to auto-generate the field with/without a required flag as appropriate (even just an asterisk, or applying a CSS class) based on the model definition.
Rambling: The goal here was to avoid writing my own forms, having DRF generate the form for me in custom views. As opposed to writing my own forms using tying them into AJAX I figured templates, render_form, and some format checks would suffice. But now I'm thinking DRF is built for back-end and dev, not front-end, and maybe I should plan to write my own forms if it will be end-user visible? Also I could have CSS files and select based on name, calling render_form then applying hand spun styles, would be less work than the HTML + the CSS. Should I review Django (just Django, not DRF) Forms and re-use serializer as validation?...
I can see 2 ways:
you can define your own template pack, look at the existing ones in the sources (e.g. 'rest_framework/horizontal/input.html') - you can check if field is required and according to this flag, set some css. you do not need something extra, especially "input-readonly.html" - just make your own copy of input.html, add few if-s and it will work.
or you can call OPTIONS on the API endpoint to get all the necessary information about fields, not only required, but readonly and allowed values for some selects - this is if you can update your forms from javascript
Would it be possible to have a dynamic valdr-type? I am trying to build a dynamic form based off of nested objects and valdr-type="{{constraint}}, for example, but is not working.
Can valdr-type be dynamic or does it have to be set with valdr-type="InsertStringHere"?
No, valdr does not yet support dynamic valdr types. I opened an issue for it: https://github.com/netceteragroup/valdr/issues/74
I was wondering if you can change your style while lifetime?!
Example: Administrtor loggs into the app, chooses interface settings and finally changes the color of the overall header
That would be a nice component to do so: link
So is that possible? And can you give me a little hint how to do that :-)
Thank's
I had done this by having multiple css classes predefined and then on the back-end had a variable containing the current class in use.
You can then with an interface or some parameters, or user settings, etc, choose a class to give to the variable.
In my jsp page the code was something like this:
<div class="#{logEntry.styleClass}">
and the backend variable "styleClass" was of type String.
I have some view which lists my module table entries.
What is the most elegant way to attach a form below the view to add record?
Waht I am trying to do know is:
I created dedicated form in my module:
function my_module_form_add_record($form_state) {
form fields.....
}
I added to the view theme file:
$add_form = drupal_get_form('my_module_form_add_record');
print $add_form;
But I do not like this solution for at least 2 reasons:
I does not work ...
2. Even if it worked - it is depended on the theme file! So if I change the theme - functionality is crashed.
I would like to find more elegant solution to attach form from custom module to the view.
I know of the existence of the "Views Attach" module but it has no option of adding custom forms.
I know also of the existence of the Views Embedded form (and I am usig it) but it is only useful if you want to add form to the every row.
Seems the must be some solution to add record from the view page!
Thanks you for help.
you could use hook_views_pre_render:
This hook is called right before the render process. The query has been executed, and the pre_render() phase has already happened for handlers, so all data should be available.
Adding output to the view can be accomplished by placing text on $view->attachment_before and $view->attachment_after. Altering the content can be achieved by editing the items of $view->result.