I'm developing a TYPO3 extension (backend usage only). There is a special property of a class I want the user to have multiple input forms for and the input forms should all be added to an array if the record for this model is saved. It should be like the "create multiple pages" form in the TYPO3 backend when you click on "Functions". So there should be also some "add new lines" button to theoretically add infinite input forms (and therefore multiple strings to the array).
Related
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'd like to know if there is a way to configure, disable or otherwise override the way Symfony handles automatically generating form labels for entity properties.
We also use the Sonata Admin Bundle and Symfony native and Sonata do not always produce the same label for complex form fields based on a given entity property, specifically when adding related entity properties e.g. something.somethingRelated. Sometimes it seems there is an extra space added to the label string (where the "dot" is) so we end up with two different labels being generated for the exact same property in two different forms.
Sonata has a configuration that allows some control over how the label is generated; e.g underscores, native, do nothing, etc.
We are trying to get our translations under control but still use the automatic generation of form labels rather than having to add a label (key) to each form field.
Right now I think my best alternative is to just turn it off in Symfony and let the actual property name be the "string" that is generated without any processing on it. So, thisIsTheProperty would have an automatically generated label string "thisIsTheProperty", not "This Is The Property" or whatever.
We are looking at Umbraco as a possible alternative to our current CMS which was developed in house and which although powerful, is dated now and becoming more difficult to maintain.
One really good feature which we would be loth to lose is the widget feature. Using this, we can build a widget by defining a number of inputs (eg text fields, media picker, links etc) together with the html required to output the results (using placeholders to substitute in the content entered by the web content editors).
On the page, content editors can select which (if any) widget(s) to use, enter content into the inputs defined in the widget, and the page outputs this accordingly.
In other words, without resorting to programming, we can create widgets just by defining inputs and the output html in minutes.
Users can select widgets and their input is controlled and formatted.
Simple and effective.
Is anything like this available in Umbraco without having to develop new C# code for each widget? I have looked into using macros in a rich text field, but I can't see how they can be made editable using complex data entry as described above.
Beside the Macro in richtext,
In Umbraco you can use a picker/list view data type to select some "component/widget items" and for rendering it requires some code if more than one document type is allowed, if document type is x1 do code a1.
Use (Partial view) Macro Files for reuse.
This is the closest to the "widget" function you want.
A other relatively new datatype in Umbraco is the Grid layouts, allow editors to create a Complex data, column structure with multiple data types. I suspect not comparable/useful for your "widget" function.
I was trying to understand how can we make drop-down values in dialog box easily authorable?
Select lists in dialogs can load their options dynamically from anywhere, so long as they are provided as an array of values in JSON format (from the docs):
[
{
value: "pink",
text: "Pink",
qtip: "Real Pink"
}
]
So one solution would be to:
Create a new template that would allow an editor to add/remove values from a list — make this editable for content authors as per any other content (e.g. using the page properties, or components that you can drag onto that template).
Create a Servlet that will parse those values & output them in the expected JSON.
Register that servlet, e.g. via a path (/bin/selectvalues).
Using the cqinclude xtype to load in your values:
i.e.
<select
type="select"
xtype="selection"
options="/bin/selectvalues"/>
If you are looking for a drop-in solution for this, take a look at http://adobe-consulting-services.github.io/acs-aem-commons/features/generic-lists.html. This supports easily authorable lists of name/value pairs which can be used (without writing additional code) in:
Classic UI Dialogs
Touch UI Dialogs
Touch UI Asset Metadata Editor
I have a form here in which there is a textfield which contains a number. In another part of the form there are rows, which coresponds with the number entered. For example 2 = 2 rows etc.
So my idea is to create one row which is duplicated by a javascript. So i must create a input element which name is in a array like name="input[]" how can i do this in Zend Framework?
The only approach i found for this kind of problem is to use subforms. But every Subform has a explicite name which is not in a array.
To make a rendered Zend_Form respond to client-side changes - as in your example, to allow the user to enter the number of rows he wants - you need both client-side and server-handling.
The best example demonstrating the general idea is from Jeremy Kendall:
jeremykendall.net » Blog Archive » Dynamically Adding Elements to Zend_Form
The upshot is that you have client-side code that adds tracks the number of fields and then a preValidation() method that injects the right number of fields into the $form instance before isValid() gets called.
[As noted in the comments there, this preValidation() processing could just be bundled into isValid() so that the controller remains unchanged.]