Much needed front end flexibility and customization
Permalink Browser Info Environment
Customizing the style of the forms (basic task for any non bootstrap looking site) is very hard, here are a few reasons and suggestions.
If not removed all together there should be an option to opt out of the .ccm-ui class for a form as it creates many limitations / conflicts with styling.
Css in views.css has "!important" all over it (due to first issue) and again goes against easy customization.
/elements/attribute_form.php "strong" tag around label , poor separation of content and style and cumbersome div structure
You should be able to set a class for your form and each field container and element (implemented in most form addons in the store).
There is no reason for HTML5 form functionality (placeholder, validation) not being implemented as an option.
Proforms has very strong sides to it, especially the way it uses Concrete5 core structures and is great for developing in that way, making it flexible for styling greatly improve it.
If not removed all together there should be an option to opt out of the .ccm-ui class for a form as it creates many limitations / conflicts with styling.
Css in views.css has "!important" all over it (due to first issue) and again goes against easy customization.
/elements/attribute_form.php "strong" tag around label , poor separation of content and style and cumbersome div structure
You should be able to set a class for your form and each field container and element (implemented in most form addons in the store).
There is no reason for HTML5 form functionality (placeholder, validation) not being implemented as an option.
Proforms has very strong sides to it, especially the way it uses Concrete5 core structures and is great for developing in that way, making it flexible for styling greatly improve it.
| Type: | Discussion |
|---|---|
| Status: | New |
You know I was looking at this today, and it's not as bad as you say it is.
The idea of any block or package view is not that it singularly be the end-all-be-all of what that block can do, but rather a simple example of what it can do.
The appropriate, and easy I might add, way to style the PF display block is as follows:
1) copy view.php,view.js over to root -> /blocks/proforms_display/templates/template_name/ (do not include the view.css. no need)
2) remove ccm-ui class from line 13
That's it.
I am going to add one thing though to add more flexibility. Changing the attribute loader to look like so and accept custom classes for the input wrappers.
I think this will help a great deal.
ChadStrat
The idea of any block or package view is not that it singularly be the end-all-be-all of what that block can do, but rather a simple example of what it can do.
The appropriate, and easy I might add, way to style the PF display block is as follows:
1) copy view.php,view.js over to root -> /blocks/proforms_display/templates/template_name/ (do not include the view.css. no need)
2) remove ccm-ui class from line 13
That's it.
I am going to add one thing though to add more flexibility. Changing the attribute loader to look like so and accept custom classes for the input wrappers.
$data = array( 'ak'=>$ak, 'bt'=>$bt, 'value'=>$value, 'review'=>$review, 'custom_class'=>'super_clean' ); if($pfo && $pfo->reviewed > 0){$review = 1;} if($_REQUEST['edit_entry']){$review = null;} Loader::packageElement('attribute/attribute_form','proforms',$data);
I think this will help a great deal.
ChadStrat
I have removed the .ccm-ui and I also added the form's handle as a class to the form in view.php as a quick way to target different forms, like so:
$as = AttributeSet::getByID($question_set);
if (is_object($as)) {
$handle = $as->getAttributeSetHandle();
}
...
<form name="proforms_form_<?php echo $bID?>" class=" proform_slider <?php echo $handle;?>" ...
But all of this I feel is very developer oriented, for somebody who just wants to create a form and style it in their main style sheet, this is not straight foreword. Also I'm not sure that a template per different form is the right way, as not only different forms might have different style but the same form can have different style in different sections of a site, the later can be addressed in the templates view.css but I guess its a broader discussion of what is a the purpose of a block's view and how you organize your css. I'm of the opinion that style issues should be mostly handled without php/backend programming and broader still that there is a whole "CMS+CSS" tier of development/developers that needs to be catered to.
Anyway I think we can agree that you should have the option to give a class to your form.
I would also suggest that ability at the individual field level(example of use: form that have it's fields in columns columns)
$as = AttributeSet::getByID($question_set);
if (is_object($as)) {
$handle = $as->getAttributeSetHandle();
}
...
<form name="proforms_form_<?php echo $bID?>" class=" proform_slider <?php echo $handle;?>" ...
But all of this I feel is very developer oriented, for somebody who just wants to create a form and style it in their main style sheet, this is not straight foreword. Also I'm not sure that a template per different form is the right way, as not only different forms might have different style but the same form can have different style in different sections of a site, the later can be addressed in the templates view.css but I guess its a broader discussion of what is a the purpose of a block's view and how you organize your css. I'm of the opinion that style issues should be mostly handled without php/backend programming and broader still that there is a whole "CMS+CSS" tier of development/developers that needs to be catered to.
Anyway I think we can agree that you should have the option to give a class to your form.
I would also suggest that ability at the individual field level(example of use: form that have it's fields in columns columns)
Thanks for wanting to see the product evolve and improve. It's appreciated.
If you have improved views that you think can be "broad" enough and cleaner, please attach and I will review.
I will add a form field class to the form display block for both the main wrapper and the fields themselves that will override the defaults. I think this is a great idea.
ChadStrat