Is it possible to put the ID of the current page into TypoScript constant (dynamically)?
You can't since the constants are processed before the setup.
And as said, the constants are constants fixed values.
No dynamic process available for this.
Related
I'm still learning Flutter and trying to understand best practices.
One of them seems to be that global variables are bad, and recommends using something like Provider instead.
In my case, I have a bunch of settings that are read from the back end when the app first starts. The variables in globals.dart are assigned values on startup, and then don't change after being assigned.
int maxLoginAttempts...
String welcomeMessage...
...
My confusion comes from the fact that most people who've asked this question (that I have found, sorry if I missed a post somewhere) are creating variables whose value may change as the application is used. I can understand something like Provider and ChangeNotifier would work well for that.
But in my case the values are assigned once - and don't change thereafter - they're only read.
So are globals still bad in my case?
In your case no provider/state management is needed if you are just assigning some value to global variable and and its value change does not require widget rebuild.
For both "TypoScript constants" and "Extension Configuration" (as defined in ext_conf_template.txt) use a common syntax. They are documented here:
Constants (in "TypoScript Template Reference")
Extension Configuration (in "TYPO3 Explained")
An example:
# cat=basic; type=string; label=Some title
title =
Line 1 describes data type, category etc. of the variable.
Alternatively, we might have something like this:
tx_plugins.my_plugin {
# cat=basic; type=string; label=Some title
title =
}
Besides this rather simple example, there are some more things you can do with this.
Where TypoScript constants and Extension Configuration are stored and how they are used is completely different, but I am wondering if we just look at the syntax and the features you can use - is it the same?
e.g.
the available datatypes (boolean, integer etc.)
that you can't use multiline values
that you can use environment variables
how to access files
how to do localization
The reason I ask: To streamline the documentation and also I use this in my own extensions.
Short Answer
The syntax used for TS template constants and extension configuration is the same but there are some minor differences for the available types currently.
Deep Analysis
Extension Configuration
For TYPO3 CMS version 6 the extension manager and configuration was rewriten from scratch based on Extbase and using the FormEngine. Available types are:
int: integer values
int+: positive integer values only
integer: alias for int
color: color picker
wrap: wrap, lines are separated finally by | for the saved value
offset: offset field
options: select
boolean: checkbox
user: user function is used for rendering
small: small text field
string: text field
input: alias for string, only for backwards compatibility, many extensions depend on that
default: alias for string, only for backwards compatibility, many extensions depend on that
Source is available here: https://github.com/TYPO3/TYPO3.CMS/blob/master/typo3/sysext/core/Classes/ViewHelpers/Form/TypoScriptConstantsViewHelper.php#L36
TypoScript Template Constant Editor
On the other hand the TypoScript template constant editor was never rewriten to make use of the FormEngine and has it's own implementation. Here the following types are additionally available:
comment: a checkbox to switch a constant
files: file selection
Source is available here: https://github.com/TYPO3/TYPO3.CMS/blob/master/typo3/sysext/core/Classes/TypoScript/ExtendedTemplateService.php#L993
Other Questions
that you can't use multiline values
That's almost true for the TS constant editor but there is the wrap type to achieve a multiline like functionality. For the extension configuration there are the small and string types.
For the other questions I'm currently not aware of and have to investigate a little bit deeper first:
that you can use environment variables
how to access files
how to do localization
As Typoscript is a configuration it can be used in multiple ways. And TYPO3 uses it differntly. So you have to diferentiate.
Constants can be used only for frontend rendering. there they are a shortcut to use a given value in different places.
Or to easily configure something (extension) without knowledge of detailed setup. Therefore you have the Constant-Editor where you can define constants which got a special information/ comment. It's like the TCA, a help to build forms and automaticaly have some validators for data. as TS-constants only are strings which can be used in the setup you do not have real data types. it is just a configuration to have some validation in the Constant-Editor.
Aside from some recursive replacement (up to a level of 10) of constants in constants definition you have no further options to compute a value.
In Typoscript setup you have (meanwhile) stdWrap funtionality nearly everywhere.
But especially extensions don't evaluate it everywhere. so in some places you have an extension configuration in setup where you only can insert fixed strings. (like in the constants)
on the other hand:
how can an extension be configured (with TYPO3-tools)?
Aside from the Typoscript setup (where you can use the constants), which primarily is used for the frontend rendering (*) you have a global option to configure extensions with the extension manager.
This data is stored serialized in typo3conf/LocalConfiguration.php. since TYPO3 9 unserialized.
It can be accessed in frontend and backend and works globaly, while the frontend typoscript or TSconfig is dependend on the page (and user).
This brings us to the third part of configuration: TSconfig
We have page-TSconfig and user-TSconfig. In pages, be_users and be_groups you can define a configuration with typoscript syntax. This can be enhanced with 'global' PHP code of extensions which inject further configuration in ext_localconf.php and ext_tables.php (or the successors in /Configuration/TCA/ and /Configuration/TCA/Overrides/)
(*) some extensions evaluate the frontend typoscript for configuration of backend modules or plugins-options
I'm using Typo3 9.5 and got some hardcoded variables within my fluid templates. I'm trying to make this variables depending on what language the page is viewed. Default value works fine. But making use of TypoScript like
[globalVar = GP:L = 1]
#whatever
[end]
for instance already throws an Error within the console either way and therefore does not override an variable. I think I've done this before in previous Typo3 versions. How do I achieve language depending variables and render it within my FLUID template?
You shouldn't be assigning your variables this way. The right way to handle this is to create XLF files that can be referenced with f:translate to translate a given key into any language as long as there's an XLF file for it.
This method is used and supported throughout TYPO3, not just in Fluid. Nearly all labelling options support LLL:... references where you can point to specific files.
You are encouraged to create an extension that can contain such files and then reference them with LLL:EXT... paths and/or use extensionName on f:translate in your Fluid templates if the extension is other than the one rendering your Fluid templates.
I have a need to go through a set of DICOM files and modify certain tags to be current with the data maintained in the database of an external system. I am looking to use GDCM. I am new to GDCM. A search through stack overflow posts demonstrates that the anonymizer class can be used to change tag values.
Generating a simple CT DICOM image using GDCM
My question is if this is the best use of the GDCM API or if there is a better approach for changing the values of individual tags such as patient name or accession number. I am unfamiliar with all of the API options but have a link to the API documentation. It looks like the DataElement SetValue member could be used, but it doesn't appear that there is a valid constructor for doing this in the Value class. Any assistance would appreciated. This is my current approach:
Anonymizer anon = new Anonymizer();
anon.SetFile(myFile);
anon.Replace(new Tag(0x0010, 0x0010), "BUGS^BUNNY");
Quite late, but maybe it would be still useful. You have not mention if you write in C++ or C#, but I assume the latter, as you do not use pointers. Generally, your approach is correct (unless you use System.IO.File instead of gdcm.File). The value (second parameter of Replace function) has to be a plain string so no special constructor is needed. You should probably start with doxygen documentation of gdcm, and there is especially one complete example. It is in C++, but there should be no problems with translation.
There are two different ways to pad dicom tags:
Anonymizer
gdcm::Anonymizer anon;
anon.SetFile(file);
anon.Replace(gdcm::Tag(0x0002, 0x0013), "Implementation Version Name");
//Implementation Version Name
DatsElement
gdcm::Attribute<0x0018, 0x0088> ss;
ss.SetValue(10.0);
ds.Insert(ss.GetAsDataElement());
When using TemplaVoila, the template data structure is mapped to the HTML template file by pathes like
body[1]/INNER|div.grey[1] div.content_area[1] div.left_column[1] div.left_content[1]
while this is obviously as precise as possible, it is not very effective, because every change to an DOM element above the mapped one would break the mapping, which happens quite frequently and is totally pointless. I like to patch TemplaVoila to rely on the last matching path segments only, which will suffice in almost any condition, as my HTML is always tagged by id's or classes on the mapped elements.
For the start, it would be cool if it would maybe just use
.left_content[1]
instead of the path shown above. But maybe it don't work in a matching fashion like CSS selectors do.
I just can't figure out where to start. Can this be done by TS config? Are changes to TemplaVoila's PHP needed? Can a new extension do this?
Add an unique class or even better id to the desired element, so you won't need to count the occurrences. TemplaVoila hasn't possibility to use CSS-like selectors first, last etc.
The mapping does not rely on the full path, but tag name and id, if the element mapped has an id attribute set.
Having an (even unique) class attribute only forces TemplaVoila to map the absolute element path, as classes are not necessarily unique.
So no special configuration is needed, if all mapped elements have unique id attributes set.