Help with submitting data in edit/add.php
Permalink
hi im trying to add my custom edit/add.php code using $form helper but when submit is clicked i got a popup window saying error with all the text concrete5 can find on the site
concrete5 version latest
my example code
form_edit_html.php
edit.php
process.php
i know this si very simple example but the real code is too much for the simple add button save() function so i need form submit to work.
weirdly using custom pages it works just fine so i assume is some bizarre behavior of the edit/add form
thx for your help
concrete5 version latest
my example code
form_edit_html.php
<?php defined('C5_EXECUTE') or die("Access Denied."); $form = Loader::helper('form'); $myForm=$controller; ?> <div id="formCampaign"> <form method= "post" action="<?php echo $this->action('insert_campaign')?>"> <?php print $form->text('Cname', "Campaign"); print $form->text('Cdesc', "Campaign Description"); print $form->submit('boton', "Add/Update"); ?> </form> </div>
edit.php
process.php
public function action_insert_campaign() { $Cname = $this->post('Cname'); $Cdesc = $this->post('Cdesc'); //lots of sql code }
i know this si very simple example but the real code is too much for the simple add button save() function so i need form submit to work.
weirdly using custom pages it works just fine so i assume is some bizarre behavior of the edit/add form
thx for your help
Can you post a screengrab of the error message and page behind it so we can see it in context.
image attached
What I suspect is happening:
On a single page, you create your own forms. In a block add/edit dialog, C5 provides the enclosing form for you. All you need to do is provide the form content.
Html form elements can't be nested. By creating your own form, you are in fact just breaking the behaviour of the surrounding form already created by C5 for the edit dialog.
The C5 form is handled by the block controller, so the code in process.php should either be in the save method of the block controller, or called from the save method of the block controller.
You could pick a fairly simple free block from the marketplace and disect it for an example.
On a single page, you create your own forms. In a block add/edit dialog, C5 provides the enclosing form for you. All you need to do is provide the form content.
Html form elements can't be nested. By creating your own form, you are in fact just breaking the behaviour of the surrounding form already created by C5 for the edit dialog.
The C5 form is handled by the block controller, so the code in process.php should either be in the save method of the block controller, or called from the save method of the block controller.
You could pick a fairly simple free block from the marketplace and disect it for an example.
i think ill stick to pages then since all the components i've found have very simple configs and the complex ones use pages.
add/edit.php is good for very minimal components but for complex stuff it gets really bitchy
i would suggest for a next version to add and option to select the behavior of of these block forms like
assisted <-- current
expert <-- more like pages so we can avoid the voodoo needed to configure in a page and then capture the Bid so each block instance can show its assigned content
thanks for your help now back to do voodoo
add/edit.php is good for very minimal components but for complex stuff it gets really bitchy
i would suggest for a next version to add and option to select the behavior of of these block forms like
assisted <-- current
expert <-- more like pages so we can avoid the voodoo needed to configure in a page and then capture the Bid so each block instance can show its assigned content
thanks for your help now back to do voodoo
For complex add/edit forms, I find the most user-friendly practice is to break them into tabs.
You can also use package elements to break a form up, maybe an element for each tab.
Then in the controller, break the processing out into separate models and libraries.
The same strategy applies to single pages.
The real decision is whether you may want to put other content on the page, or use a block elsewhere, or edit the rest of the page about the custom form/functionality.
There are some neat jquery wizard plugins that make a big form appear like a multi-step wizard, leading a user through stages of data entry and validating as they go.
You can also use package elements to break a form up, maybe an element for each tab.
Then in the controller, break the processing out into separate models and libraries.
The same strategy applies to single pages.
The real decision is whether you may want to put other content on the page, or use a block elsewhere, or edit the rest of the page about the custom form/functionality.
There are some neat jquery wizard plugins that make a big form appear like a multi-step wizard, leading a user through stages of data entry and validating as they go.
yeap im using tabs, but controller gives me hell if i call anything but save() and the php code was getting too nasty for my taste so i prefer a more mainteinable solution by using and adding some fields to my db to handle the Blocks id link to the content.
in my case i cant use jquery wizard since the data load is not sequential enough and i need every write operation generates an inmediate read operation in many parts of the form or forms
so for now pages will do just fine and that way i can embed html5 code / css3 easier than using c5 form widgets and the code is way more readable too, especially in for css
in my case i cant use jquery wizard since the data load is not sequential enough and i need every write operation generates an inmediate read operation in many parts of the form or forms
so for now pages will do just fine and that way i can embed html5 code / css3 easier than using c5 form widgets and the code is way more readable too, especially in for css
keeping it alive