I'm wondering how to split a controller.js file? We've a folder "abcd, in this folder we've "controller", "view", "manifest.json" as well as "Component.js" and in that "controller" folder, we've only one file called "File.controller.js". This is a very big file, that's why I want to split/extend this file. Could anyone please share your knowledge here? Thanks a lot in advance!
The mechanism for this is similar to extracting new classes in Object-oriented programming languages. Once you find cohesive pieces of code that can be extracted as a separate component, you can choose to create a new file e.g. "ExtractedComponent.js" that has the following structure: e.g.
sap.ui.define([], function() {
"use strict";
// implement the extracted functionality here
...
}
and then you can use this extracted component as a dependency in your controller. Just add it to the File.controller.js correctly, e.g.:
sap.ui.define([
...,
/path/to/extracted/component/ExtractedComponent.js
...],
function(..., ExtractedComponent, ...) {
...
});
and then use it wherever necessary. To name a few examples, we extracted such reusable pieces of code that manage filters, date formatting, OData clients, etc.
Related
I am just starting to migrate some of my applications from Zend#1 to Zend#3. All is working fine, but regarding the views I've some trouble understanding the underlying concept.
As the tutorials suggest my project layout is like this:
module
Application
view
application
index
main.phtml
foo.phtml
baz
index.phtml
I'm wondering why you need to dublicate the "application" folder inside the view directory - you are already in the directory hirachy of the module. Is there a way to change the search path for the default template resolver so that the module name is omited? Just relying on the viewManager's "template_path_stack" is not working. Do I really need to write a custom resolver here?
Thanks a lot!
PS. Nope, I do not want to use custom template maps here ;-) I want to understand and use the default revolver without template maps, if possible.
"Application" is the name of a module in your overall 'application.' At the start, "Application" is the only module, but it is common to add other modules: you might have a module for "Clients" and another module for "Vendors." The hierarchy of the view folders follows the same hierarchy as ModuleName:ControllerName:ActionName, and ZF needs to use the module name in the view folders hierarchy in case you happen to have identical controller and action name pairs in two or more modules. It is likely that a "Clients" module and a "Vendors" module will both have an "index" action. It is less likely that the two would have identical controller names but it's not completely out of the question. If you had a controller named "Contacts" in both a "Clients" module and a "Vendors" module, "contacts/index" isn't enough information to tell ZF which view to use. It needs the module name in the folder hierarchy to distinguish between "clients/contacts/index" and "vendors/contacts/index".
UPDATE
Something to wrap your head around is that ZF3 takes things like router definitions, view folders and who knows what else from all of your different modules and aggregates them into a single structure. In other words,
module
Application
view
application
add
add.phtml
delete
delete.phtml
edit
edit.phtml
index
index.phtml
module
Clients
view
clients
add-client
add.phtml
delete-client
delete.phtml
edit-client
edit.phtml
client-index
index.phtml
module
Vendors
view
vendors
add-vendor
add.phtml
delete-vendor
delete.phtml
edit-vendor
edit.phtml
vendor-index
index.phtml
gets recognized somewhat like this:
module
....
view
application
add
add.phtml
delete
delete.phtml
edit
edit.phtml
index
index.phtml
clients
add-client
add.phtml
delete-client
delete.phtml
edit-client
edit.phtml
client-index
index.phtml
vendors
add-vendor
add.phtml
delete-vendor
delete.phtml
edit-vendor
edit.phtml
vendor-index
index.phtml
and you could probably put all of your view files into a single module if you wanted to.
Perhaps this helps explain why a folder with the module name is included beneath the "view" folder. The folder with the module name that is above the "view" folder has a storage function. The folders with module names below the "view" folder serve as a means of referencing which modules the view files are associated with in the aggregated definition.
Found one possible solution!
In your module's config add this one to the view_manager::
'controller_map' => [
'Dashboard\Controller\DashboardController' => 'Dashboard'
],
Instead of looking for a template called "Dashboard/view/dashboard/[controller]/[action].phtml" the framework will now look for "Dashboard/view/[controller]/[action].phtml". Basically you are telling Zend to use some kind of shorthand here and strip the array's value from the template resolution (have a look at InjectTemplateListener::mapController())
Anyways... a better solution and explanation is welcome!
I'm using Play framework 2.2.4 and Scala templates. I have created base Scala template with many code blocks, which I want to use in multiple views. Something like:
base.scala.html
#()
#display(product: Product) = {
#product.name ($#product.price)
}
products.scala.html
...
#display(product)
...
How can I import such file in view to use #display block?
Each view fragment should be in it's own file, with it's own parameters declared there. A Play template is supposed to work like a single function, not many. Instead, create a directory called base, and separate the view fragments into separate files.
views/base/display.scala.html
#(product: Product)
#product.name ($#product.price)
views/products.scala.html
...
#base.display(product)
...
Put it in a separate file, display.scala.html and make it the only/actual template, the file name is the fragment/function name:
#(product: Product)
#product.name ($#product.price)
if in the same package just call it
#display(product)
or if in another package either use full package name or import it first
#some.package.display(product)
#import some.package.display
#display(product)
Take a look into templating doc, section: Tags (they are just functions right?)
In general you can i.e. move your block to views/tags/displayProduct.scala.html (and use it as common template) so you can use it in ANY view with:
<div class="product">
#tags.displayProduct(product)
</div>
I am new to Play Framework and still trying to wrap my head around some things with the new Scala template engine.
Let's say I have the following package structure:
app/
app/controllers/Items.scala
app/models/Item.scala
app/views/layouts/page.scala.html
app/views/item/show.scala.html
app/views/item/details.scala.html //partial
And this is my item/show template:
#(item: Item, form: Form[Item])(implicit flash: Flash)
#layout.page() {
#*want to include details partial, wont work due to item param*#
#item.details(item)
}
Since including another template (e.g. including item/details above) is the exact same syntax as accessing a template parameter (e.g. item above), obviously this existing naming convention won't work without something changing.
I know I can rename my "app.views.item" package to "app.views.items", and rely on singular/plural forms to differentiate the view from the param name, but this does not seem like a very straightforward solution. Also what if I really want the parameter name to be the same as the view package?
One idea I have is to prepend all my views with an extra top level package:
app/views/views/item/details.scala.html
So the include syntax would be #views.item.details(), but again this is obviously a hack.
What is a good way to avoid this issue? How can I better organize my code to avoid such naming collisions?
Most other template engines use operations like "include" or "render" to specify a partial include. I don't mean to offend anyone here, but is the Play Scala template engine syntax so terse that it actually dictates the organization of code?
3 solutions:
First
Typpicaly for partial templates you should use tags as described in the docs, where app/views/tags folder is a base:
file: app/views/tags/product.scala.html
in the templates (no initial import required in the parent view full syntax will allow you to avoid name-clash: #tags.packageName.tagName()):
<div id="container">
#tags.product(item)
</div>
Of course in your case you can also use packages in the base folder
file: app/views/tags/item/product.scala.html
<div id="container">
#tags.item.product(item)
</div>
I'm pretty sure that'll solve your problem.
Second
To avoid clash without changing package's name you can just rename the item in your view, also I recommend do not use a form name for the Form[T] as it can conflict with helpers:
#(existingItem: Item, existingItemForm: Form[Item])(implicit flash: Flash)
#layout.page() {
#item.details(existingItem)
}
Third
If you'll fill your Form[Item] before passing to the view with given Item object, you don't need to pass both, as most probably you can get data from the form:
#(itemForm: Form[Item])(implicit flash: Flash)
#layout.page() {
<div>Name of item is: #itemForm("name").value (this is a replacemnet for ##existingItem.name </div>
#item.details(itemForm)
}
Of course in you product.scala.html you'll need to change the #(item: Item) param to #(itemForm: Form[Item])
What is the best way to structure or package a view helper that will display a reusable flash chart based on passed data?
Should the structure looks something like this, or is it overkill? I would like to keep the files separate from the general public app files.
-application
---module
----default
------views
--------helpers
----------MyFlashChart.php
-public
---images
---css
---js
---default
------views
--------helpers
----------MyFlashChart
------------js
------------css
------------images
------------swf
I guess technically I will be using a partial in combination..
Read the docs:
http://framework.zend.com/manual/en/project-structure.project.html
I am trying to implement a templating sytem in zend framework.
I basically use to put all the partials files and template variation in one file, but as the templates are increasing this is beign highly unmanageable.
for example
/application/layout/script/template1partial-banner.phtml
/application/layout/script/template1partial-footer.phtml
/application/layout/script/template1variation1.phtml
/application/layout/script/template1variation2.phtml
/application/layout/script/template2variation1.phtml
/application/layout/script/template2variation2.phtml
You can see, how unmanageable this is
so i want to manage it under this structure
/application/layout/script/template1/partial/banner.phtml
/application/layout/script/template1/partial/footer.phtml
/application/layout/script/template1/variation/1.phtml
/application/layout/script/template1/variation/2.phtml
/application/layout/script/template2/partial/banner.phtml
/application/layout/script/template2/partial/footer.phtml
/application/layout/script/template2/variation/1.phtml
/application/layout/script/template2/variation/2.phtml
Well defining the partials is not a problem, you can just use $this -> render($this -> getTemplateName()."/partials/banner.phtml");
Its the variations, that is main problem
I used $this -> _helper -> layout -> setLayout('template1variation1'); before, but for the new thing I can't use it, now.
How can i do something this?
You can also define a complete path in your layout function.
$this->_helper->layout->setLayout('template1/partial/banner');
One Other way to do this task is to disable layout for your current action and then render it to any phtml file. For example first disable layout for current action
$this->_helper->layout->disableLayout();
Then just render to any html file like this
$this->render("complete path to your phmtl file");