I am needing to change a private static property set on a class in Silverstripe. The initial value of the property is set to a boolean. I can change the value in my _config.php file with the following
Config::inst()->remove('class_name', 'property');
Config::inst()->update('class_name', 'property', []);
What is the proper syntax to achieve the above using my _conf.yml configuration? I would like to avoid spreading out my configuration amongst multiple files.
In the config.yml file you should do the following:
class_name:
property: string-value
or if it is an array:
class_name:
property:
- one
- two
I think what you are asking is how to replace the casting of the static, I think you might only be able to do that as you have in your example above as the yml config only sets existing config values rather than changes their structure.
Related
When I run a build with stencil, I get
[Warn]
The #Prop() name "title" is a reserved public name. Please rename the "title"
prop so it does not conflict with an existing standardized prototype member.
Reusing prop names that are already defined on the element's prototype may
cause unexpected runtime errors or user-interface issues on various browsers,
so it's best to avoid them entirely.
I know it's only a warning but since it may cause unexpected runtime errors, I was wondering if some standard for naming it already existed. (since title was for me the more obvious propriety name to use).
If not, what would be the best practice?
title is a global html attribute name - 'reserved'. See https://developer.mozilla.org/en-US/docs/Web/HTML/Global_attributes. As a best practice, you shouldn't use global attribute names for #Props. I don't know of any 'standard' for naming a property which is the title of your component but isn't the same as the global title attribute (which is usually used for the tooltip).
As of today, the only workaround I found was to add attributes as property and pass all the information through this variable, like the following
attributes: {
title: string
description: string
/** ... */
}
I didn't found better than that.
But I'm still open to any ideas
Properties and component attributes are strongly connected but not necessarily the same thing.
We cannot use the title variable because of the HTMLElement prop type, but we can set the field text as title like this
#Prop({ attribute: 'title' }) heading?: string;
I'm using FOS Rest bundle and JMS Serializer to create a REST Api. The problem is I would like to keep the property names in the JSON response camel cased instead of using _.
For example, I have a property called employeeIdentifier, by default that gets converted to employee_identifier.
I saw that there's an option in the config to disable the lowercase and get rid of the _, but then it becomes EmployeeIdentifier.
Is there any way that JMS Serializer keeps the original name of the property? Thanks in advance
I found a way to do it globally, if you want to keep the property names as is you need to use the IdenticalPropertyNamingStrategy
There are several ways to accomplish this, first by changing the config(Thanks #Phantom):
#config.yml
jms_serializer:
property_naming:
id: 'jms_serializer.identical_property_naming_strategy'
Second, you could override the default alias for this
services:
jms_serializer.naming_strategy:
alias: jms_serializer.identical_property_naming_strategy
The bundle defines these https://github.com/schmittjoh/JMSSerializerBundle/blob/master/Resources/config/services.xml so you should be able to override them
Another way to do it is when you initialize the builder:
$serializebuilder = JMS\Serializer\SerializerBuilder::create();
$serializebuilder->setPropertyNamingStrategy(new \JMS\Serializer\Naming\IdenticalPropertyNamingStrategy());
$serializer = $serializebuilder->build();
Having upgraded jms/serilizer-bundle from 1.1 to 2.2 the parameter hack described above did not work. You can override the service definition as follows:
#app/config/services.yml
services:
....
jms_serializer.serialized_name_annotation_strategy:
class: JMS\Serializer\Naming\SerializedNameAnnotationStrategy
arguments:
- '#jms_serializer.identical_property_naming_strategy'
Worked for me (Symfony 4.4 and JMS ^3.8) with this config in config/packages/jms_serializer.yaml :
jms_serializer:
property_naming:
id: jms_serializer.identical_property_naming_strategy
and removing the cache manually
https://github.com/schmittjoh/serializer/issues/1037
I found a way to do it but it's not the best way I think, there's an annotation SerializedName wich allows you to override the property serialization. The problem is that you have to do it one by one on every property with camel case, here's the documentation:
YAML: http://jmsyst.com/libs/serializer/master/reference/yml_reference
Annotation: http://jmsyst.com/libs/serializer/master/reference/annotations#serializedname
I had to add the following to parameters.yml instead of config.yml:
jms_serializer.serialized_name_annotation_strategy.class: JMS\Serializer\Naming\SerializedNameAnnotationStrategy
I have a spring-mvc application that is using java configuration, not xml. There are #Configuration annotations sprinkled through several files. In particular, there is a #PropertySources annotation in one file in a class that implements WebMvcConfigurerAdapter. There are two classes which contain an #Autowired Environment variable. One of these classes is itself a #Configuration class, and I would like it to have access to the fully-loaded Environment at the time it runs.
This isn't happening. When this code executes, the Environment is still null. I've tried reordering the #ComponentScan packages, tried moving the #PropertySources annotation, and nothing has helped me load the property sources in time.
I want this to happen first, before any other configuration.
What must I do to make it so?
UPDATE: After trying many things, including the Order annotation, I find the problem seems to be not so much that the #PropertySources are being loaded too late as that a class I have that is derived from org.springframework.security.web.context.AbstractSecurityWebApplicationInitializer is being loaded too soon. Nothing in my code even references this class but Spring is somehow deciding that this, above all other classes, must be initialized first. No amount of messing around with #Order seems to change this. This in spite of the javadocs, which indicate that the behavior I want is the default:
Caveats
Subclasses of AbstractDispatcherServletInitializer will register their
filters before any other Filter. This means that you will typically
want to ensure subclasses of AbstractDispatcherServletInitializer are
invoked first. This can be done by ensuring the Order or Ordered of
AbstractDispatcherServletInitializer are sooner than subclasses of
AbstractSecurityWebApplicationInitializer.
You can use ContextInitializer, catch the moment when Boot prepared its environment and "inject" your property source programmatically as you want.
If you have a ConfigurableApplicationContext then it provides a ConfigurableEnvironment, which contains the propertySources as a list. If you want your PropertySource to rule all above the others than add it as first. If you want to place it to a special position then you can add it before an other, identified by its "name".
public class ConfigInitializer implements ApplicationContextInitializer<ConfigurableApplicationContext> {
#Override
public void initialize(ConfigurableApplicationContext ctx) {
// rule over all the others:
ctx.getEnvironment().getPropertySources().
addFirst(new ResourcePropertySource("file:/etc/conf/your_custom.properties"));
// rule over application.properties but not argument or systemproperties etc
ctx.getEnvironment().getPropertySources().
addBefore("applicationConfig: [classpath:/application.properties]",
new ResourcePropertySource("classpath:your_custom.properties"));
// names can be discovered by placing a breakpoint somewhere here and watch
// ctx.getEnvironment().getPropertySources().propertySourceList members,
// each has a name ...
}
}
You can bring into play this class by:
registering it in the application.properties :
context.initializer.classes=a.b.c.ConfigInitializer
or from application start :
new SpringApplicationBuilder(YourApplication.class).
initializers(new ConfigInitializer()).
run(args);
By the way this is a proper way to inject more of your custom properties, like properties coming from a database or a different host etc...
Not that I am an expert in Java config but maybe:
Spring 4 utilizes this feature in its #PropertySource annotation. To
remind you, #PropertySource annotation provides a mechanism for adding
a source of name/value property pairs to Spring's Environment and it
is used in conjunction with #Configuration classes.
Taken from: http://blog.codeleak.pl/2013/11/how-to-propertysource-annotations-in.html
Are you using #PropertySource or #PropertySources?
Have You tried 'order' property for spring bean initialisation?
Is it possible to use variable values for defining new twig globals in a configuartion-yml-file?
The situation is, that we want to define the domain name at the one hand and at the other define often used paths (but using the already defined variable instead of writing the server name again at the beginning of each path).
So is it possible to make the config-file look something like the following code?
twig:
globals:
serv: http://www.server.de
path: {{serv}}/path/
If not, what would be a reasonable alternative?
Thx in advance
I suggest to use parameters.yml to define configuration params.
parameters.yml
serv: "http://www.server.de"
config.yml
twig:
globals:
serv: "%serv%"
path: "%serv%/path/"
I am using Unity2 with XML configuration. It has the neat feature to specify namespaces and assemblies in the XML config for which automatic type lookup is performed, so that you do not need to always specify full name or create an alias.
Is it possible to specify assemblies and namespaces for the automatic type lookup programatically, without them being explicitly listed in the XML configuration? My goal is to simplify the XML configuration for my application's administrators. Types from two or three namespaces will almost always be used in the container registrations, so I would like these namespaces to be included in the lookup automatically.
There's nothing built in explicitly to support this.
An option would require a few more steps in your code. instead of just calling container.LoadConfiguration(), you'd instead explicitly grab the configuration section:
var section = (UnityConfigurationSection)ConfigurationManager.GetSection("unity");
Then, you'd go into the Namespaces or Assemblies properties on the section, and add new NamespaceElement or AssemblyElement objects pointing at the "standard" namespaces and assemblies. Then you apply the updated configuration section to the container. Something like this:
section.Namespaces.Add(new NamespaceElement() { Name = "my.standard.namespace" });
container.LoadConfiguration(section);
I haven't actually tried this, :-), but it should work.