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.
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.
Does QuickFIX/J provide any way to specify field->values mappings in config files that should be used on specific sessions?
For example on SESSION_UAT I want to send on every NewOrder customTag1="Test", and on SESSION_PROD I want customTag1="Real"? The values may change over time and should be maintained by non-developers so I don't want to do that part in code.
I could myself add support for this but I wonder if there's anything like that already so I won't reinvent the wheel. I was looking at codegen package in QuickFIX/J for this but the code generating step is something I want to avoid.
No, this is not something that QF/j explicitly offers.
However, you could put a custom value in the QF/j session config file (see docs) and set your value according to that. That's a pretty easy way to do it.
Or if you don't want users to be able to edit the session config, it would be simple to roll your own config file format and reader.
In SugarCRM, you can create your custom modules (e.g. MyModule) and they are kept in /modules just like stock objects, with any default metadata, views, language files, etc. For a custom module MyModule, you might have something like:
/modules/MyModule/MyModule.class.php
/modules/MyModule/MyModule.php
/modules/MyModule/language/
/modules/MyModule/metadata
And so on, so that everything is nicely defined and all the modules are kept together. The module becomes registered with the system by a file such as /custom/Extension/application/Include/MyModule.php with contents something like:
<?php
$beanList['MyModule'] = 'MyModule';
$beanFiles['MyModule'] = 'modules/MyModule/MyModule.php';
$moduleList[] = 'MyModule';
Obviously, the $beanFiles array references where we can find the base module's class, usually an extension of the SugarBean object. Recently I was advised that we can adjust that file's location for the sake of customization, and it makes sense to a degree. Setting it like $beanFiles['MyModule'] = 'custom/modules/MyModule/MyModule.php'; would allow us to access the base class via Module Loader even if the security scan tool prevents core file changes, and this would also allow us to not exactly extend, but replace stock modules like Accounts or Calls, without modifying core files and having system upgrades to wipe out the changes.
So here's my question: what is the best practice here? I've been working with SugarCRM pretty intensely for several years and this is the first time I've ever been tempted to modify the $beanFiles array. My concern is that I'm deviating from best practice here, and also that somehow both files modules/MyModule/MyModule.php and custom/modules/MyModule/MyModule.php could be loaded which would cause a class name conflict in PHP (i.e. because both classes are named MyModule...). Obviously, any references to the class would need to be updated (e.g. an entryPoint that works with this module), but am I missing any potential ramifications?
Technically it should be fine, but I can see how it could be possible that both the core version and your version could conflict if both are referenced. It all depends on the scenario, but I prefer to extend the core bean and find somewhere in the stack where I can have my custom version used in place of the core bean. I wrote up an example a couple of years ago here: https://www.sugaroutfitters.com/blog/safely-customizing-a-core-bean-in-sugarcrm
For most use-cases, there's a way to hijack Sugar to use your bean at a given point.
If you can't get around it you can always grep to see where the core module is explicitly being included to ensure that there won't be conflict down the road.
I'm currently making good use of GWT's ClientBundles in my app. It works fine, but I have a large number of resources and it becomes tedious to manually create Java interfaces for each file:
#ClientBundle.Source("world_war_ii.txt")
public ExternalTextResource worldWarII();
#ClientBundle.Source("spain.txt")
public ExternalTextResource spain();
#ClientBundle.Source("france.txt")
public ExternalTextResource france();
I'd like to be able to (perhaps at compile time) dynamically list every *.txt file in a given directory, and then have run-time access to them, perhaps as an array ExternalTextResource[], rather than having to explicitly list them in my code. There may be hundreds of such resources, and enumerating them manually as code would be very painful and unmaintainable.
The ClientBundle documentation explicitly says that "to provide a file-system abstraction" is a non-goal, so unfortunately this seems to disallow what I'm trying to do.
What's the best way to deal with a large number of external resources that must be available at run-time? Would a generator help?
There's an automatic generator for CssResource - maybe you could look at its code and modify it to your needs?
I ended up following this advice: perform the file operations on the server, and then return a list of the file (meta)data via an RPC call.
This turns out to be fairly simple, and also allows me to return lightweight references (filenames) in the list, which I use to populate a Tree client-side; when the user clicks on a TreeItem the actual text contents are downloaded.
I'm trying to come up with a way to make it easy to switch out our "mock" data services and our live ones. Basically, we'll have live servers with real web services, but for whatever reason, a developer may want to load data from static files (file urls).
I figured I would solve this problem by creating categories that override the methods that fetch the data, thus leaving original code untouched (it has no concept of the "mock" data). I don't want to litter my code with #ifdef.
I can put an #ifdef at the very beginning of each file that has categories in it, and I can set a custom flag in the configuration settings, but I'd rather just have a way to include or exclude the files depending on the configuration. Is that possible? How do you solve this problem?
See http://lists.apple.com/archives/xcode-users/2009/Jun/msg00153.html
The trick is to define EXCLUDED_SOURCE_FILE_NAMES in the configuration you want to exclude the files from, and set the value of that custom build setting to a list of the file names (or a pattern that matches those, and only those, file names).
I would recommend creating two targets one of which has the mock categories included and another one which does not.
When you want to test, just build the target containing the mock categories. Everything else can remain identical.
If you would like to add a file but do not wont to compile it. Go to (for all your targets) project>build phases>compile source and take out the file that you do not want to compile.