I'm a developer and I am very confident with MVC pattern and have already developed a lot of webapp from scratch using php framework like symfony or yii.
I'm a little bit confused about joomla mvc and terminology and after googling a lot, read joomla book extensions guide, read on joomla website my doubt are still there.
What is confusing for me is the component mvc structure and how I have to set up "my way of think" about joomla mvc, for doing the things in the joomla way.
In particular I am used to reasoning in terms of controller/action (like in symfony and yii framework)
So the final list of all my webapp url will be
controller1/action1
controller1/action2
controller1/action3
controller2/action1
controller2/action2
Each controller's action will decide what view to render and what layout to use for showing the view.
In particular in these frameworks, the definition of a layout is exactly the mean of a layout. And the view is the "core part" of the page.
So I can have a view with a list of users and I can put this view inside a mobile layout or a desktop layout, or to build a view for mobile and put it only in the mobile layout and so on.
The final result about directory structure in my webapp is something similar to the following:
controllers/
controller1
controller2
controller3
models/
modelForTableA
modelForTableB
views/
controller1/
viewForAction1
viewForAction2
layouts/
mobileLayout.php
desktopLayout.php
and for me is very clear to understand.
So finally my questions are:
how would be the directory structure in joomla?
what are in joomla the definition of view, layout and task?
I need to clarify that I do not need an explaination about MVC works in general, but if I would achieve the same result as before, how I have to organize my code and my work?
Suppose that I want to build a component with the following "url"
userController/addUser
userController/editUser
userController/listUsers
userController/viewUserDetail
anotherController/addOperation
anotherController/editOperation
anotherController/myNonCrudOperation
Thank you very much
Routing in Joomla is slightly different. The SEF URLs are built from menu items, which in turn point to a View/Layout combination.
This turns things around: a controller is not bound to a specific View/Layout.
Let's make an example of the flow with the addUser functionality you mentioned as an example; I'll be referring to these files (but you'll have plenty more):
/controllers/user.php
/models/user.php
/views/useradd/view.html.php
/views/useradd/tmpl/default.php
/views/useradd/tmpl/default.xml
/controller.php
/router.php
As you can see the layouts are inside each view's tmpl folder.
router.php
Let's start from this last file: router.php defines our custom SEF rules so, after Joomla passes the call to our component (usually with the params
?option=com_componentname) we can takeover and interpret the URL as we wish. It is a bit hard to get started with but does provide the most flexibility and power. We don't really need to implement it at all for this simple example: so back to our registration now.
First step: show the "new user" form.
You would typically bind this to a menu item, pointing to the /views/useradd/tmpl/default.php; the /views/useradd/tmpl/default.xml contains the definition of the layout so it's available in the menu manager. Very often there is only one layout per view.
Control is passed to the view /views/useradd/view.html.php , and the view will then load an instance of its own model (automatically chosen based on the view name, you can load other models of course) to gather any initialization data.
The view then renders the layout, and presents it to the user.
The layout's responsibility includes generating a form with an appropriate action (endpoint) and security tokens if appropriate:
<form action="index.php?option=com_mycomponent">
<input type="hidden" task="user.save">
<?php echo JHtml::_('form.token');?>
as you see it doesn't really matter if you want to use <input or params on the url, and you can most often mix them.
Form interaction
For autocompletion the form may need to invoke some backend controller methods, i.e. the method emailAvailable() in the /controllers/user.php
It does not make sense to have such functionality indexed, so we'll invoke the method directly with a non-SEF url:
index.php?option=com_ourcomponent&task=user.emailAvailable
followed by any other parameter. This will work in both get and post.
The controller /controllers/user.php's emailAvailable() method will return a json structure and then invoke exit() as we don't want the CMS to kick in at all. An alternative solution is to add the param &format=json in the call.
{"email":"johndoe#example.com", "available":true}
Saving the data
When the user submits the form, processing is first handled by the controller since a task is specified. (see above task=user.save). Joomla will invoke the method save() in the controller /controllers/user.php.
This time, however, our controller is responsible for returning information to the user. After processing the data, it may choose to re-render the registration form showing an error, or a thank you page. In either case the controller simply sets the redirect, letting Joomla handle the rendering when appropriate.
$this->setRedirect(JRoute::_('index.php?option=com_yourcomponent&view=useradd', false));
More control
Each time a controller task is not specified, the display() method of the main controller is invoked. You can add custom logic there.
Joomla fires several events during a view rendering; these can be intercepted by a system plugin or - if you add in the calls - other kinds of plugins as well. You may even create your own types of plugins. Do not try to instantiate a view manually from a controller, as this may inhibit plugin firing.
Small insight,
1) Directory Structure
controllers/
controller1
controller2
controller3
models/
modelForTableA
modelForTableB
views/
layout1
2) View and layout and task
check this answer
3) More routing techniques with SEF.
Hope it helps.
solved with this. I cannot delete this question because there already exists other answer.
Could any moderator close or delete this? Thank you
https://joomla.stackexchange.com/questions/18774/joomla-terminology-view-layout-task-and-component-development/18799#18799
Related
Say I have a list of Action objects, which corresponds to a Ember model. Each has a few properties (timestamps) and a detail attribute, which can can recursively contain more details (arbitrarily deep nesting). You can think of the details as nested lists.
I want to write a UI that allows easy editing (auto completion of values, easy copy and paste, reorder elements, etc) of the detail for any Action object.
Right now, my DetailView template will recursively render additional DetailViews:
{{#if view.content.hasChildren}}
{{#each child in view.content.children}}
{{#DetailView contentBinding=child}}
{{/each}}
{{#else}}
{{#EditDetailView contentBinding=view.content.value}}
{{/if}}
So each DetailsView corresponds to a node in the Details object tree.
But I am unclear how to add controllers to the mix -- there is additional state I need to store / functionality to implement (e.g., transforming values from the Detail object for display in the DetailsView; handling events for inserting/deleting/reordering elements; changing the structure of the Details tree) that belongs neither in the model nor the view.
Ideally I would have a DetailsController serving as a proxy a Details per DetailsView. Can I dynamically instantiate controllers and set up their contents within a view template? My understanding of the new Ember Router is to setup controllers and outlets in in a given route; however, that doesn't seem to apply here because no routing is being done at all. All suggestions / insight about how to handle recursive controllers / views / routes welcome.
I've taken a look at EmberJS Nested Views and Controllers, but that proposes I have a single ArrayController for all Details, even across Actions ... this would not preserve the tree structure of the nested details either.
I've also looked at Recursive view in handlebars template not working after upgrading to Ember 0.9.6 but the solution doesn't say anything about controllers.
** UPDATE Feb 20, 2013 **
API documentation for the {{control}} helper is now available here. It warns that "The control helper is currently under development and is considered experimental."
To enable it, set ENV.EXPERIMENTAL_CONTROL_HELPER = true before requiring Ember.
** UPDATE Feb 3, 2013 **
A new helper {{control}} has been added to ember, implementing the Reusable Views proposal. So to have a DetailsController proxy a Details per DetailsView you can just:
{{control 'detail' child}}
See the {{control}} tests for example
Ideally I would have a DetailsController serving as a proxy a Details per DetailsView. Can I dynamically instantiate controllers and set up their contents within a view template?
Typically the way to do this would be via the handlebars {{render}} helper, which renders a template with an appropriate view and controller. Unfortunately you cannot use {{render}} to insert the same template more than once, so it cannot be used within an {{each}} block.
There was a lengthy discussion on the topic recently. See: Non-Singleton Controller Discussion!
Two solutions were proposed. The first involves adding an itemControllerClass property to ArrayController. If this property was set, the ArrayController would automatically wrap new contents in the specified class. This was added to ember a few weeks ago and takes care of most use cases, where you have a flat-list of items and want each to be wrapped in a proxy.
The second proposal, Reusable Views, allows you to provide a controller class to a view.
{{view UI.Calendar dateBinding="post.startDate" controllerClass="App.CalendarController"}}
This would create an instance of App.CalendarController for each UI.Calendar widget, which would be tied to the lifecycle of the widget. As of today this has not been implemented. See {{view}} should have an option to create a controller! for the latest status.
So AFAIK there is not a good way to accomplish this for the use case you outlined. Meantime, binding data to the view:
{{view App.DetailView contentBinding="child"}}
and then having some logic in the view itself seems reasonable. If/when Reusable View support is added to master you can pull that logic up into the controller.
See: https://github.com/emberjs/ember.js/issues/1766
I have a regular view I'd like to use in another page, appearing magically in a jQuery-like accordion if the expand button is clicked. If I call it using:
Html.Partial(A_non_partial_view, new view_model_used_by_the_non_partial_view())
...does that have a chance of working, or is MVC not plumbed that way? (I'm using MVC 3 if that helps.)
You can, but only if it is in the same controllers views folder or in the shared views folder. otherwise you will have to specify that path fully which isn't practically really.
If you use Html.Action or Html.RenderAction, then that action will need to return a PartialView otherwise it will push out a full html page again with head tags etc etc
Imagine I have a form (Page1.cshtml) with 1 link (LinkBrands). I also have a controller for Page1 (Page1Controller) and one for brands (BrandController). When the user clicks the link what is better to do:
LinkBrands-->Page1Controller-->BrandController (Page1Controller's action will redirect to BrandController)
OR
LinkBrands-->BrandController
Not sure what route is better. Any suggestions?
Usually you don't have a single controller per view. You would use multiple views or partial views all calling actions on the same related controller. I assume Brand is a separate entity from whatever else Page1 is trying to display, therefore it should probably use the BrandController directly but since there really isn't enough information to go on with your example as to what page1's function is I couldn't say what you are trying to relate.
If you need to capture information from the brand link as it relates to page1 then sure have it collect that in page1controller first before redirecting to brandcontroller to display a new view.
What does your Page1Controller do?? It seems as though you are defeating the purpose of the Model-View-Controller architecture and trying to form it back to the WebForms method with code-behind.
So without seeing what exactly your controllers are doing, I'd say your second option is best.
It all depends.
If you have to execute any logic in Page1Controller (saving data for instance) before displaying the second page, then you need to go by Page1Controller, and then go to BrandController:
LinkBrands-->Page1Controller-->BrandController
In case you just need to redirected to the second page (you do not need anything from Page1Controller, you do not need it to perform any action, and you can create a the model for second page in BrandController) then go with the second option:
LinkBrands-->BrandController
Hope this helps.
I'm new to MVC and I'm introducing myself through the Codeigniter framework. As a practice application I'm creating a simple blog application that gives the ability to create, view, edit, and delete posts.
For the "edit post" page, I'm using the same view file as my "create new post" and simply populating the form fields with the data I'm getting from my model when the user is editing an old post.
This seems all fine and dandy but I'm a bit confused on what logic is stored in the Controller vs. View. I obviously need some logic that tells the form to pre-populate the form fields (if I'm editing a post) or to leave everything blank (if it's a new post). There's also other things such as the view page needs to know what title to display at the top of the page: "Create New Post" or "Edit Post".
Where does this logic go? Does it go in the View? Or does it go in the Controller? and Why? I started putting all that logic inside the view file because I've read that I should keep the controller code minimal, however I now have a big php code block at the top of my view file that's dealing with variables and I'm not sure if this is the correct approach.
Any advice would be much appreciated!
I obviously need some logic that tells the form to pre-populate the form fields (if I'm editing a post) or to leave everything blank (if it's a new post).
Check out the set_value() function in the Form Helper. You can do something like this in your view:
<input type="text" name="subject" value="<?php echo set_value('subject', $subject); ?>" size="50" />
If it's a new post, pass empty string as $subject when loading the View from the Controller.
If it's editing, pass the subject of the post that is being edited as $subject.
Also, if a user submits the form and there are errors and you need to reload the form, set_value() will return what the user just posted (i.e. $_POST['subject']).
There's also other things such as the view page needs to know what title to display at the top of the page: "Create New Post" or "Edit Post".
Just pass a variable named $page_title from your Controller to your View, and set the value accordingly. This is pretty common, especially when you start building reusable templates.
Where does this logic go? Does it go in the View? Or does it go in the Controller? and Why?
There should be almost no logic in the View. Maybe simple if/else statements if you must, and loops to iterate through arrays of data.
Even Controller should not have much logic in it. It is mainly responsible for acting as a middle-man between the Models, the Views and the libraries.
I've read that I should keep the controller code minimal
That has to do with Controllers vs. Models, not the Views. It is good practice to keep Controllers smaller, and put as much of the logic as possible into the Models and the libraries. Also referred to as "Skinny Controllers, Fat Models".
I know how to use Zend_Acl to allow certain resources to certain usergroups but how do i use it to allow only specific parts of the page to be shown? For example
I have a button to delete a post via AJAX on the page but i only want to show the button to Admins only. I can use Zend_Acl to block access to the controller post/delete but i can't use it to block the button from showing.
// in controller
$this->view->allow_delete_post = $acl->isAllowed($role, 'delete_post');
.
// in template
<? if ($this->allow_delete_post): ?>[button html]<? endif; ?>
Would that not do it?
You can also write a custom static ACL class which you can then call directly from within your view script.
Since ACL is normally handled at plugin level it means that if your visitor is seeing the view then ACL has already allowed the resource, therefor inside your view you can now do something like this...
if(My_Custom_Acl::getIsAllowed('some_resource', 'delete_post_action'){
I did not specify the role name in the custom getIsAllowed() method, because at this point ACL is already suppose to know the user's Identity and the Role.
Hope this helps
Although Christof gave a good solution, an alternative is to split the views. Although this starts to violate DRY, when you have about 200 different admin things/controls, it's getting heavy in the view - thus splitting the view with $this->render('view') and $this->render('edit') for permissions from the controller is sometimes easier. Then only the edit view script has the edit links. But again, it's DRY, so not optimal, but an alternative. I guess you have to weigh it up, which one is more DRY, repeating the ACL check or the stuff in 2 views...