It looks like you're new here. If you want to get involved, click one of these buttons!
Take a look at this example for building forms in Elefant:
Elefant provides automatic protection against things like CSRF attacks so you don't have to worry about the safety of your forms, and you can control access to members only by adding this to the start of the file:
Now that form is password protected. From there it's just a matter of creating the database entry in the form handler function, which can be done either by creating a model object (example here) or just directly running an SQL insert query, for example:
'insert into my_table values (?, ?)',
I have those pages setup that way now...I am using the require_admin for the new entry page and require_login for the job list page. That works well. I am going to look at your example and see what I can come up with. Where do you actually change the links so that when Submit is clicked it knows to use the new handler that I create? I tried finding out how to change the number 1 next to the details link so that I can see the info but it gives me a 500 error.
Just installed the app using elefant build-app joblister so I am going to work from here I guess and see what I can come up with.
One other question...how much would it cost you to write the job lister app for me to install on my end? I am somewhat grasping the concept but still heavily confused. I have so many answers that need to be answered. I wish you had tutorials and programming elefant 101 on audio cd
I would need a full description of what you need written (list of screens and their purpose and access restrictions, fields to be inserted/displayed, any emails to be triggered on insert, etc.). Send me an email or PM and I can see what I can do.
It's hard to document a framework to the right level for everyone, since a lot of the easier bits can be found on other sites and apply to PHP in general, but solid examples are pretty key in all cases. If you find specific spots that you get stuck on, post them to the forum and we can see about filling in the gaps :)
In the form handler example, there is a bit of "magic" happening behind the scenes. Specifically, the constructor grabs the current handler name (e.g., myapp/myform) from the controller object (aka $this in line 4). It uses the handler name to auto-load the validation rules from a matching file in the app's forms folder, and to find a matching view template in the views folder of the same app. This eliminates two lines of code for you:
$form->rules = parse_ini_file ('apps/myapp/forms/myform.php', true);
$form->view = 'myapp/myform';
From there, the handle() function either displays the form by calling echo $tpl->render($form->view, $form->data), or calls the function you just passed to it to handle the form submission.
echo $tpl->render($form->view, $form->data)
In the end, it just means a lot less PHP code to setup a form, with the rules defined in apps/myapp/forms, the form submission handling found in apps/myapp/handlers and the HTML kept separate in apps/myapp/views.
Now I've messed up the new entry page. It is showing results same as the job list page instead of the form. The dynamic object isnt letting me choose a form its just putting in appname/listresults
Message sent on this site to you.