I am on a Project update from version vaadin 6 to vaadin 7. In the vaadin 7 version is used to a large extent the method getPaintable() from the class ApplicationConnection. Nevertheless it is deprecated in vaadin 7 . After examining the api and the official tutorial I have not detected and understood by what method or combination of methods it is replaced. If I want for example to do:
ComponentConnector paintable = this.client.getPaintable(uidl);
How can I excecute the above statement using excusively vaadin 7 (not deprecated) api?
Update:
The answer certifies my suspect that the method in ApplicationConnection getConnector(java.lang.String connectorId, int connectorType) should be used instead, but it is still missing, what is the int type connectorType and how one gets it. Any suggestion?
Update 2:
The replacement suggested in the answer seems reasonable and it might work but my worry is:
Should we use generally UIDL class in vaadin 7? I have the impression that the method updateFromUIDL(UIDL uidl, ApplicationConnection client)should not be called in vaadin 7. How can we the get uidl.getId() , uidl.getTag(). I reckon also that uidl.getId() should be replaced by the method in AbstractConnector getConnectorId(). Am I right?
Update:
After looking at the implementation of the deprecated getPaintable method, you should be able replace it with
ComponentConnector paintable = (ComponentConnector) getConnector(uidl.getId(),
Integer.parseInt(uidl.getTag()));
But don't forget that this can be only a intermediate step. Vaadin 7 changes the general mechanism for Client-Server interaction of widgets:
The old mechanism with UIDL, paintContent() and changeVariables() is still there for a while to ease migration, but it is recommended to update your components to the new mechanisms, which also tend to result in much cleaner code. Using the old mechanisms requires implementing LegacyComponent.
If you compare the integration diagrams of Vaadin 6 with Vaadin 7, you will see how the general integration mechanism have changed.
Original Answer:
Vaadin dev ticket: Deprecate ApplicationConnection.getPaintable(UIDL)
Description:
Functionality from getPaintable(UIDL) should be moved to getPaintable(String paintableId) and getPaintable(UIDL) should be deprecated
Change Log:
#8439 Deprecated ApplicationConnect.getPaintable(UIDL) and added getConnector(String id, String connectorType) instead
Related
My problem is that when I call (SsoUI) UI.getCurrent(), where SsoUI inherits from UI, I get a ClassCastException at runtime saying that UI cannot be cast to SsoUI.
Just to give some context, we implemented SSO between a suite of applications in Vaadin 7 using Hazelcast, and the Hazelcast instance reference is accessed through this class SsoUI. So at some point in our code there is this line:
HazelcastInstance hi = SsoUI.getCurrentSsoUI().getHazelcastInstance();
where
public static SsoUI getSsoUI() {
return (SsoUI) UI.getCurrent();
}
and everything works fine.
So now we are developing new applications on vaadin 14 and I tried to replicate the same structure to handle single sign on, but now I get the error I wrote at the beginning, a ClassCastException.
Am I missing something or are there differences between UI in vaadin 7 and UI in vaadin 14 which render this approach unusable?
Edit: to clarify, SSO stands for Single Sign On and SsoUI is my custom class which extends UI.
Am I missing something or are there differences between UI in vaadin 7 and UI in vaadin 14 which render this approach unusable?
Yes, there is a difference. You're not expected to extend the UI class in Vaadin 10 or later.
To quote Leif Åstrand of Vaadin Ltd.:
Using a custom UI class has been deprecated but still functioning since Vaadin 10. We would like to encourage application developers to move away from that pattern so that we could eventually simplify the internal implementation. …
ComponentUtil
If you need to store some object so that it's accessible where the current UI object is available, you can use the ComponentUtil class to map values to the current UI instance.
To set a value:ComponentUtil.setData(UI.getCurrent(), \[key or class\], \[value\])
To read a value:ComponentUtil.getData(UI.getCurrent(), \[key or class\])
I am having a restfull service and there are more than 20 clients thats is using this service.
#Path("/provider")
public class Provider{
#Path("/simpleprovider")
#GET
public String getProvider(){
return "Simple Provider";
}
}
Now i have decided to introduce version in service, i have google alot, read my articles but i am totally confused how should i do? suppose i change URI for new service like #Path("/provider/v1") than how should i provide support for existing clients ? by considering this thing should i have to provide change on every client whenever api new version comes in action ?
After Googling i found that there are 3 ways to provide versioning
URL versioning
custom request header
content type
but could not find any practical example please help me in this regard
http://stackoverflow.com/questions/389169/best-practices-for-api-versioning
http://www.narwhl.com/2015/03/the-ultimate-solution-to-versioning-rest-apis-content-negotiation/
http://restcookbook.com/Basics/versioning/
http://www.troyhunt.com/2014/02/your-api-versioning-is-wrong-which-is.html
http://www.lexicalscope.com/blog/2012/03/12/how-are-rest-apis-versioned/
Any help will be greatly appreciated
Versioning a service can be very tricky and is always a big decision when determining the versioning strategy. Especially if you have people using the service. From my experience here are some things to consider:
Understand and communicate when and if you plan on sun setting versions of your API. The last thing you want to have is a problem where you are having to upkeep 10 different versions of an API.
Understand if a version change is absolutely necessary. A good rule of thumb is if core functionality is changing or if the contract can potentially break someones software that is integrating with your API. Here are some things to consider when determining if you really need to version:
If you are removing fields from a resource.
If you are removing (or updating) a URL (or method).
If an existing endpoint (or method) logic is going to change such that it would require a consumer to re-implement.
Overall, if a change that you make would break someone integrating with your API.
Are you going to require database changes that would not be backwards compatible with your previous version(s)? This is when versioning can get really fun (sarcastically) because now you might have to make your database backwards compatible which, in my experience, can be difficult problem to deal with moving forward.
To answer your question, though, I have found the best way to version to be in the URL. Be very simple and deliberate with your versioning so that it is crystal clear for your integrator. For example:
GET /v1/products/{id} // Version 1
GET /v2/products/{id} // Version 2
** If you decide on URL versioning then my advice is to put do "v" for version and a SINGLE number like 1 or 2. Don't get into versions, sub versions, etc... This will make your API seem like it revs a lot which can cause concern for consumers. Also, keep the version as FAR left of the URL as possible. The idea is that everything to the right of the version is the new versioned resource.
I would AVOID using headers to version your service. You don't want to hide versions from your consumer. Be as transparent and explicit about versioning as you possibly can.
Versioning in the URL allows you to also do some useful routing and things on your web server and proxies as well. You can either version like this in your actual code, for example:
[HttpGet("v1/products")]
public Product GetProduct(string id)
{
return _repository.GetProduct(id);
}
or you can version using your web server by setting up virtual directories (or whatever). Then your code might look something like this instead:
[HttpGet("products")]
public Product GetProduct(string id)
{
return _repository.GetProduct(id);
}
However you decide to version it is very important to think about the pro's and con's of each decision and weigh them because if you are running an API that people are using the bad decisions will catch up to you in a hurry.
In the documentation of HttpResponseCache there is a section:
Working With Earlier Releases
This class was added in Android 4.0 (Ice Cream Sandwich). Use
reflection to enable the response cache without impacting earlier
releases:
try {
File httpCacheDir = new File(context.getCacheDir(), "http");
long httpCacheSize = 10 * 1024 * 1024; // 10 MiB
Class.forName("android.net.http.HttpResponseCache")
.getMethod("install", File.class, long.class)
.invoke(null, httpCacheDir, httpCacheSize);
}
catch (Exception httpResponseCacheNotAvailable) {
}
You can see this call via reflection in a questions here on SO (e.g. here), and examples on the web. I also took over code that contains this exact snippet to set up the cache (including the comment, so its probably just copypasta). However, I don't quite understand why you have to use reflection here.
Normally when I want to use a method added at a certain API level above my defined minSdkVersion, I would use the following pattern:
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.HONEYCOMB) {
// do something here
}
so why isn't this the default pattern for HttpResponseCache. What is the advantage of using reflection? It certainly doesn't add to the readability of my code. Does HttpResponseCache actually work below ICS when using reflection this way?
EDIT: I don't have an old Android device here and my emulator refuses to start at all, so I can't simply test it at the moment. Maybe it just crashes horribly without reflection.
What is the advantage of using reflection?
First, quoting the documentation:
This class was added in Android 4.0 (Ice Cream Sandwich).
By "was added", they mean "was added to the Android SDK", and by "Ice Cream Sandwich", they really mean Android 3.2 (API Level 13) based on the rest of the JavaDocs.
However, the HttpResponseCache class itself has existed in the framework for longer, hopefully since Android 1.0 given their recommendations. However, that class was marked with the #hide annotation, so it could not be used directly by apps until API Level 13.
Your Java version guard block using Build will avoid referencing this class directly on older devices. However, it does not actually configure the cache on older devices, either.
Their approach will work on all versions of Android and will allow you to configure the cache, as the class has existed since the beginning.
It is fairly rare that Google explicitly authorizes the use of reflection to get at hidden classes or methods this way, which is why you don't see it often in official documentation.
Unfortunately your suggestion will not work for older versions. Think about the following. They added method install(File, long) to new version. But the code that calls this method is packaged into other jar.
Now you have old version of jar that contains HttpResponseCache and new version of jar that calls it. If you write there
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.HONEYCOMB) {
cache.install(file, number);
}
NoSuchMethodError will be thrown even if expression of if is false.
Using reflection is a ugly but useful technique to prevent this.
I am converting the PHP plugin to ColdFusion. In PHP, there are used OO concepts so classes and objects are used.
How I can convert those classes to ColdFusion class and create objects for those classes.
Also I have created Java class and using <cfobject> tag, I have created object, but I need ColdFusion classes and created objects.
Please let me know if you have any ideas.
ColdFusion does have classes and objects and follows limited OOPS principles. You can do inheritance, interfaces. Polymorphic functions is still not allowed.
Classes in ColdFusion are called as Components. CFC -> ColdFusion component. Depending on the ColdFusion version, you can write them in script mode or in tag mode.
You can refer to the documentation for CF8 about creating component and their objects.
The createObject() method you have mentioned is one way of creating different type of objects. The other ways are to use <cfinvoke> or <cfobject>
Hope this helps. Just read the docs in detail and they will help you every time.
Realistically you should be able to solve this by reading the docs a bit more thoroughly than you already have. However this question is fairly easily answered. Firstly let me disabuse you of something though:
there is no option to create classes in coldfusion without using the
java,com and corba
This is just you not reading properly. Even on the page you link to (cfobject, which is pointing to an obsolete version of ColdFusion btw), the third link it provides "component object" discusses instantiating native CFML "classes" ("components" in CFML parlance, for some reason). It's perhaps not clear from top-level browsing that a "component" is a "class", but if you're learning something, you should be doing more than top-level browsing.
You are approaching your learning from a very odd angle: reading up on how to instantiate an object is not the direction you ought to be taking if you want to find out how to define the class the object will be an instance of. It kinda suggests a gap in your knowledge of OO (which could make this work a challenge for you).
Anyway, of course CFML allows for the definition of classes and the usage thereof, natively in the language. And has been able to do so since v6.0 (although this was not really production-ready until 6.1, due to some poor implementation decisions), over a decade ago.
The answer to your broader question, can be found by reading the docs starting with "Building and Using ColdFusion Components". But the basic form is:
// Foo.cfc
component {
public Foo function init(/* args here */){
// code here
}
// etc
}
And that sort of thing.
This question already has answers here:
What’s the current state of closures in Java?
(6 answers)
Closed 9 years ago.
So is Java 7 finally going to get the closures? What's the latest news?
Yes, closures were include to release plan of java 7 (and it was the most significant reason to delay release from winter to autumn (expected in September 2010)).
The latest news could be found at Project Lambda. You may also be interested in reading latest specification draft.
There is no official statement on the state of closures at the moment.
Here are some readable examples of how it could work and look like.
If you want to get some insight into what's going on I refer you to the OpenJDK mailing list.
Overview
Basically there is some hope, because code together with some tests were already committed to some source code branch and there are at least some halfway working infrastructure to test it.
The change message from Maurizio Cimadamore reads:
initial lambda push; the current prototype suuports the following features:
function types syntax (optionally enabled with -XDallowFunctionTypes)
function types subtyping
full support for lambda expression of type 1 and 2
inference of thrown types/return type in a lambda
lambda conversion using rules specified in v0.1.5 draft
support references to 'this' (both explicit and implicit)
translation using method handles
The modified script build of the
langtools repository now generates an
additional jarfile called javacrt.jar
which contains an helper class to be
used during SAM conversion; after the
build, the generated scripts
javac/java will take care of
automatically setting up the required
dependencies so that code containing
lambda expressions can be compiled and
executed.
But this is ongoing work and quite buggy at the moment.
For instance the compiler sometimes crashes on valid expressions, doesn't compile correct closure syntax code or generates illegal byte code.
On the negative side there are some statements from Neal Gafter:
It's been nearly three months since the 0.15 draft, and it is now less
than two weeks before the TL (Tools and Languages) final integration
preceding openjdk7 feature complete. If you've made progress on the
specification and implementation, we would very much appreciate it being
shared with us. If not, perhaps we can help. If Oracle has decided that
this feature is no longer important for JDK7, that would be good to know
too. Whatever is happening, silence sends the wrong message.
A discussion between Neal Gafter and Jonathan Gibbons:
Great to see this, Maurizio! Unfortunately it arrives a week too late, and
in the wrong repository, to be included in jdk7.
I notice that none of the tests show a variable of function type being
converted to a SAM type. What are the plans there?
Jonathan Gibbons' response:
Since the published feature list for jdk7 and the published schedule for
jdk7 would appear to be at odds, why do you always assume the schedule
is correct?
Neal Gafter's answer:
Because I recall repeated discussion to the effect that the feature set
would be adjusted based on their completion status with respect to the
schedule.
Some people even question if the whole thing makes sense anymore and suggest moving to another language:
One starts to wonder, why not just move to Scala -- there's much more
that needs to be added to Java in order to build a coherent combination
of features around lambdas. And now these delays, which affect not just
users of ParallelArray but everyone who wants to build neatly refactored,
testable software in Java.
Seems like nobody's proposing to add declaration-site variance in Java
=> means FunctionN<T, ...> interfaces will not subtype the way they should.
Nor is there specialization for primitives. (Scala's #specialized is
broken for all but toy classes, but at least it's moving in the right
direction)
No JVM-level recognition that an object is a closure, and can hence be
eliminated, as it can be with Scala's closure elimination (if the HOF can
also be inlined.) The JVM seems to add something like an unavoidable machine
word access to every polymorphic call site, even if they are supposedly
inline-cached and not megamorphic, even inside a loop. Result that I've
seen is approximately a 2x slowdown on toy microbenchmarks like "sum an array
of integers" if implemented with any form of closures other than something
that can be #inline'd in Scala. (And even in Scala, most HOF's are virtual
hence can't be inlined.) I for one would like to see usable inlining in a
language that /encourages/ the use of closures in every for loop.
Conclusion
This is just a quick look at the whole problem going on and the quotes and statements are not exhaustive at all. At the moment people are still in the state of "Can closures really be done in Java and if yes, how should it be done and how might it look like?".
There is no simple "OK, we just add closures to Java over the weekend".
Due to the interaction of some design mistakes like varargs as arrays, type erasure ... there are cases which just can't work. Finding all these small problems and deciding if they are fixable is quite hard.
In the end, there might be some surprises.
I'm not sure what that surprise will be, but I guess it will be either:
Closures won't get into Java 7 or
Closures in Java 7 will be what Generics were in Java 5 (Buggy, complex stuff, which looks like it might work, but breaks apart as soon as you push things a bit further)
Personal opinion
I switched to Scala a long time ago. As long as Oracle doesn't do stupid things to the JVM, I don't care anymore. In the evolutionary process of the Java language mistakes were made, partly due to backward compatibility. This created an additional burden with every new change people tried to make.
Basically: Java works, but there will be no evolution of the language anymore. Every change people make increases the cost of making the next change, making changes in the future more and more unlikely.
I don't believe that there will be any changes to the Java language after Java 7 apart from some small syntax improvements like project Coin.
http://java.dzone.com/news/closures-coming-java-7
The latest news is AFAIK still as of late Nov 2009 that closures will be in Java 7 in some form. Since this was given as the main reason for a significant delay in the release, it seems pretty unlikely that they'll drop it again.
There's been a whole lot of syntax and transparency related debating (particularly focusing on how hard to read a currying function with a particular syntax is, it seems like) going on on the lambda-dev mailing list, and there have been a couple draft proposal iterations from Sun, but I haven't seen much from them on that list in a while.
I'm at a release conference now and the speaker is saying closures are coming to Java 8.