We are migrating AjaxControlToolKit 3.02 to 16.1 used in a ASP.NET project.We have following code snippet in the existing 3.02 version:
AjaxControlToolkit.ScriptObjectBuilder.GetScriptReferences()
While AjaxControlToolKit version is updated to 16.1 the above code snippet is not complied due to unavailability of the ScriptObjectBuilder class and GetScriptReferences method. It seems the class is deprecated in the higer version of the library.
In that case, how the above code can be re-written to achieve the same functionality?
Any approach or suggestion would help us.
It seems that there is no direct analogue to this method.
The ToolkitResourceManager class is a successor of the ScriptObjectBuilder and has many methods for registering resources.
Foe example, it has GetControlScriptReferences(Type type) method. It calls GetEmbeddedScripts(params string[] toolkitBundles) internally, which is private now.
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 compiling some Vala code on ElementaryOS Loki, which ships with GTK Version 3.18. Now I get (a lot of) deprecated warnings like:
src/ScreenGrabber.vala:64.55-64.94: warning: Gdk.Display.get_device_manager has been deprecated since 3.20.
src/ScreenGrabber.vala:64.55-64.115: warning: Gdk.DeviceManager.get_client_pointer has been deprecated since 3.20
src/ScreenGrabber.vala:85.19-85.50: warning: Gdk.Screen.get_active_window has been deprecated since 3.22
But the recommended alternative methods that should be used in favor of the "deprecated" ones simply dont't exist in 3.18 yet, so I cannot use them.
How can I make valac giving me correct warnings for the given GTK Version? I tend to switch off warnings completely which I would rather like to avoid, if possible. valac has a switch --target-glib, but there is no equivalent "--target-gtk"
--
EDIT:
e.g. this little program demonstrates the problem if compiled with valac -o test test.vala --pkg=gtk+-3.0 (on ElementaryOS Loki, with GTK 3.18)
using Gtk;
public class Test {
public Test() {
var manager = Gdk.Display.get_default().get_device_manager();
}
public static int main(string[] args) {
var test = new Test();
return 0;
}
}
Probably the best solution is to use the --enable-deprecated switch when compiling with valac. You could also try --disable-since-check if that doesn't work. The --disable-since-check was introduced in Vala 0.32 with the new [Version] attribute.
In an ideal world a library would also distribute its binding for Vala. This would mean the binding is kept in sync with the library. See Vala Bindings Upstream guide.
Both GTK+ and Vala are GNOME hosted projects. Although Vala carries the GTK+ bindings, both projects are kept in sync and should work well together. Specifically relating to your question, GTK+ 3.18 was released 22 September 2015 and Vala 0.30 on the 18 September 2015. Both of these were in time for the GNOME 3.18 release on 23 September 2015.
What has happened with Loki is, according to the Loki beta release blog post, GTK+3.18 and Vala 0.32 have been bundled together. Vala 0.32 carries bindings for GTK+3.20.
So you could download the gtk+-3.0.vapi and gdk-3.0.vapi from the Vala 0.30.0 release and use that instead. This, unfortunately, will show a lot of different warnings because of the way version information is noted in VAPIs has recently changed. Vala now uses [Version] instead of [Deprecated]. These different warnings can be suppressed with --enable-deprecated.
If you contribute to a distribution then there is no fundamental reason why distributions need to bundle the Vala compiler with the bindings that come with the compiler. So they could have two, or more, packages. One for the compiler, one for the non-upstreamed bindings, e.g. vala-0.30 and vala-non-upstreamed-bindings-0.30. Although that is a bit of a simplification, for example Vala will continue to carry a binding some time after it has been generated upstream.
Have an interesting situation following the release of Java 1.8.0_25 into the wilds... I believe the root of my issue is related primarily to the new (to 1.8) features of "default" implementations within Interfaces.
The application I am working on is currently targeted at 1.7, which until now has been working well. Until users started updating to 1.8. Now that our users have started updating to 1.8, our hand is forced somewhat into moving to 1.8 support.
We have fixed most of the issues (mainly relating to changes to the JavaFX packages between 1.7 and 1.8) but have one vexing issue remaining.
In my wisdom, or lack thereof, I, some time ago, decided to create a SortedList<T> which extends from AbstractList<T>. Until now, this class has worked fine, however when running on a 1.8 runtime, I get:
Duplicate methods named spliterator with the parameters () and () are inherited
from the types Collection<T> and Iterable<T>
This, to me, appears to be caused by the "default" implementations in some of the Interfaces that are implemented by AbstractList<T> (my SortedList<T> class does not implement any additional Interfaces other than Serializable). Implementing Serializable is another problem for us, as we need to support deserialisation of SortedList<T> objects, there's no way around that!).
I can get rid of the error by providing an override implementation of spliterator() in my SortedList<T> class. However, if this is built, it no longer runs on a Java 1.7 environment. If I attempt to use SortedList<T> with a 1.7 runtime, I get:
Problem:
Error: Unresolved compilation problems:
The import java.util.Spliterator cannot be resolved
Spliterator cannot be resolved to a type
com.xxxx.xxxx.util.SortedList.<init>(SortedList.java:13)
This error is pretty obvious, since we've now overridden the spliterator() method in SortedList<T> it needs to include java.util.Spliterator, but that doesn't exist in 1.7.
Ideally we would like to NOT require our customers to update to Java 1.8 if they don't want to.
Is our hand being forced here? Do we need to force users to update to 1.8 and also roll out a new version to any users who have updated to 1.8 by themselves?
Does anyone know a way around this issue?
On a more philosophical note, why has Interface been corrupted with with implementation :-(. Might be a nifty new feature, but they really should have avoided doing anything that would result in breaking changes to existing code, particularly in something so fundamental as lists/collections etc.
Any help or suggestions regarding this predicament would be greatly appreciated.
Cheers,
Mark
The whole point of default methods is to avoid the situation you describe. The code below compiles and runs as expected with Java 7 and 8:
public class SortedList<T> extends AbstractList<T> implements Serializable {
#Override public T get(int index) { return null; }
#Override public int size() { return 0; }
public static void main(String[] args) {
SortedList<String> s = new SortedList<> ();
System.out.println(s.size());
}
}
Ok, so both of you (#Holger and #assylias) were correct... But, our situation is a little more complicated.
The environment we're working in is Eclipse 3.8.1 which doesn't support Java 8 (and won't in the future to my knowelege). So we can't just change to a Java 8
compiler to fix the issues.
Our product is a sizeable Eclipse RCP application. Upgrading our IDE is not currently an option, as there would be major rework involved. We will need to continue
to develop under a Java 1.7 environment for this reason.
If anyone is interested, we have resolved the issue by:
Creating fragments (one per Java version that causes issues, so three in our case) for our main plugin. These fragments are configured as patch fragments.
Added the Java FX JARs into the fragments (This was done to resolve some issues with Java FX in an earlier release and again for the 1.8.0_25 release).
Also in the fragments, in the same namespace as the main plugin, we added the implementation of the SortedList class. The code is identical for each case, but
the fragment for Java 8 is compiled specifically with a Java 8 compiler. Overriding the spliterator() method wasn't necessary in the end (when compiled with the Java 8
compiler, it works ok and still compiles with the 1.7 compiler as there is no reference to the Spliterator class anymore).
This is probably not an ideal solution, but it will work we think :-).
Thanks for your input & suggestions, much appreciated.
try Creating an abstract class that overrides the spliterator() with the prefered behaviour definition i.e.
abstract class Java8_AbstractCollection<E> extends AbstractCollection<E> {
/* (non-Javadoc)
* #see java.util.Collection#spliterator()
*/
public Spliterator<E> spliterator() {
return (Spliterator<E>) super.spliterator();
}
}
I need to know why this class JournalStructureServiceUtil is deprecated and I can't find it's replacement.
Does it have any replacement ?
I am using Liferay 6.2 e ga2.
If you see source of JournalStructureLocalServiceUtil.java or JournalStructureServiceUtil.java, it clearly has class comment as below.
#deprecated As of 6.2.0, since Web Content Administration now uses the Dynamic
Data Mapping framework to handle structures
So DDMStructureLocalServiceUtil.java or DDMStructureServiceUtil.java is it's replacement.
I have an Eclipse plugin and I am aiming for 3.1 or 3.2 as a minimum version to support. The problem is that some of my code only works in version 3.5 and above (see my other question: Is there an alternative to CaretListener in Eclipse?).
Now that I have code that works in the older versions and different code that works in the newer versions, is there a way that I can call the newer code only if my plugin is running in version 3.5 or above and then revert to the old code if running anything older?
As a test, I've created two plugins that have the same class within it (just doing slightly different things). I have marked the org.eclipse.ui dependency as a minimum of 3.5 in one plugin and 3.1 as a minimum in the other but I can't get the one that relies on 3.5 to be ignored in older versions...
Can anyone help?
Thanks,
Alan
You could use org.eclipse.core.runtime.Platform to get the org.eclipse.ui Bundle and check the version.
Version ui = Platform.getBundle("org.eclipse.ui").getVersion();
// then do something with that
Register MyListener if >=3.5, and OldMyListener otherwise.
EDIT:
Right, the above is only good for capturing differences in runtime behaviour.
Eclipse supports a couple of tricks for only loading some classes.
The easiest from a development point of view is the trick that #ShiDoiSi mentioned.
Bundle myBundle = org.osgi.framework.FrameworkUtil.getBundle(this.class);
Version ui = Platform.getBundle("org.eclipse.ui").getVersion();
Version cutOff = new Version(3,5,0);
final Executable processListener;
if (ui.compareTo(cutOff)<0) {
Class pc = myBundle.loadClass("my.pkg.OldListenerProcess");
processListener = (Executable) pc.newInstance();
} else {
Class pc = myBundle.loadClass("my.pkg.ListenerProcess");
processListener = (Executable) pc.newInstance();
}
processListener.execute(targetObject);
Another option that uses more of the eclipse framework would be defining your own extension point so that contributions from other bundles can decide which version to use. Basically it's the same pattern as above, except the version checking is done by the dependency ranges on the plugin the contributes the Executable to run. Depend on org.eclipse.ui [0.0.0,3.5.0) for the old way, and simply specifying org.eclipse.ui 3.5.0 (that's an open ended range on 3.5.0) for the current way. Then you can read your extension and instantiate the class provided.
If you were creating extra plugins for this (a little heavy weight for the 2 differences) you could define a command in your main plugin, and have the extra plugins provide the equivalent handler. The plugins would still have to have dependency ranges so that only one would load for the <3.5 or >=3.5 case. Then using the command API you could execute the command (and the correct handler would run).
ICommandService cmdS
= (ICommandService) workbenchWindow.getService(ICommandService.class);
Command process = cmdS.getCommand("my.pkg.ListenerProcess");
ParameterizedCommand cmd = new ParameterizedCommand(process, null);
IHandlerService handlerS
= (IHandlerService) workbenchWindow.getService(IHandlerService.class);
IEvaluationContext ctx = handlerS.createContextSnapshot(false);
ctx.addVariable("toAddListener", targetObject);
handlerS.executeCommandInContext(cmd, null, ctx);
Then your implementation of handler would use HandlerUtil.getVariable(event, "toAddListener") to extract the object you need from the ExecutionEvent.
It sounds to me that you should be supplying two plugins, one supporting version 3.1 to "just below" 3.5, and the other one from 3.5 upwards. So you don't really get to choose, it's basically the Eclipse plugin layer choosing the right one based on your version ranges.
Or if you provide just the compiled class files, then of course you could load the required class dynamically based on testing the version of the running Eclipse.