I've created a sandbox with a demonstration of binding UI components to both data and state: http://dojo-sandbox.net/public/51073/1
It's my plan to generate code from a page definition creating a page-level widget which is templated. This widget will have its own scope, where the model and state will reside, which I am trying to simulate in the sandbox by way of the Page object.
The sandbox is working because the Page object is in the global state, which appears to be the default context for object resolution in mvc binding.
However the plan is to have a view widget supporting each page with both the Model and State contained within the widget's scope. The generated template for the view would be bound to both the Model and the State. I can establish the source via the 'target' property, but when the same UI component must be bound to two different models, one for value and one for state, the single source doesn't support this.
The Model data will come to me from the back-end, and the State data is derived via the State.Execute method once the Model data is present.
I've taken a look at the 'rel:' parameter of at(), but don't see how to leverage this syntax within a specific context, ie my view widget's scope. It seems to be working fine for the default global scope.
Is there a standard way to direct the data-dojo-props value binding at one source, and the data-mvc-bindings for attributes at another? Or, more precisely, what is the at('rel:') syntax which will support specifying the context of the relation, and not rely on the 'target' of the widget or containing widget?
If there is no way to specify the 'target' at this level, I will generate more logic in the Execute method to specifically set the html attribute on the component during state compilation.
data-mvc-bindings is for allowing non-widgets use dojox/mvc/at. If a widget is declared for an element data-dojo-props is the one for use instead.
If target is specified via data-dojo-props or data-mvc-bindings, it’ll be set eventually to the widget.target. ”rel:” syntax looks for a widget having .target up in DOM tree.
It means that one “group” cannot have more than one "relative binding target”, in case it’s one of your questions. You can have a “scope object” that contains pointers to more than one models and use it as a “relative binding target”, that may serve a similar purpose:
<div data-dojo-type="dijit/_WidgetBase"
data-dojo-props="target: {model0: model0, model1: model1}">
<input type="text"
data-dojo-type="dijit/form/TextBox"
data-dojo-props="value: at('rel:model0', 'value'),
disabled: at('rel:model1', 'disabled')" />
</div>
A working example can be found at http://jsfiddle.net/asudoh/M3bRC/. Hope these help.
Best, - Akira
Related
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
In Ember, if you want an action to be handled by a view, it's easy to achieve this using
<button {{action 'something' target='view'}}>
`{{view App.targetView}}` // this is the view in which the 'something' action ought to be handled
If you wanted the parentView to handle this, then target='view' gets replaced with target='parentView'
Fair enough, my problem is that I want a childView to handle and simply stating 'childView' yields
'Cannot read property 'send' of undefined '
I could choose to specify the name of the view in here, like :
target='targetView'
where
{{view App.targetView viewName="targetView"}}
that did not work. Neither did
target ='views.targetView' nor 'childViews.targetView'
Please don't guide me to change the semantic structure of my app by stating that the button with this action needs to be within the App.targetView template because that to me is a hack and messing with the semantic structure of my app.
What I do need to know is how I can use the target property to specify a specific view, not just the containing or parent view :) ?
To be honest, my instinctive response is "eek, don't do that". But, I'm going to suspend disbelief and stipulate that you have a good reason for wanting to do this.
The reason your approach did not work is that the target property path is evaluated in the template's context (which by default is the controller). Solution: use the view keyword in the property path and chain the viewName of the target view.
e.g.
<button {{action "foo" target="view.targetView"}}>Click me</button>
{{view App.TargetView viewName="targetView"}}
http://emberjs.jsbin.com/aGagORaz/1/edit?html,js,output
I'm playing with actions in Ember and I see that some people use targets that point to their controllers or their views like such:
{{action saveNote target="view"}
However, I also see that Ember supports event bubbling much like the DOM, in that events will work their way up to the application controller and router.
Is there a reason for specifying either "view" or "controller"? If I understand it correctly, the view/controller that the template's action belongs to will be the first in line to receive the event, so why specify it?
There's really no reason to target the controller, since it's the default target. Events not handled by the controller will bubble up from the controller to the routes.
However, if you want the view to respond to an action, you'll need to target it explicitly.
target="controller' is not needed ( anymore? )
target="view" can have many uses which are perhaps local to a specific view instead of belonging into a controller. Like toggling the display of an item.
But target also has other use cases like if you want to target a controller you have declared in needs which is then accessible in controllers.<nameOfController>
I can watch in a directive one object's property (actually - clientHeight). But how to change other object's padding-top according to this height? I know how to do this using jQuery, but I am looking for an Angular way.
In Angular one can access some page element using a directive. Ok, but how to access other page element in the same directive?
There are a number of ways you could do this. For all of the suggestions below, assume you have two directives – one for watching the clientHeight, the other for adjusting the padding.
Create a service (that is injected into both directives). Have the first directive modify an object property in the service (e.g., someObj.prop1). The other directive $watches that object property.
Use events. Have the first directive $emit or $broadcast an event and the second directive can listen for it using $on (in its link function or in its own controller).
If there is an ancestor relationship, you can require the ancestor directive's controller in the descendant directive. See AngularJS: reuse component with different parent for an example.
Not recommended, but another option: use $rootScope instead of a service: inject $rootScope into both directives. Have the first directive modify an object property on $rootScope. The other directive $watches that object property.
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