I have recently migrated a SAPUI5 application from version 1.52 to version 1.96 and now I have an issue with defining constraints for a sap.ui.model.type.DateTime field (a sap.m.DateTimePicker to be precise).
In 1.52, I had the following binding definition in an XML View:
Based on this definition, it was possible to force the user to enter a value in this field using something like:
oBinding.getType().validateValue(oInternalValue);
Somewhere between SAPUI5 1.52 and 1.96, there were some changes to how constraints are handled and now defined constraints have to be valid dates.
Considering the above, how could I pass a valid Date, as constraint, in an XML View binding definition?
I've already tried various options like:
"May 18, 2000 00:01"
958597260000 (number of milliseconds since the ECMAScript epoch)
"/Date(958597260000)/"
Thanks and have a good day!
SePo
Related
I am adding a field to the pages table (is a relation to a file) and would like the value of the field in the pages record to be copied to the translated record by default.
Currently, the copied field is empty (default value), which is probably a good idea in most cases.
I am thinking of something that behaves like l10n_mode = prefixLangTitle without the prefix.
Depending on the TYPO3 version this should be possible with one of the following behaviours for the inline field:
https://docs.typo3.org/typo3cms/TCAReference/7.6/Reference/Columns/Inline/Index.html#behaviour
https://docs.typo3.org/typo3cms/TCAReference/8.7/ColumnsConfig/Type/Inline.html#localizechildrenatparentlocalization
https://docs.typo3.org/typo3cms/TCAReference/latest/ColumnsConfig/Type/Inline.html#allowlanguagesynchronization
Sine the localizeChildrenWithParentLocalization feature is broken with pages and pages_language_overlay though, I guess the only working versions would be CMS 8 or 9 with properly configured language synchronization.
https://forge.typo3.org/issues/78743
Use
['behaviour']['allowLanguageSynchronization'] => true
if the translated record will use the value from the default field by
default (will effectively be copied), but it should be possible to change
this later.
See pages.author as example.
When "Custom value" is selected, the value can be overridden.
Alternativively, use
l10n_mode = exclude
if the field should always have the value of the default language and you
should not be able to change it in the translated record.
I am using CRM 2016, and trying to customize email template by adding a dynamic data. I know that CRM allows to use only specific vanilla entities, but when I explorer an old code I found an option to use {0}, {1} etc' for injecting data from non vanilla entities (by code) - unfortunately that code cannot be tested...
Have someone heard or know about that way? is it possible? what to google for?
You can do this by manually typing similar marker what CRM is using. Note that this is not documented in SDK.
Dynamic Values For Custom Entities In Email Templates
In the template, where you want the value to appear, type within 2 brackets an exclamation point followed by the entity logical name. After the entity name, add a colon, and then the field logical name, ending it with a semi colon. If you’d like a default value if nothing was found, after the semi colon add the default value.
{!<entitylogicalname>: <fieldlogicalname>; <Default Text>}
More in part 2:
The Global Template Type is what you’d want to use for custom
entities, or any other entity not listed in the template type drop
down menu. And just to reiterate, regardless of the way you insert
values, whether you use the out of the box insert method or you
manually type it in, you can only insert values from one record.
Dynamic Values For Email Templates - Part 2
Dynamics' email templates are flawed. You either can't use custom entities or you have no translation. I use this workflow instead. It can do everything : https://github.com/rtebar/dynamics-custom-emails
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.
Since updating from Flux 6.0.2 to the newest Flux TER-Release (7.0.0) I have the problem that all my defined flux:field.select items are switched. I have them defined as an array like this items="{0: {0: 'value shown as a CSS class in the frontend',1: 'value shown in BE'},}". But now I get the BE value in the frontend template.
Also all my content elements from my provider extension are shown twice (without a title) in the backend and the fields defined in the 'Configuration' section of my content element are shown twice.
There's also a RTE field shown at the bottom of my content element that has not been there before.
BE Output: view
Code on Pastebin: http://pastebin.com/CNcphn2k
Any help deeply appreciated.
EDIT:
I just set up a fresh instance of TYPO3 6.1.9 (blank package) and installed my extension with the above mentioned content elements. Dependencies were resolved automatically as it should (newest versions). Via the content wizard I tried to create a new element and I get the same result as in my existing install I first noticed this bug in.
EDIT2:
I was able to narrow it down to the flux:form.container tag. This duplicates the output in the BE. The select values are still switched though.
It is possible that you missed this official announcement:
http://fluidtypo3.org/blog/news/new-colpos-value.html
Failure to run the update script before letting TYPO3 change the type of the colPos value will result in the symptoms you describe. There is, unfortunately, no way to restore this (since your SQL will have cropped off all negative values and made them zero without any backup).
Restore from a backup and run the script and you should be fine.
I'm currently using TYPO3 6.1.8-dev to build a flux/fluidpages (GitHub Master) powered template and managed to have it running on the root pages, though, I have issues with the sub-pages, in terms of value inheritance.
I've implemented the following scenario:
A Flux Flexform Configuration is used, if there is no TypoScript override variable set, retrieved from TS Setup.
The Flexform fields have the following names:
gridsettings.topRow_use (checkbox)
gridsettings.topRow_cols (select)
After the Flexform Configuration, I use these fields to build the backend grid, after I mix in some static values of a TypoScript configuration with:
{v:iterator.merge(a:'{gridsettings}', b:'{tssettings}') -> v:var.set(name:'gridsettings')}
This works for every page with explicit settings in the page properties, but not for sub-pages, which should just inherit the parents settings.
In the case of sub-pages the gridsettings array is null, and only my TS settings are visible.
I'd like to have the convenience to just create a new sub-page, and add content to the inherited backend-layout grid without any further interaction in the page settings.
How can I solve this issue?
Two parts to this:
1) To solve the problem that you manually must merge TS with FlexForm settings, use the prefix settings. in all your field names. This special, reserved variable name will be used by both Extbase and Fluid without requiring you to transfer it, and your FlexForm settings will be merged (on top of) your TS settings.
2) Inheritance requires the exact same page template on parent and child page, or that child page sets parent decides as option for which template to use. There could be other causes for failing inheritance (for example, the use of default on any of your fields - since you don't include your Flux form structure this is impossible to determine) but mismatching parent/child template is the most common. Also, make sure your Flux is up-to-date; there have been bugfixes recently related to inheritance.