Is it safe to create a new UrbanCode Deploy component by exporting the original component to a JSON file, changing the name, and importing it as a new component? Are there other fields (UUIDs, etc.) that need to be changed so that there won't be conflicts or overwrites?
It is much safer and quicker to just use the "Copy" action for the component if you can. Is there some reason you can't? If you have to import, it should be ok, but you likely want to make sure you leave all of the Import Component options as the defaults (e.g. leave the Upgrade component checkbox empty) to avoid damaging/changing other linked objects.
Related
I'm currently looking for a way to capture only svelte components on the DOM tree during development mode. I can see that we I run npm run dev all elements and conponents have the "class='svelte-somerandomID'". Does this only happen in development mode?
Yes, it's only in during development that all elements get a scoping class -- and only with some tools. Actually it's a hack we've added in vite-plugin-svelte to enable more power CSS only HMR.
The classes you're referring to are what Svelte uses to make the CSS in a component apply only to the elements of this component. It adds a class that is unique to the component to all elements that can be affected by the component's CSS, and it also modifies your CSS rules to add the same class to them.
Normally the compiler only adds the scoping class to elements that can actually be targeted by the existing CSS rules in your component. If you really want all the elements in a component to have the scoping class, you can use the same trick that I linked to above: add the following rule to your component's CSS.
* {}
By default the generated class names are a hash of the component's CSS content. But you can also customize them with the cssHash compiler option. Note that vite-plugin-svelte also changes how the class names are generated, to be based on the file name instead of the content.
Since every element in the component would be targeted by this roule, this will cause the Svelte compiler to add the scoping class to all the elements.
If you wanted to automatically generalize this to every element of every component, you may want to do it with a preprocessor (if you need some inspiration, the code I've linked too actually implement this with a preprocessor).
I'm not sure if this is what you really want though. For one thing, only elements get a scoping class: components don't get a scoping class, because components don't have dedicated elements in the DOM (only the ones you may or may not add via the component's markup). The above trick would only give you a mean to select every element of a Svelte component. There might probably be easier or cleaner ways to achieve what you really want. For example, a simple wrapping component, or an action, that would use wrappingElement.querySelectorAll('*') or something...
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.
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.
For some imports, I may want to keep a * import even I am currently using only 1-2 classes/methods. For example, I may want to import org.mockito.Mockito.* even I am currently using only a few of them, because when my test grows, I will need to use more static method under Mockito. However Organize Imports function in Eclipse always break down my import to import individual methods (which is the preferred behavior in most case).
Is there a way to let me control such behavior in package basis? i.e. I want to keep importing * for some packages (or disabling auto-break-down feature), but for other packages, I would want to use Eclipse's default behavior (deciding * base on number of classes/methods used)
You can't change the policy for individual imported packages or classes, but you can set the overall threshold lower so that Organize Imports won't convert the wildcard import to individual ones. Go to Preferences > Java > Code Style > Organize Imports and then edit the Number of static imports needed... value to something small, like 2.
With it set to a small number, you can manually add a wildcard import and as long as the class uses at least the threshold number of methods, Eclipse will leave it alone.
This doesn't appear to be possible at present, but as it's clearly a useful idea I've added a feature request to eclipse bugzilla for it: https://bugs.eclipse.org/bugs/show_bug.cgi?id=506826
I need to implement a custom ResultHandler but I am confused about how to actually integrate my custom class into the software package.
I have read this: http://elki.dbs.ifi.lmu.de/wiki/HowTo/InvokingELKIFromJava but my question is how are you meant to implement a custom result handler such that it shows up in the GUI?
The only way I can think of doing it is by extracting the elki.jar package and manually inserting my custom class into the source code, and then re-jarring the package. However I am fairly sure this is not the way it is meant to be done.
Also, in my resulthandler I need to output all the rows to a single text file with the cluster that each row belongs to displayed. How tips on how I can achieve this?
There are two questions in here.
in order to make your class instantiable by the UIs (both MiniGUI and command line), the classes must implement our Parameterization API. There are essentially two choices to make your class instantiable:
Add a public constructor without parameters (the UI won't know how to set your parameters!)
Add an inner static class Parameterizer that handles parameterization
in order to add your class to autocompletion (dropdown menu), the classes must be discovered by the MiniGUI/CLI/other UIs. ELKI uses two methods of discovery:
for .jar files, it reads the META-INF/elki/interfacename service files. This is a classic service-loader approach; except that we also allow ordering instances.
for directories only, ELKI will also scan for all .class files, and inspect them. This is mostly meant for development time, to avoid having to update the service files all the time. For performance reasons, we do not inspect the contents of .jar files; these are expected to use service files.
You do not need your class to be in the dropdown menu - you can always type the full class name. If this does not work, adding the name to the service file will not help either, but ELKI can either not find the class at all, or cannot instantiate it.
There is also a tutorial on implementing a custom result handler, but it does not discuss how to add it to the menu. In "development mode" - when having a folder with .class files - it will show up automatically.