I see deprecated log of TYPO3 v6.2x
There are many functions remove from GeneralUtility.php
Is there any alternative of GeneralUtility::getUniqueName($theFile, $theDest, $dontCheckForUnique=0); ?
Thanks in advance.
The function is removed because it's not needed anymore since FAL was introduced in TYPO3 6.0. You can find alternatives in the FileReference object see: FileReference Class Reference.
Methods like getIdentifier() and getPublicUrl() can now be used.
Related
I see kotlin.List and kotlin.MutableList is implemented by java.util.ArrayList. But where did kotlin put this trick? Compiler or somewhere in stdlib?
If kotlin supports making a class implementing an interface outside of its definition file like the ArrayList case, it will be fascinated.
No, it is not supported.
You are right, that is only a compiler trick. There are lots of magic applied to the collections to make them right. Fortunately it is not available to the devs. Special paragraph in the docs: https://kotlinlang.org/docs/reference/java-interop.html#mapped-types
I'm writing a plugin for Eclipse Juno, I want to make use of class AbstractSourceLookupDirector. When I look at the API it says it has a constructor, but when I use following statement in my code, it says "cannot instantiate type AbstractSourceLookupDirector"
AbstractSourceLookupDirector srclookupDir = new AbstractSourceLookupDirector();
Could you please let me know how to make use of AbstractSourceLookupDirector.
Ref: http://help.eclipse.org/indigo/topic/org.eclipse.platform.doc.isv/reference/api/org/eclipse/debug/core/sourcelookup/AbstractSourceLookupDirector.html
Many thanks in advance!
It is an Abstract class, you can't instantiate abstract classes in Java.
What you need to do is configure an extension point org.eclipse.debug.core.sourceLocators
and have your class extend AbstractSourceLookupDirector
An example is given in the juno docs
http://help.eclipse.org/juno/index.jsp?topic=%2Forg.eclipse.platform.doc.isv%2Freference%2Fextension-points%2Forg_eclipse_debug_core_sourceLocators.html
If you request an unbound object from NInject, then the default behaviour is (if a suitable constructor is available) appears to be to create an instance of the appropriate object.
I'd like to disable this behaviour (I had a difficult to debug issue because something was auto-bound instead of picking up my custom binding in a module). This question hints that it is possible, but I'm unable to find the answer from the NInject wiki.
Remove the SelfBindingResolver from the kernel components after creation:
kernel.Components.RemoveAll<IMissingBindingResolver>();
kernel.Components.Add<IMissingBindingResolver, DefaultValueBindingResolver>();
The following is a better, more direct way of removing the SelfBindingResolver, without assuming that the DefaultValueBindingResolver is the only other IMissingBindingResolver component:
kernel.Components.Remove<IMissingBindingResolver, SelfBindingResolver>();
It's possible the Remove<T, TImplementation>() method was only added in a recent version of Ninject, but this works for me using Ninject 3.2.2.0.
I've just started using RestKit, and got an issue when trying to create RKObject subclass; apparently, such class is not found, but this example http://mobile.tutsplus.com/tutorials/iphone/restkit_ios-sdk/ shows how to make it. I installed it and it seems to be working ok.
So I am wondering whether that class was removed and there is an alternative or am I doing something wrong here?
Yes, RKObject was removed. Here is an answer to the same question.
Simple question... I want to use Ninject Interceptors to take care of my NFRs, however alot of my classes require arguments in the constructors. I read that they are looking at allowing constructors with arguments but currently I get an error:
Can not instantiate proxy of class: myClass
Could not find a parameterless constructor.
Parameter name: constructorArguments
I am using version 2.2.1 I think, noticed there is a tagged 2.3 version on the extensions site, but will any of this solve my problems? if not is there any way around this?
2.3 adds support for Interface proxies. This means it will solve the problem for all types that are resolved by interface. It's also planned to add support for classes without default constructor.
But be aware that 2.3 is work in progress. While there aren't any known new problems it is not tested yet against real applications as 2.2 is and interface changes of new stuff can still change. Also InRequestScope support for XML and Conventions has temporarily been disabled.