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
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 have the following code to pull in two different categories but this outputs 6 separate files and I would like the output to be just one. How can this be done in AEM 6.0?
<clientlib data-sly-call="${clientLib.js # categories=['cq.foundation-main','cq.shared']}" data-sly-unwrap />
Thanks
In AEM, a category include will merge and compress all the files into a single js (or css) include. This is done per category include.
If you want to merge multiple categories, you should consider using the embed option in categories dependencies. How this works is:
Create a new category (for e.g. cq-embed)
Define embed dependencies ('cq.foundation-main','cq.shared') for the new category you have created.
Reference your new category.
You can also use this tool from ACS to optimise the includes:
https://adobe-consulting-services.github.io/acs-aem-tools/features/clientlibs-optimizer/index.html
It allows you to create the embed categories and reference them in a much cleaner way.
I feel like I'm missing something obvious. In working with v0.6.0, the Readme indicates you can use:
{%= partial("partial-name") %}
However, these are just getting printed as plain text. Do I need to use a different engine if I want to have those tags parsed?
Assemble allows using different engines and the example that you have is using lodash with custom delimiters.
To use the default partials helper in handlebars do {{partial "partial-name"}}
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])
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");