I am loading a JSON-LD document using Jena:
Model mj = RDFDataMgr.loadModel([filename]);
The actual content being loaded is here: http://build.fhir.org/account-example.jsonld
Jena goes off and resolves the context, and returns an error (LOADING_REMOTE_CONTEXT_FAILED - lovely suppression of the actual cause in the Jena code :-(). But I need to override the context anyway, and use a different source, because I am doing the build for what will be posted at build.fhir.org, and I need to use my local versions instead. I can't see how to override the context resolution
Alternatively, I could use the loading method documented here: https://github.com/jsonld-java/jsonld-java#code-example - but I have no idea how to get to a Jena graph from there (and I haven't figured out how make the custom resolution work in my Eclipse context either)
How can I get to a Jena graph using a context defined in code somewhere?
I think Jena devs are subscribed to the relevant tag RSS streams. They might weigh in on the clarity of LOADING_REMOTE_CONTEXT_FAILED error. But it seems pretty clear to me.
In order to override the context, you can use read(Model model, String uri, Context context) method. ModelFactory.createDefaultModel() will create a intance of a Model that you can pass as a first argument. See more examples here: https://github.com/apache/jena/tree/master/jena-arq/src-examples/arq/examples/riot
Alternative library is not Jena-compatible (nor RDF4J, which strikes me as rather silly), so there is no easy way to use it with Jena-dependent code.
Finally, you provided the code example for getting a model but now mention a graph – there is a method for that as well: read(Graph graph, String uri, Context context).
Related
I am trying to use Dart to tersely define entities in an application, following the idiom of code = configuration. Since I will be defining many entities, I'd like to keep the code as trim and concise and readable as possible.
In an effort to keep boilerplate as close to 0 lines as possible, I recently wrote some code like this:
// man.dart
part of entity_component_framework;
var _man = entity('man', (entityBuilder) {
entityBuilder.add([TopHat, CrookedTeeth]);
})
// test.dart
part of entity_component_framework;
var man = EntityBuilder.entities['man']; // null, since _man wasn't ever accessed.
The entity method associates the entityBuilder passed into the function with a name ('man' in this case). var _man exists because only variable assignments can be top-level in Dart. This seems to be the most concise way possible to use Dart as a DSL.
One thing I wasn't counting on, though, is lazy initialization. If I never access _man -- and I had no intention to, since the entity function neatly stored all the relevant information I required in another data structure -- then the entity function is never run. This is a feature, not a bug.
So, what's the cleanest way of using Dart as a DSL given the lazy initialization restriction?
So, as you point out, it's a feature that Dart doesn't run any code until it's told to. So if you want something to happen, you need to do it in code that runs. Some possibilities
Put your calls to entity() inside the main() function. I assume you don't want to do that, and probably that you want people to be able to add more of these in additional files without modifying the originals.
If you're willing to incur the overhead of mirrors, which is probably not that much if they're confined to this library, use them to find all the top-level variables in that library and access them. Or define them as functions or getters. But I assume that you like the property that variables are automatically one-shot. You'd want to use a MirrorsUsed annotation.
A variation on that would be to use annotations to mark the things you want to be initialized. Though this is similar in that you'd have to iterate over the annotated things, which I think would also require mirrors.
This is more of a conceptual question.
I had to work on a functionality that had to create a dynamic h:dataTable. And whenever I created a component, I did something similar to this:
DataTable table = (DataTable) FacesContext.getCurrentInstance().getApplication()
.createComponent(DataTable.COMPONENT_TYPE);
Using the FacesContext to create everything for me.
However I could just as simply have done this:
DataTable table = new DataTable();
The reason I did it in the first way is that all the tutorials and material I read while developing did it that way, but I never got a clear answer why.
Is there an actual reason why the first is better than the second?
The Application#createComponent() adds an extra abstract layer allowing runtime polymorphism and pluggability. The concrete implementation is configurable by <component> entry in faces-config.xml which could in turn be provided via a JAR. This allows changing implementation without rewriting/recompiling the code.
It's exactly like as how JDBC API works: you don't do new SomeDriver(), but you do Class.forName(someDriverClassName) which allows the driver to not be a compiletime dependency and thus your JDBC code to be portable across many DB vendors without rewriting/recompiling.
However, if the application is for "internal usage" only and not intented to be distributable (and thus all the code is always full under you control), then runtime polymorphism has not a so big advantage and may add (very minor) overhead.
See also:
What is the relationship between component family, component type and renderer type?
I'm trying to bind a XML response from a WS to a set of POJO's classes using ksoap2-android.
A lot of examples on the internet treat very simple responses like this one.
In my case however, I have a lot of custom classes and they keep a reference of each other, sometimes even inside an arraylist.
Here's what i'm trying to do, i would like to bind this kind of response :
<Car number="35">
<Engine>
[...]
</Engine>
<Passenger id="1">
[...]
</Passenger>
<Passenger id="2">
[...]
</Passenger>
</Car>
To this kind of class :
public class Car {
private int number;
private Engine engine;
private ArrayList<Passenger> passengers;
}
With, if possible, only modifying POJOs files (the Simple XML annotations system is very elegant, too bad there's no equivalent to this in ksoap).
I looked into the KVMSerializable interface, but when I try to override the getPropertyInfo() method, I have no idea of what I should return in the PropertyInfo.type and how will ksoap handle ArrayLists.
I got a huge headache right now, please help me
Please go to the below URL and read it.
http://www.c-sharpcorner.com/UploadFile/88b6e5/how-to-call-web-service-in-android-using-soap/
Thanks
Ashok Parmar
Traction Software Co.
You should read the document from ksoap 2, they have many useful examples in there.
For getting an array of complex type, you can check here
And I have used this approach to parse a complex object.
If all of them not work, you have to map field by field from soap object to your pojo.
Updated:
Thanks a lot for the 3rd link, it's very useful and I'm now able to
map custom objects. However, in the wiki page you provided, the author
is parsing an array of custom classes, wrapped in a parent element. Is
there a way to do this with inline lists like in my example ?
I have never tried it before, but I think you can combine my answer and the wiki.
First, you can try an example from wiki to implement your passengers list (extends Vector). Then you can use my approach to create a complex object with arraylist inside. The important thing is you must register your object with the response from web service. Something like this:
public class PassengerVector extends Vector<Passenger> implements KvmSerializable {
}
envelope.addMapping(NAMESPACE, "Car", Car.class);
envelope.addMapping(NAMESPACE, "Passenger", PassengerVector.class);
But I'm not sure this way can work. For a very complex object like your example, I recommend you should get data field by field by its name, as like the wiki
Here is an example.
foreach (var doc in documents)
{
var processor = this.factory.Create();
processor.Process(doc);
}
The factory internally calls kernel.Get<IDocumentProcessor>().
I'd like all the document processor's dependencies' lifetimes to be "scoped" to this composition root. This configuration seems to do what I want:
kernel.Bind<IEntityContext>().To<EntityContext>().InCallScope();
Now each object graph rooted at the document processor has a unique, shared entity context for accessing the database. But this
affects all entity contexts everywhere in the application (which may be ok, but seems hard to discover), and
only seems to work for bindings known about statically.
I think my question is, how can I achieve the same scoping / lifetime management effect with "contextual" or dynamic information? Perhaps I want to have the document instance itself injected into all children of the new root:
var processor = this.factory.Create(doc)
processor.Process()
Thanks!
With Ninject 3.0.0 you can do
kerne.Get<IProcessor>(new ConstructorArgument("doc", doc, true));
But to me there still seems to be a design flaw to have doc as a dependency of the processor. It would be better to create the processor once and reuse it for multiple documents by passing the document to the Process method. I still do not get what's the issue with this due to the fact that the question does not show the actual problem.
I have an application using the Entity Framework code first. My setup is that I have a core service which all other services inherit from. The core service contains the following code:
public static DatabaseContext db = new DatabaseContext();
public CoreService()
{
db.Database.Initialize(force: false);
}
Then, another class will inherit from CoreService and when it needs to query the database will just run some code such as:
db.Products.Where(blah => blah.IsEnabled);
However, I seem to be getting conflicting stories as to which is best.
Some people advise NOT to do what I'm doing.
Other people say that you should define the context for each class (rather than use a base class to instantiate it)
Others say that for EVERY database call, I should wrap it in a using block. I've never seen this in any of the examples from Microsoft.
Can anyone clarify?
I'm currently at a point where refactoring is possible and quite quick, so I'd like some general advice if possible.
You should wrap one context per web request. Hold it open for as long as you need it, then get rid of it when you are finished. That's what the using is for.
Do NOT wrap up your context in a Singleton. That is not a good idea.
If you are working with clients like WinForms then I think you would wrap the context around each form but that's not my area.
Also, make sure you know when you are going to be actually executing against your datasource so you don't end up enumerating multiple times when you might only need to do so once to work with the results.
Lastly, you have seen this practice from MS as lots of the ADO stuff supports being wrapped in a using but hardly anyone realises this.
I suggest to use design principle "prefer composition over inheritance".
You can have the reference of the database context in your base class.
Implement a singleton for getting the DataContext and assign the datacontext to this reference.
The conflicts you get are not related to sharing the context between classes but are caused by the static declaration of your context. If you make the context an instance field of your service class, so that every service instance gets its own context, there should be no issues.
The using pattern you mention is not required but instead you should make sure that context.Dispose() is called at the service disposal.