I tried to use this backbone extension for making stackable modals.
http://awkward.github.io/backbone.modal/
It says is compatible with Marionette and so i been trying to use it with views that i create with it. But the problem it seems that it doesn't allow me to use eco templates and the examples in the website are only with underscore templates.
For declaring Marionette views using eco templates all i need to do is this :
class Views.ItemView extends Marionette.ItemView
template: "items/show/templates/item"
But i can't define the template that way for the Backbone.Modal view class, also i can't pass a view into the template and i tried to use the views stackable part but i'm very lost with it.
Thanks for your time and answer.
If you're wanting to use eco templates with Marionette you'll need to do something like this before your views and after Marionette:
Backbone.Marionette.Renderer.render = (template, data) ->
throw "Template #{template} not found" if !JST[template]
JST[template](data)
The default template renderer assumes that the template is a function and just calls it with the output of serializeData and templateHelpers
If you don't want to define the custom renderer you should be able to change your template line to something like this:
class Views.ItemView extends Marionette.ItemView
template: JST["items/show/templates/item"]
Related
Using the AMD and module paradigm used by UI5, I want to use separate JS classes in distinct JS files to separate my ajax code from the related controllers.
A foundation class will be concerned with common activity such as generic error handling whilst specific classes extending from this will deal with subject-specific ajax communication only. This will NOT be a custom control so no requirement for render capability, metadata, etc.
I wish to benefit from the sap.ui.define functionality and also want my new class to be good UI5 citizen. For example I want to fire my init when the class is instantiated.
Which sapui5 class or classes should I extend from? I am currently using sap/ui/base/Object but would like to know if there is a better choice based on better performance or better fit to purpose.
I am aware of the documentation on custom controls but this seems to focus only on details of classes that render to screen.
This is the skeleton of my current approach:
sap.ui.define(['sap/ui/base/Object'],
function(BaseObject) {
"use strict";
var AjaxBase = BaseObject.extend("myAjaxBase", {
constructor: function(oControl) {
BaseObject.apply(this);
console.log("AjaxBase.constructor() fires")
}
})
AjaxBase.prototype.init = function() {
console.log("AjaxBase.init() fires")
}
return AjaxBase;
}, true)
You can use sap.ui.define even for objects which do not extend sap.ui.base.Object. So if you do not really need functionality provided by UI5 objects you are not forced to extend them. However, in your case it looks like you want to use event support and in this case it would be useful to at least extend sap.ui.base.EventProvider.
As you want to separate backend calls from your controllers it looks like you are using a JSONModel and have more complex use cases than just reads. In this case you could also extend the JSONModel with support for create, update and delete operations.
I'm writing a MVC portlet framework and I plan to use Rythm inside my views. I would like to pass various arguments to the view and was wondering if there is a way to declare these arguments for the view using Java at runtime? I know that I can declare arguments in the view using the #args tag and that I can add custom tags from Java, but I wanted to do something similar to how ASP.NET MVC passes helper classes (HtmlHelper #Html, UrlHelper #Url, Object #Model) to the view.
If all the arguments you planned to pass to the view are global (i.e. they applied to all render session and to all templates) then you should treated them as implicit variables, meaning template author don't need to declare them but they are free to use them. Examples of implicit variables are session, request, context etc.
For how to declare implicit variables, you can refer to:
Spring-rythm
Actframework
For how to configure Rythm engine with your implicit variable, refer to
Spring-rythm
ActFramework
For how to inject implicity variables into rythm engine for each render session, you can also refer to:
Spring-rythm
Actframework
For things like HtmlHelper my recommendation is to provide reusable rythm template as tags instead of Java object. Because you need to render html snippet, thus using rythm is a natural way to go instead of let the Java code to output the content.
For things like UrlHelper if it is all about String manipulation, you can go straight with Java code, but probably the public static method is more appropriate than helper instance
I want to have something like
Routes
GET /endpoint pathToTemplate.templateName.scala.html
In order to avoid the need to create a controller just to serve this template.
I need a template because I am serving up values using an imported scala library so this can't just be static html
#import tool.values._
<p>
#Tool.getValue()
<p>
It is impossible to achieve your desire solution but you can to make a workaround with one controller and the dynamic URL parts mapping.
Firstly create a controller which serves a view for any provided path. Route definitions must be placed in code for example with usage of a simple hash map instead of the route file.
object GlobalController extends Controller {
private val getRouterMap = Map(
"view1" -> views.html.view1(),
"view2" -> views.html.view2(),
"sub/view3" -> views.html.view3()
)
def route(path: String) = Action { implicit request =>
Ok(getRouterMap.getOrElse(path, views.html.notFound()))
}
}
Secondly at the end of the route file define a mapping for the created action as follow.
GET /*path controllers.GlobalController.route(path)
It is very important to put it as the last line. Otherwise it will shadow all other mappings defined below.
Hint
Anyway if I ware you I would reconsider your design. Singleton objects aren't easily testable. Sooner or later they will make your life really painful.
I know there are view controllers and action controllers. I think that view helpers can be used from views and action helpers used from actions in controllers.
I need a class that at bootstrap or wherever, it initializes a number of configuration options, arrays for things like convert month numbers to their names and role numbers to their names.
How can this be achieved?
Put them in a model and use it anywhere you like by instantiating it and calling its helper methods. All model files are auto loaded whenever you call them.
Have a model Constants.php:
<?php
class Constants {
public static function convertMonth($month) {
doLogic();
return $something;
}
}
?>
In your controller or view:
Constants::convertMonth(12);
You could build a Resource Plugin and then add it to yout bootstrap class.
The Constants class or Resource approaches both work nicely. However, I recently had to undo/upgrade a Constants class based solution to meet new requirements, so you might want to consider your future plans before going down those paths.
Specifically, if you ever intend to support multiple languages, or even different words for the constants in different contexts, check out Zend_Translate API docs, Zend_Translate example, or this blog post.
I would like to make a global Zend_Log object that I can reach from my Controllers and my Models.
What should I add to my Bootstrap? (My bootstrap extends Zend_Application_Bootstrap)
How then can I reach the logger object from my controller actions and from my model?
As you do with any other class - assign it to the Zend_Registy. I'd suggest setting like this:
Zend_Registry::set('Zend_Log',$logInstance);
This is a common way, which is used also for translate (set translate instance to 'Zend_Translate' and classes like forms and validators will find it automatically).
You can use Zend_Registry::get('Zend_Log')->log(...) to log anywhere you want. It's not very good from the point of architecture (you should not use normally), but for log - which can appear practically anywhere in the app from view helpers to controllers and models it's a good thing.