So I've been using TypeLite 1.0.1 with good results until I upgraded to the latest version (1.1.0). It seems the IMemberIdentifier interface is gone, which broke this part of my T4 script:
ts.WithFormatter((TypeLite.TsModels.IMemberIdentifier identifier) =>
Char.ToLower(identifier.Name[0]) + identifier.Name.Substring(1));
I was using this to camel case all my properties in the TypeScript interfaces I'm generating. I can't seem to find a workaround for it and the TypeLite site documentation still uses the above code in their example. I had the same problem with version 1.0.2.
Any comments or ideas much appreciated. Thanks.
It seems that method of formatting members has changed.
To camel case all properties use:
ts.WithMemberFormatter((TypeLite.TsModels.TsProperty identifier) => Char.ToLower(identifier.Name[0]) + identifier.Name.Substring(1));
Related
I am looking for potential pitfalls or best practices when supporting multiple TYPO3 major versions with extensions. There are some things to consider.
I noticed several extensions support several TYPO3 major version in one version, e.g.
extension version 1.0.0 supports 9.5.* and 10.4.*
However, this way, you can't really get rid of things as soon as they are deprecated. (For example, a function may be deprecated in 10 and there is a replacement function, but this is not available in 9, so in order to support both you use the deprecated function).
This has the disadvantage, that the extension scanner will point out lots of things which are just deprecated. I am a huge fan of the extension scanner and getting rid of deprecations as soon as possible.
When I created my extension migrate2composer I used a separate version branch 8.7. But this is more work if I fix bugs because it needs to be backported.
What is a good strategy and are there ways to keep the workload minimal?
One possibility to support multiple versions and already use the new functionality can be found in the bootstrap_package:
/***************
* Make the extension configuration accessible
*/
if (class_exists(\TYPO3\CMS\Core\Configuration\ExtensionConfiguration::class)) {
$extensionConfiguration = \TYPO3\CMS\Core\Utility\GeneralUtility::makeInstance(
\TYPO3\CMS\Core\Configuration\ExtensionConfiguration::class
);
$bootstrapPackageConfiguration = $extensionConfiguration->get('bootstrap_package');
} else {
// Fallback for CMS8
// #extensionScannerIgnoreLine
$bootstrapPackageConfiguration = $GLOBALS['TYPO3_CONF_VARS']['EXT']['extConf']['bootstrap_package'];
if (!is_array($bootstrapPackageConfiguration)) {
$bootstrapPackageConfiguration = unserialize($bootstrapPackageConfiguration);
}
}
The line // #extensionScannerIgnoreLine will make the extension scanner ignore the following line and will not clutter up the report with this, see Extension scanner documentation.
Thanks goes to Simon Gilli for pointing this out ...
I release a unique version for each TYPO3 LTS version to be able to throw out old stuff. This also facilitates automated testing.
I am like you using different branches to manage that and cherry-pick commits between them.
It's a little bit more work but can be facilitated with helper scripts. I have written some sentences about our reasoning here https://docs.typo3.org/p/dmind/cookieman/master/en-us/Contributors/Index.html#branches
I've heard from some users being confused by the versioning scheme, so in hindsight for the next time I would choose to stick with 1 major version = 1 TYPO3 LTS.
E.g. starting with
v1 - TYPO3 v9
v2 - TYPO3 v10
v3 - TYPO3 v11
And then if our extension has breaking changes, continue with the next free major version, maybe removing the "new feature" support for an older LTS.
v4 - TYPO3 v10
v5 - TYPO3 v11
It is also a compromise however. This way you cannot say that feature X is "in version > 4.1" but maybe the composer scheme will be better understood in the future so you could say "^4.1 || ^5.1".
I am trying to migrate from version 0.8.1 to 0.9.1 in Scala js. Previously, if I wanted to have a user defined attribute in an element I did so as follows:
button("my-attribute".attr = "false")
But does no longer compiles in version 0.9.1. What is the correct approach now?
I'm not sure what library you were using, but it almost looks like ScalaTags. If so, the syntax you want is:
button(attr("my-attribute") := "false")
ScalaTags Docs
I vaguely recall that ScalaTags used to have the .attr syntax you describe – it definitely looks familiar, but I can't find it right now. Maybe it was removed... And it is definitely :=, not =.
Also, the only relevant library I know where 0.9.1 is a relevant version number is scala-js-dom, but that library doesn't provide anything like the example you're describing.
I have download EF6 using nuget (version 6.0.21010).
I can't find the DefaultSQLExecutionStrategy mentioned in this EF6 article - http://msdn.microsoft.com/en-us/data/dn456835
Can anyone tell me where it is... my System.Data.Entity.SqlServer only has SqlAzureExecutionStrategy and four other classes, but no DefaultSQLExecutionStrategy.
Thanks
It's here: https://entityframework.codeplex.com/SourceControl/latest#src/EntityFramework.SqlServer/DefaultSqlExecutionStrategy.cs. Note that this class is internal and is in the EntityFramework.SqlServer.dll.
EDIT
The article has been updated and it now says that this type is internal.
I searched the web for how to enforce srictfp in Scala but could not find any hint of it. There are some people complaining about it, but real solutions cannot be found. There is a bugtracker entry about it which is almost two years old. As it seems there is no elegant fix for it on the way I'm looking for workarounds.
My current idea is to set the appropiate method flag ACC_STRICT in the generated bytecode by myself somehow but I have no idea what would be the best solution to do so. A Scala Compiler Plugin comes to mind or just hacking flags in a hex editor. Maybe someone faced the same challenge and can tell me his or her solution?
You could add a post-processor in your build process that would add the strictfp modifier to the generated class (i.e. setting the ACC_STRICT flag as you say).
You can implement such a post-processor using Javassist for example. This could look like this:
CtClass clazz = ClassPool.getDefault().makeClass(
new FileInputStream("old/HelloWorld.class"));
CtMethod method = clazz.getDeclaredMethod("testMethod");
method.setModifiers(method.getModifiers() | Modifier.STRICT);
clazz.detach();
clazz.toBytecode(new DataOutputStream(new FileOutputStream(
"new/HelloWorld.class")));
You would then have to find a way to configure which classes/method need to be modified this way.
Scala has a strictfp annotation now:
#strictfp
def f() = …
As far as i know lucene(.net) doesn't support the wildcard at the beginning of a searchterm
--> http://lucene.apache.org/java/2_0_0/queryparsersyntax.html
"Note: You cannot use a * or ? symbol as the first character of a search."
for example
*myword
maybe because it's quiet difficult to search "everything" before the searchterm.
Despite that, We are looknig for a way to use the wildcard at the beginning.
Does anyone know if this is possible?
One Thought was asearchterm, bsearchterm, ....z*searchterm
... but that seems a bit random to me.
thanks in advance
Your question is tagged with Lucene.NET so I assume you mean the .NET version rather than the Java version.
Yes, you can have wildcards at the beginning of a search term by via
var queryParser = new QueryParser(LuceneVersion, "content", new StandardAnalyzer(LuceneVersion));
queryParser.SetAllowLeadingWildcard(true);
but you need to be aware of the performance consequences. Find more detailed source code in this blog.
Since Lucene.NET is a port of the Java version, I suspect you could use the same approach for the Java version. I didn't verify this, though.