I'm building a proper extension for the management of real estate, I would like to use the added "Image Metadata" field "Show in list view" as the extension tx_news does.
I can build this option in exactly as tx_news does but in case the site instalation uses both extensions, does this cause a conflict ? ( I'd use the same field name showinpreview )
Should I use a different field name to avoid trouble?
( I plan to use this feature in the exact same fashion, so I can easily share the use of the field in the "sys_file_reference" table ... if there was no other conflict there could be the case that an image was used in both extensions and the selection would be determined by one of the two extensions for both or do I misunderstand something here... )
anybody did experiments with this and can avoid me the trouble ?
I never had this use case but both ways are possible.
- use the same field: less code needed but your extension depends on news
- new field: also fine
You can use the same field as there also is a field which identifies the table the record belongs to.
Be sure to stay in sync with tx_news. either by a dependency, which might be a great overhead if you don't use tx_news otherwise, or with the same declaration as in tx_news, this can conflict if tx_news changes declaration unnoticed.
You have to declare your own access which will be independent as you use other namespace and context.
Related
The common way to write the TypoScript is in Configuration/TypoScript/setup.txt.
But there also two other way to write TS. One with ext_typoscript_setup.txt and other with ExtensionManagementUtility::addTypoScriptSetup().
Can someone explain me what the difference is and when should i use which one?
Theoretically the usage of ext_typoscript_setup.txt files has been deprecated. Theoretically because it has never really been removed from the core.
ext_typoscript_setup.txt and ExtensionManagementUtility::addTypoScriptSetup() do quite the same thing as those will always load the given TypoScript. However the problem is that sometimes people have a hard time overriding those default code. To make it even more complicated there is the select field Static Template Files from TYPO3 Extensions inside the sys_template record which can influence the order.
As a solution (or at least how I handle it):
Always use the way of having TS in Configuration/TypoScript/... and let the integrator decide how and in which order it is included. Some people include TypoScript within their SitePackage, some in sys_template record, ...
However I also use ext_typoscript_setup.txt in rare case if some TS must be available and which won't be changed by an integrator.
I have some data (logins) I want to be ignored from git in my custom TYPO3 extension code.
As AdditionalConfiguration.php is already ignored in my case, it seems a good place to store such data.
It normally contains Data like
$GLOBALS['TYPO3_CONF_VARS']['DB']['Connections']['Default']['dbname']
Now would it make sense to make something like custom globals? Does that exist?
$GLOBALS['CUSTOM_CONF_VARS']['MYEXT']['username']
Should and can I do that or not?
I think you can use your own globals. But I would consider using your own globals as bad programming style.
If you have installation specific data the right way to store the data depends on the kind of data and where you need it:
everything for the Frondend should be stored in typoscript. This can be in a file from a site-extension or in the database (template record)
for BE you could use Page- or User-TSconfig. here you also can use a file from a site-extension or database records (pages/be_user)
if you have FE and BE or anything alse (e.g. scheduler jobs) you can use extension specific global data, you can set in the extension manager. -> docs.
Instead of saving configuration in $GLOBALS try use typoscript. Will be much easier to keep and maintain it.
Let's say I have a struct definition like this:
struct SomeStruct {
1: optional binary content;
2: optional binary newConetent;
}
What is the best practice to deprecate the first field ("content"), without affecting deployment? The deployment of the new code will be into multiple applications that is using this thrift structure? (Assuming some applications are still using the "content" field before the deployment)?
Thank you!
The recommended solution is to comment out the field but leave it in the IDL. This prevents the field ID from becoming reused later for sth. else which then of course would produce incompatibilities.
If "in use by clients" means that they are accessing the outdated field for RPC only, that's not a problem w/regard to Thrift. Thrift will behave just like with a new field.
If however you mean that the field is used for serialization and the old data contain relevant information that needs to be converted somehow into the new format, you will have to leave the field active in the IDL. You may consider renaming the field in order to make it visible to the target audience of your IDL.
I'm new to the fedext-universe. By now, I've created a set of content elements, and they work fine.
There is one drawback though: One set of content elements has some fields in common, and these fields are rather complicated. Usually, I'd move their definition to a partial, but that isn't possible in flux forms. The beginners guide states
Flux templates can use Layouts and
Partials - but a Flux form cannot
be split into Partial templates.
Is there any way to avoid redefining these fields over and over again? Among other things, I've tried to use the <vhs:render.inline> viewhelper along with a custom viewhelper, returning the fluid-definition of the fields, but I can't get that to work.
Flux 7.0 will bring the option to place fields and sheets into Partial templates - if you are currently in a development project, I recommend trying it out from the development branches on Github:
https://github.com/FluidTYPO3/flux/tree/development
Flux 7.0 also will bring the option to create PHP classes which for example create ready-made sheets with a bunch of fields - such a class would be ideal to reuse, simply requiring one PHP class and one Fluid ViewHelper. Such an approach would be more efficient when your forms are rendered, but of course is much more technically demanding than a Partial template.
EDIT: though not yet documented, creating custom sheets involves two simple steps: 1) create a subclass of FluidTYPO3\Flux\Form\Container\Sheet and a subclass of FluidTYPO3\Flux\ViewHelpers\Form\SheetViewHelper - then include your namespace in the template, use your own ViewHelper instead of a flux:form.sheet (and add additional fields if you need them) and then inside the Sheet object, use the $this->createField() method from within object initialization, to automatically add any number of fields with predefined names, labels etc.
Is there any way I can use the format_number_choice function inside of a actions file. In fact I need to use it for a Form error message.
'max_size' => 'File is too large (maximum is %max_size% bytes).',
In English it's simply "bytes", but in other languages the syntax changes after a certain value (for example if the number is greater than 20 it's: "20 of bytes").
I can use parenthesis, of course, but if the framework offers support for doing this specific thing, why not to use it?!
The way it's currently implemented in the 1.4 branch, you can define only one translation per message using il18n XML files.
What you could do is create a custom validator which inherits the current validator (sfValidatorFile in your example) and does the size checking in the doClean method before calling its parent's method.
I suggest you take a look at the source to see how it works : sfValidatorFile
The correct way to handle number ranges for translation is explained here in the Definitive Guide. I won't reproduce it here as the documentation itself is clear and concise. Note however that the string is not extracted automatically by the i18n-extract task, so you need to add it manually - again, the documentation explains this.
So yes, you can use the format_number_choice() function inside an action - you just need to load the helper inside the action like this:
sfContext::getInstance()->getConfiguration()->loadHelpers('I18N');