GraphStream styling without hideous strings/absolute file paths? - java

In the GraphStream documentation, it is stated that we can style a graph by the following ways:
This attribute must be stored on a graph and takes as value either the
style sheet itself as a string of characters or the URL of a file,
local, distant or packaged in a jar.
You can for example change the background color of the graph using a
style sheet given as a string this way:
graph.addAttribute("ui.stylesheet", "graph { fill-color: red; }");
But you can also specify an URL:
graph.addAttribute("ui.stylehseet",
"url('http://www.deep.in/the/site/mystylesheet')");
Or:
graph.addAttribute("ui.stylesheet",
"url(file:///somewhere/over/the/rainbow/stylesheet')");
However, I experimented with this, and came to the conclusion that GraphStream only supports absolute file paths for this attribute. This is an issue since I will ultimately be exporting the application as a JAR file, and although I have found that you can circumvent the issue by doing something like:
ClassLoader.getSystemClassLoader().getResource(".").getPath(‌​);
there is uncertainty associated with this method (i.e. it may not work on certain machines, such as Linux machines (?)).
In which case, my current hack is to store the 'stylesheet' as a long string, something like this:
private static final String GRAPH_DISPLAY_STYLESHEET =
"graph { fill-color: white; }" +
"node {" +
"fill-color: black;" +
"shape: rounded-box;" +
"shadow-mode: plain;" +
"shadow-color: #C8C8C8;" +
"shadow-width: 4;" +
"shadow-offset: 4, -4;" +
"text-background-mode: rounded-box;" +
"text-padding: 5;" +
"text-background-color: black;" +
"text-color: white;" +
"text-size: 20;" +
"size-mode: fit;}" +
"edge { fill-color: black; }";
which is frankly very unsightly.
Does anyone have any ideas about how to improve this situation? Thanks in advance!

Using an embedded-resource and getResource() is the way to go. To avoid file system vagaries, try one of these approaches:
Use one of the approaches adduced here to convert each resource to a String suitable for addAttribute().
Load an instance of java.util.Properties with your styles, as shown here and here, so that each style is available as a String suitable for addAttribute().

Related

What is the most efficient selector to use with findElement()?

When working with Selenium web testing, there are a few ways to identify WebElements.
In my experience, I have used the following selectors:
Class Name - By.className()
CSS Selector - By.cssSelector()
ID - By.id()
Link Text - By.linkText()
Name - By.name()
Tag Name - By.tagName()
XPath - By.xpath()
Obviously, when only one option is usable to locate an element, we must use that one, but when multiple methods may be used (ex: the div below), how should it be determined which method to use? Are there selectors that are more efficient than others? Are there some that are more durable?
<div class="class" id="id" name="name">Here's a div</div>
Just for s&gs...
I timed each of the identifier methods finding the div above five separate times and averaged the time taken to find the element.
WebDriver driver = new FirefoxDriver();
driver.get("file://<Path>/div.html");
long starttime = System.currentTimeMillis();
//driver.findElement(By.className("class"));
//driver.findElement(By.cssSelector("html body div"));
//driver.findElement(By.id("id"));
//driver.findElement(By.name("name"));
//driver.findElement(By.tagName("div"));
//driver.findElement(By.xpath("/html/body/div"));
long stoptime = System.currentTimeMillis();
System.out.println(stoptime-starttime + " milliseconds");
driver.quit();
They are sorted below by average run time..
CssSelector: (796ms + 430ms + 258ms + 408ms + 694ms) / 5 = ~517.2ms
ClassName: (670ms + 453ms + 812ms + 415ms + 474ms) / 5 = ~564.8ms
Name: (342ms + 901ms + 542ms + 847ms + 393ms) / 5 = ~605ms
ID: (888ms + 700ms + 431ms + 550ms + 501ms) / 5 = ~614ms
Xpath: (835ms + 770ms + 415ms + 491ms + 852ms) / 5 = ~672.6ms
TagName: (998ms + 832ms + 1278ms + 227ms + 648ms) / 5 = ~796.6ms
After reading #JeffC 's answer I decided to compare By.cssSelector() with classname, tagname, and id as the search terms. Again, results are below..
WebDriver driver = new FirefoxDriver();
driver.get("file://<Path>/div.html");
long starttime = System.currentTimeMillis();
//driver.findElement(By.cssSelector(".class"));
//driver.findElement(By.className("class"));
//driver.findElement(By.cssSelector("#id"));
//driver.findElement(By.id("id"));
//driver.findElement(By.cssSelector("div"));
//driver.findElement(By.tagName("div"));
long stoptime = System.currentTimeMillis();
System.out.println(stoptime-starttime + " milliseconds");
driver.quit();
By.cssSelector(".class"): (327ms + 165ms + 166ms + 282ms + 55ms) / 5 = ~199ms
By.className("class"): (338ms + 801ms + 529ms + 804ms + 281ms) / 5 = ~550ms
By.cssSelector("#id"): (58ms + 818ms + 261ms + 51ms + 72ms) / 5 = ~252ms
By.id("id") - (820ms + 543ms + 112ms + 434ms + 738ms) / 5 = ~529ms
By.cssSelector("div"): (594ms + 845ms + 455ms + 369ms + 173ms) / 5 = ~487ms
By.tagName("div"): (825ms + 843ms + 715ms + 629ms + 1008ms) / 5 = ~804ms
From this, it seems like you should use css selectors for just about everything you can!
In my experience, I use these locators in this order:
id
linkText/partialLinkText
CSS Selector
XPath
The others: class name, tag name, name, etc. can all be found using CSS selectors. I rarely need a single class name so I prefer CSS selector so that I can use more than one class but also specify a tag name to make it more specific and less likely to break. Tag name is rarely used... unless we are talking about a TABLE or TR or TD tags and those can all be done with CSS Selectors. I generally find that tags with a name also have an id so I prefer id.
I recently found, as you did in your answer, that CSS selector is the fastest. This makes sense because Selenium is using the browser to do the searches and CSS selectors are so common that the different browsers have optimized performance for their use.
linkText/partialLinkText are very specialized so I don't really count them. I use them when I can and it makes sense. I have thought about just using By.cssSelector("#someId") but I don't think it really makes that much of a difference and By.id() is just a little more obvious when using an Id.
I rarely use XPath and only when I can't accomplish it with other locators, e.g. in the case of text from a tag or some weird child/descendant thing that I can't do with CSS selectors. I found (and read) that XPath support is varied by browser and it's slower so I avoid it unless absolutely necessary... and I have found you can locate 99% of elements with #1-3.
ids should be the most durable. LinkText and partialLinkText are probably fairly durable, depending on the page. Classes applied and the structure of the HTML that you would use with CSS selectors are probably the most likely to change with a page update. It really depends on the size of the update as to whether a partial portion of a page is changed. CSS Selectors and XPath would both (generally) be affected by these sorts of changes.
In the end... as long as you aren't scraping the page for hundreds of elements, one page transition is likely to be WAY more significant than a few hundred ms of difference between locator methods.
I'd prioritise selectors like this:
ID - By.id()
Name - By.name()
CSS Selector - By.cssSelector()
XPath - By.xpath()
Tag Name - By.tagName()
Link Text - By.linkText()
However, uniq IDs and Names are not always exist. Also you can use CSS Selectors to locate by ID #element_id or by Name [name=element_name] or by ClassName .element_class, so might be good idea to use CSS Selectors instead ID, Name and ClassName. Css is faster than xPath, so it's better to use it where possible. xPath is good for difficult element locators which CSS Selectors can't find. I also wouldn't use Tag Name and Link Text as you can write the same with xPath(For Link Text //a[text()='link_text'], Tag Name //div) or CSS Selectors(For Tag Name div ).
Locators should be descriptive, unique, and unlikely to change. So my priority is as follows:
ID - You'll get the exact element you want and it can be descriptive and won't be changed by mistake.
Class - Very descriptive, probably unique in context of parent element.
CSS - Better performence than XPath - see Dave Haeffner's great benchmark.
XPath - Has capabilities that CSS doesn't like Axis e.g. ::parent and functions like contains().
I would avoid LinkText and TagName as they tend to cause unexpected failures due to very generic filtering.
Note on CSS and XPath: Using these with something like //div/li[1]/*/span[2] or div > li:nth-child(1) should also be avoided as they depend on the rendering and prone to changes.

GATE usage in java Netbeans

I am trying to write an application from extracting entities from a text and want to use GATE jar files. For which I have installed the GATE tool and have imported jar files, but it is giving errors. I can't understand from where to download more jar files and how to run the first simple program with this.
Please make sure that you added gate.jar from YOUR_GATE_HOME/bin folder.
From your screenshot I can assume that you used an example provided by GitHub. This example looks good, except one part (from my point of view of course). I would suggest to replace output piece with the next more readable code:
String text = "Steve works for Apple Inc in California.";
Document gateDocument = Factory.newDocument(text);
corpus.add(gateDocument);
// tell the ANNIE application about the corpus and run it
annie.setCorpus(corpus);
annie.execute();
List<Annotation> personAnnotations = gateDocument.getAnnotations().get(ANNIEConstants.PERSON_ANNOTATION_TYPE).inDocumentOrder();
for (Annotation personAnnotation : personAnnotations) {
System.out.println("Entity Text: " + gate.Utils.stringFor(gateDocument, personAnnotation) + " Features: " + personAnnotation.getFeatures());
}
Similar things could be done for Location, Organisation and other Entity types defined in GATE. Also do not forget to release resources with Factory.deleteResource().

Eclipse RCP: How to programmatically get Problems View records

On Eclipse Luna, I need to programmatically build java projects and then retrieve the Problems View's records. I use the following code
IWorkspace workspace = ResourcesPlugin.getWorkspace();
IResource resource = workspace.getRoot();
IMarker[] markers = resource.findMarkers(IMarker.MARKER, true, IResource.DEPTH_INFINITE);
for (IMarker m : markers) {
System.out.println("Id: " + m.getId());
System.out.println("Message: " + m.getAttribute(IMarker.MESSAGE));
System.out.println("Source ID: " + m.getAttribute(IMarker.SOURCE_ID));
System.out.println("Location: " + m.getAttribute(IMarker.LOCATION));
System.out.println("Line Number: " + m.getAttribute(IMarker.LINE_NUMBER));
System.out.println("Marker: " + m.getAttribute(IMarker.MARKER));
}
The message and line number are printed correctly. But IMarker.SOURCE_ID returns "JDT" and IMarker.LOCATION is always null.
Anybody knows how can I get the data shown as "Resource" and "Path" on the Problems View? I cannot create any custom Marker view using MarkerSupportView. I need to access the existing Problems View in a programmatic way. Thank you for any suggestion.
Got it. Use getResource() instead of getAttribute().
The markers API is pretty flexible, you should read the documentation.
Long story short, there will be other attributes that you're not looking at. Try calling getAttributes and dumping them out.

Minecraft 1.7.2 setting textures efficiently

I set textures in each individual file, this is the non efficient way to set it
this.setUnlocalizedName("ItemName");
this.setTextureName("MyModName:ItemName");
This way made sense to me, but didn't work:
this.setUnlocalizedName("ItemName");
this.setTextureName(OtherClassName.MODID + ":" + this.getUnlocalizedName());
the 'OtherClassName.MODID' is referring to a variable in another class that contains 'MyModName'
The this.getUnlocalizedName() gets the UnlocalizedName that has been declared, 'ItemName'
Any help? I am not sure why it doesn't work.
getUnlocalizedName is slightly weird - it returns the string you passed into setUnlocalizedName, but with "item." at the start. The joys of working with deobfuscated code...
This would work:
String name = "ItemName";
this.setUnlocalizedName(name);
this.setTextureName(OtherClassName.MODID + ":" + name);
Note that it's not more efficient as in faster to run, but it might be faster to write if you change the item name a lot.

How can i send an query from java to lpsolve as String

Hi i formulated a linear programing problem using java
and i want to send it to be solved by lpsolve without the need to create each constraint seperatlly.
i want to send the entire block (which if i insert it to the ide works well) and get a result
so basically instead of using something like
problem.strAddConstraint("", LpSolve.EQ, 9);
problem.strAddConstraint("", LpSolve.LE, 5);
i want to just send as one string
min: 0*x11 + 0*x12 + 0*x13
x11 + x12 + x13= 9;
x12 + x12<5;
can it be done if so how?
LpSolve supports LP files as well as MPS files. Everything is thoroughly detailed in the API documentation (see http://lpsolve.sourceforge.net/5.5/).
You can do your job like this in java :
lp = LpSolve.readLP("model.lp", NORMAL, "test model");
LpSolve.solve(lp)
What is sad with file based approaches is that you will not be able to use warm start features. I would not suggest you to use such approach if you want to optimize successive similar problems.
Cheers

Categories