I have a controller which assigns data to the view via $this->view->assign('groups', $groups);
Those 'groups' are processed in the HTML template. Now if I'm not mistaken it must be that typo3 caches the whole computation flow of the controller somewhere. Because when I change those 'groups', they are not recomputed, meaning the HTML template does not get updated data. However if I change the HTML template directly, I see the updates. It's just that computation of 'groups' in the controller which doesn't get updated. How can I prevent typo3 from caching that whole cascade of "controller computes data and assigns them to the view"?
Related
Need: A dynamic template loaded from a DB
I need to present a JSON object via "template plugins" that will come from a database (defined outside the application itself). The plugin will be applied only if a plugin exists.
For this example, let's assume I have this object of type "Reservation" that contains a sub-object of type "Flight":
{
"id": "ABC-XYZ",
"reservationDate": "2020-09-23",
"state": "paid",
"flight":
{
"origin": "BCN",
"destination": "MAD",
"airline": "VY"
}
}
Rules
The controller will call a page template passing multiple objects.
The page template will "use" or "include" (see later more info) an object.html.twig and will display it.
The object.html.twig will do this:
If there's not any known plugin able to handle this type of object, the template will display a <pre> with the object converted to YAML. This will be mainly act as a "default" plugin or "fallback" plugin.
If there's a known plugin able to handle the object, the object will be sent to the plugin (which is not anything else than another twig template).
In this case, the plugin should be able to separate "parts" of "interpretable" results to make them "nice" and leave the rest into an object that will be, in turn, displayed again with the original "default" plugin.
If there are parts of the object that are in turn interpretable, they will be in turn passed to other plugins.
Example "desired" outputs
Sample 1. No plugin available
Sample 2. Plugin 'reservation' available. Interprets the state in green. Also removes the redundant data of the ID
Sample 3. Same than 2 but also plugin 'flight' available, able to process the flight block. Formats the texts and makes a lookup of the airline full-name
Sample 4. Plugin 'flight' available, able to process the flight, that in turn knows that the origin and the destination are "airports" and passes them into the corresponding nested 'airport' plugin, because they are "reusable" objects not only in the "flight" plugin but also in many other places in the application, so they are defined appart
What I have already explored
I know that doing it via 'include' it could work. But let's take a look at the differences between 'use' and 'include':
The major difference between include and use in twig is that:
When you include a template, it's direct HTML 'inserted there' where you can use the {{ }} operator for printing and {% %} for control flow (set variables, ifs, fors, etc.). The renderer will process it straight forward. But defining a new block via {% block myNiceBlock %} is forbidden.
When you 'use' a template, it's pre-loaded, and blocks are permitted. There's no rendering of the included block. Then, from the caller, you use a {{ block( 'whatever' ) }} to tell the renderer to go and render that specific block.
The 'include' is more rudimentary. The use allows horizontal reusing and allows itself to auto-organize itself with other sub-blocks called by the parent block, all in one single file.
For example, in the airports example, if there are N images, in a include you should put the wrapper HTML directly in the file, do a loop and inside the loop write the inner HTML.
Instead in the use approach you'd do an airport block which in turn loops over the images and just calls the block airportImage which is defined in another block in the same file, thus facilitating clean-coding.
Requirement
The application should not be re-deployed when new plugins are created. They must be loaded from a DB or any other dynamic system, as the plugins will be written by "users of the application" as they need it. No deploy allowed.
The plugins should be written in terms of a "block-able" twig template, so need to be 'use'-able.
Question
Discovering "which" plugin to call is not a problem. Assume that whoever (the controller, the twig itself, whoever really) can discover for this example that a "reservation" plugin exists somewhere. How can I use it from the page? When the reservation is rendering it "asks if a flight plugin" is available. If not, all to the YAML. If it is, how can then dynamically tell the reservation to use the flight?
In short: How do I force a template to dynamically use (not include) templates that, in turn, comes from the database (not from fixed files)?
NOTE: If this info is useful: I'm using Symfony 5 with webpack.
Thanks!
When generating forms with the form module the corresponding yaml files get stored in fileadmin/user_upload.
Now I want to integrate those yaml files into my sitepackage and thus into my CVS. Where is the correct place for them? In the example extension they are stored in Resources/... while I would think they have to go into Configuration/Yaml
And how do I configure the form extension to search them in that place?
While it's basically a matter of taste where exactly one saves his form definitions, I try to separate form configuration and form definitions.
From the official documentation:
[...] the form configuration allows you to define:
which form elements, finishers, and validators are available,
how those objects are pre-configured,
how those objects will be displayed within the frontend and backend.
In contrast, the form definition describes the specific form,
including
all form elements and their corresponding validators,
the order of the form elements within the form, and
the finishers which are fired as soon as the form has been submitted.
Furthermore, it defines the concrete values of each property of the mentioned aspects.
So, for more clarity I save all form configuration in a sitepackage under Configuration/Yaml/ and the form definitions under Resources/Private/Forms, neighbouring the templates.
I wrote a full tutorial how to use custom templates with EXT:form, which also includes the answers to your question.
In short:
Register YAML configuration with TypoScript in your extension root folder as ext_typoscript_setup.txt (as recommended1)
plugin.tx_form.settings.yamlConfigurations {
100 = EXT:my_extension/Configuration/Yaml/CustomFormSetup.yaml
}
module.tx_form.settings.yamlConfigurations {
100 = EXT:my_extension/Configuration/Yaml/CustomFormSetup.yaml
}
CustomFormSetup.yaml – setting up a new storage path
TYPO3:
CMS:
Form:
persistenceManager:
allowedExtensionPaths:
10: EXT:my_extension/Resources/Private/Forms/
allowSaveToExtensionPaths: true
allowDeleteFromExtensionPaths: true
1TypoScript inside an ext_typoscript_setup.txt is automatically loaded in both frontend and backend of your TYPO3 installation directly after installing your extension. This differs from other TypoScript files, which have to be included manually, e.g. as static templates. See official Form Framework documentation.
I'd suggest Resources/Private/Forms for your form definitions. The form extension clarifies how to register additional form definition paths.
I am building a multi-step application form with React. Having first built it with pure internal state I am now in the process of refactoring to Redux using redux-form.
Having used the example here as a basis: http://redux-form.com/5.2.5/#/examples/wizard?_k=oftw7a we have come a good way.
However the problem appears when i have two forms which are supposed to have the same value. During one of the pages i have a name field, that is supposed to be duplicated on the name field of the next page. The opposite should happen if you go back from the last page. Any tips to how this could be achieved?
Using the wizard, you are basically working with the exact same form that's split into multiple pieces. Ultimately it's the same form, because redux-form tracks them by name. It is how the library identifies the pieces of the same form - using the name.
form: 'wizard',
Here you can see that the exact same instance of the form will be shared throughout the pieces. fields work in a similar manner. Each field is defined as part of a form.
As long as you use the same field constants inside the fields object that you pass into the reduxForm function and as long as the value for form is the same, so that they use the same underlying form object, it should work for you just fine.
On one page you should pass in
export default reduxForm({
form: 'wizard',
fields : {
'fieldIWantOnBothPartsOfTheForm',
'someOtherFieldThatShouldOnlyBeHere',
},
...
And then on the other page:
export default reduxForm({
form: 'wizard',
fields : {
'fieldIWantOnBothPartsOfTheForm',
'thirdFieldHere',
},
...
Also, make sure you keep destroyOnUnmount equal to false if you want to navigate back-and-forth.
Hope that helps.
The Page Layout template for the "simple" theme (the default) contains:
<% include SideBar %>
<div class="content-container unit size3of4 lastUnit">
<article>
<h1>$Title</h1>
<div class="content">$Content</div>
</article>
$Form
$CommentsForm
</div>
Where does the value of $Form come from? ie to make use of it, what do I need to do?
Is it intended that I define a function Form() within the page controller that returns the form?
Yeah, it's a bit of an oddity. $Form is used by the Security controller, which is invoked in login situations (/Security/login, /Security/lostpassword, etc..) and because those templates can be themed, it assumes that you have a $Form variable somewhere in your template that indicates where the form should render.
You only need it in your Page.ss template, as the Security controller just renders a generic Page.
Anything in Silverstripe that extends ViewableData basically doubles as a ViewModel. This includes DataObject and Controller. So things that are publicly accessible on these objects are exposed to the View layer and callable as template variables (be they properties or methods).
Where does the value of $Form come from? ie to make use of it, what do I need to do?
So basically yes, your assumption is correct. If you define public function Form() (which returns a Form instance) in the page controller class you want the form to show on, it will render a form on the template (for all pages of that type).
Is it intended that I define a function Form() within the page controller that returns the form?
What UncleCheese intends to say in his answer is that the variable name $Form is arbitrary. Your method could for instance be named ContactForm(), in which case you'd need to give the template $ContactForm to show the form (be sure that the second parameter to Form constructor reflects this too - http://docs.silverstripe.org/en/3.1/developer_guides/forms/introduction/ using - __FUNCTION__ is a great way to avoid this gotcha).
Form() however does not appear as a function by default in page.php, nor in ContentController, etc. The Security controller however uses Page.ss to render (when you have the CMS module installed) - thus meaning if you do not have $Form in Page.ss somewhere, you will never be able to log in. So it's important to keep this unless you also define a Security.ss to make the login/lostpassword/etc. pages different to the normal Page.ss layout (in which case that template needs $Form).
I am currently working on a project developed using Zend Framework, based on the structure of my web page design I have reached a point where I have to pass a small number of variables to my layout from each Controller/Action. These variables are:
<?php Zend_Layout::getMvcInstance()->assign('pageId', 'page1'); ?>
<?php Zend_Layout::getMvcInstance()->assign('headerType', '<header id="index">'); ?>
The reason for passing this information is firstly, I pass the page id as the multi column layout may change depending on the content being displayed, thus the page id within the body tag links the appropriate CSS to how the page should be displayed. Secondly I display a promotional jQuery slider only on the index page, but I need the flexibility to have it displayed on potentially multiple pages in case the wind changes and the client changes their mind.
My actual question: Is there a more appropriate method of passing this information to the Layout that I am overlooking?
I am not really questioning whether the information has to be sent, rather is there some Zend Framework feature that I have, in my haste, overlooked which would reduce the amount of repetitive redundant code which may very well be repeated in multiple Actions within the same controller?
You could turn that logic into an action helper than you can call from your controllers in a more direct way. You could also make a view helper to accomplish the same thing but view helpers usually generate data for the view rather than set properties.
// library/PageId.php
class Lib_PageId extends Zend_Controller_Action_Helper_Abstract
{
public function direct($title, $pageId, $headerType)
{
$view = $this->getActionController()->view;
$view->headTitle()->append($title);
$view->pageId = $pageId;
$view->headerType = $headerType;
}
}
In your controller actions you can now do this:
$this->_helper->PageId('Homepage', 'page1', 'index');
// now pageId and headerType are available in the view and
// Homepage has been appended to the title
You will also need to register the helper path in your Bootstrap like this:
protected function _initActionHelpers()
{
Zend_Controller_Action_HelperBroker::addPrefix('Lib');
}
Doing it like that can reduce the amount of repetitive code and remove needing to assign the values from the view. You can do it in the controller very quickly. You can also have default values in the case that the helper hasn't been called.
You shoudn't really be passing anything from the view to the layout, for a start the view should be included IN the layout, not the other way around.
So, setting your page title should be done using similar code to what you have, but inside the controller action being called:
$this->view->headTitle()->append('Homepage');
And the other two issues - you need to rethink as I stated to begin with. Maybe you're misunderstanding the layout/view principle? If you include the different views per action, then you simply change the div id when needed, and include the header for your banner only in the index.phtml file.