I built a custom component for Joomla 1.5. It' an FAQ component.
I'd like to let users add questions from the Front-End.
I have several fields that shouldn't be displayed for the user on the front end.
For ex. in the back-end admin has fields like Approved, Ordering and Published and the rest. I would like to let any user without signing in to add question front the front-end but these 3 fields shouldn't be displayed to the users on the front-end.
So, how to build the front-end user input?
Maybe someone has done that or know some good tutorial for this case?
In the view.html.php file of your component (eg. com_faq/views/view.html.php) you can define the mark up for your input field section. I build up a $html variable like:
$html .= '<input name="addQuestion" value="" type="Text"/>';
then add a reference to it:
$this->assignRef("addQuestion", $html);
so that in your view template (i.e. com_faq/views/tmpl/default.php) you can add it to your page like
echo $this->addQuestion;
When you click your submit button you can reroute back to the same view. So user a url like
index.php?option=com_faq&task=addQuestion&view=default
So before you mark up your page (so within the first few lines of your display function for example) you can grab the contents of your user's input on the front end
$question = JRequest::getVar('addRequest', null);
Once you have this you can either store it to your database or display it. Alternatively you can AJAX submit your form and process it in a controller function so the you don't have the refresh etc.
You will need to edit your router.php file to pick up the task and pass it to your controller i.e. set it as a task or a view.
There are loads of options for this but fundamentally there are 3 things you need:
Create your mark up in your view.html.php file and assign a reference to it
Include the reference in your template i.e. default.php
Submit your form to an address that your same component can process it i.e. index.php?option=com_faq&task=addQuestion&view=default
Hope this helps :)
Related
When we develop forms for CMS (for example an Add product page and a edit product page), we usually develop 2 pages. But this result in double work and harder in maintenance & amendment.
Is there any way that I can do a form to be reusable on both add / edit page with Laravel?
Thank you.
Yes, provided that your add/edit form is identical. Here's a brief idea on how it can be done:
Load the form using Form::model binding (http://laravel.com/docs/html#form-model-binding) which will populate the HTML fields with current values (for editing) or empty (for new form)
Add a hidden field in your form, like the product_id which is either loaded or generated depending on whether it is an edit/new form
Upon submission to your controllers you can use something like this:
//after form validation
$new = Product::firstorCreate(array(
'product_id' => Input::get('product_id')
));
//assign the rest of the fields
$new->save();
I hope that can give you an idea to solve your issue.
I use more obvious approach:
Former could be used both in views and controllers, so I use it in controller
I create simple private method that holds my form
Use it both in add and edit action
On any given page (It's used site-wide for different purposes) I'd like to call a function getMyForm() or something similar and this would render a several step selection process for a product. We only have this one product but it is quite a complex selection process.
If I wanted to implement this on one page only it would be fairly simple... but I'd like this selection process to be available on different pages, and it seems silly for me to recreate the form for each page used when it's only really the outcome after the selection process that will change for each.
How would I go about achieving this:
Should I have the form on it's own page anyway then link to it at the beginning of the selection process and redirect to the appropriate page after selection depending on the page the user first came from?
Use a service container or similar to render the form on the specific page, then use session attributes/variables to track which step the user is currently on, and refresh the current page after each selection.
Something completely different?
Additional stuff:
I want this to be functional without javascript/jQuery, but this
would be a nice addition in future so I don't want to rule it out if
possible.
The selection process is dependent on what was selected in the
previous step, so I can't just render the whole form in step one, and
some kind of refresh will be required.
First, i'd say you can't completely avoid javascript your selection process, if only for triggering change event on your selectors. Having user to manually trigger page refresh through some button doesn't seem like a good idea.
But if you're so inclined, you need to create a form controller with form builder, there just check a request and render a form accordingly.
For example, if no request is supplied it renders a starting form contains only one select and a submit button, and its action is simple submit to the same page. Main page controller includes a form controller, so form controller gets a request and renders second part and so on...
I have an action that renders search view to do search as the above search bar in this website, so its should be shown in every view.
I don't know what is the mechanism to do it. for example if I make the search action as a widget this will not be fine, because the results of search will be shown in the same position of the search widget ( at the top of website).
so, how I can make a search action that should be shown in every view in the website?
In order to resue same search function in everywhere, you need to create a widget.
I have explained briefly in How a widget works, then you can attach it in every view that you want.
If you don't have any idea to begin, check this out: Yii ESearch
Here are some references that would be useful:
how-to-use-a-widget-as-an-action-provider
actions-code-reuse-with-caction/
Yii Widget
If you want to add something to every view then you should add it to the layout. By the sounds of it you don't need to use a widget at all, although it would probably help with code maintainability.
You never mentioned a requirement for ajax so keep it simple and don't use it. When someone enters a search and clicks submit (or presses return) then the form submits to the SearchController. This way there is no need to have a search action in each controller.
If you particularly want the same action in every controller then create a Controller base class with that function in it and inherit from it to create all your other controllers.
I am working on a symfony 1.4 project and am trying to add a custom field in a backend form. At the moment, my module has a batch history with editing and deleting options for each row and a form that allows the user to filter through it. I would like to add a custom creation form and I am struggling to do that.
Going on the /*model_name*/new/ page does show me a form: this is the form I would like to make changes to.
I would like to display a dropdown list of elements from another table (and model) on this page. How can I do that knowing that the current module's widgetSchema doesn't have that relation?
Should I edit generator.yml? When I try adding a title: to new: , it doesn't seem to affect the /new/ page (even after cache:clear).
It would be easier if you create that relation in your schema.yml. Your generated form will be able to render the widget you want.
Otherwise, what you need to do is edit the *model_name*Form class by adding the widget and validator you want (sfWidgetFormDoctrineChoice and sfValidatorDoctrineChoice in your case)
The generator.yml uses the form *model_name*Form class by default, but I suggest you copy this class in a lib folder you create in your module, and edit this one instead. Then, you edit your generator.yml to use this new form, this is how you do it
Also, make sure there is not much rows in the table of your relation. Else, symfony will try to generate a html select tag with a lot of options and you will need to kill your php and even webserver processes.
Yes, you need to edit generator.yml, but in the form line:
# apps/backend/modules/whatever/config/generator.yml
config:
...
form:
display:
Whatever...
Here you have some examples. Taken from the official documentation:
http://symfony.com/legacy/doc/jobeet/1_4/en/12?orm=Doctrine#chapter_12_form_views_configuration
This way, the form that the generator uses will be the one you specify. And maybe you don't need to modify something else.
I'm writing simple website with some cms functions. It would be good to have all menu items and pages contents held in database.
I have table with id, name, parent_id and a content field. In future I would maybe move content to a content table to have multiple contents to menu item with fk. But it is not the case here.
The question is:
Do I need the URL field in menu table?
What else do i need to get it to work? Should every page have its own controller? I,m a beginner with zend framework, so please give me some directives. Thanks in advance.
Lets start with Question 2: every page does not need its own controller. If your pages are static you can even load every page using a single action. For more dynamic processing you could use a separate action for each page.
In any case, make sure you structure your code into controllers and actions in a way that makes sense. For example, inside your CMS a user might edit, create or delete a post. You could then create a PostController inside which you write an editAction, createAction and deleteAction.
You could store the URL in the table, but you do not necessarily have to.
Single action approach (mostly for static content)
Make sure the page id or name is stored in a GET param. You could then use the following code:
public function genericpageAction()
{
$thePageID = $this->_request->getParam('id');
// fetch the page content from the db based on $thePageID
// and pass it to the view
}
Of course, here, you could also match against the URL stored in the table if you chose that approach.
Multiple action approach (for more dynamic processing, most likely what you want with a CMS)
You could define a route for each page and load its content in the respective action. For example, for the page to edit a post:
class MyCMS_PostController extends Zend_Controller_Action
{
public function editAction()
{
// fetch the home page content
// do any further processing if necessary
}
}