I am new to CSLA and i am trying to understand the difference between FieldManager.updatechildren(this) vs FieldManager.updatechildren.
When is it appropriate to use either one?
I figured out the answer to my question. Use FieldManager.UpdateChildren(this) when updating a certain child with certain parameters. All other cases we use FieldManager.UpdateChildren
Related
I started today learning Netlogo based on an existing simulation which uses ask-concurrent. When I looked up the documentation to find what ask-concurrent does, I found the following: NOTE: The following information is included only for backwards compatibility. We don't recommend using the ask-concurrent primitive at all in new models.
However, it doesn't say anything about alternatives to this function. What should I use instead of ask-concurrent?
Use regular ask. If you find that changes the meaning of the code in a way that you consider undesirable, then in order to advise you on what to do about it, we will need to know the details of your code.
http://ccl.northwestern.edu/netlogo/docs/programming.html#ask-concurrent contains several examples of pieces of code that use ask-concurrent and how they can be written using regular ask instead.
I can't figure out, how to set a logic and the according options in Scala^Z3.
Guess its really simple, but I just can't find it.. so I really would appreciate some help there ;)
Regards,
Florian
ps.: Scala 3.2 and Z3 4.0 work really fine together :)
In case you are still looking...
There are two ways to set options:
Pass the parameters when you construct your Z3Config instance, e.g. new Z3Config("MODEL" -> true).
Call .setParamValue on a Z3Config instance, e.g. myConf.setParamValue("MODEL", true).
Now to answer the particular question on how to set the logic, that is unfortunately not supported by Z3's API. You can take a look at Leo's answer to this similar question for C#.
Note that strictly speaking you don't really need that option when using the API, though: all theories can be used and Z3 will magically figure out what to do.
I'm looking for an end to end example using dojo.store with dijit.Tree over REST.
There are many existing examples that use the older dojo api, dojo.data.api, but a dearth of ones using the dojo.store api.
Is the reason that dijit.Tree doesn't fully support dojo.store yet?
If so, do I need to use the dojo.data.ObjectStore wrapper to encapsulate dojo.store for use with dijit.tree?
I saw one example of working around this by extending StoreFileCache:
http://dojo-toolkit.33424.n3.nabble.com/New-object-store-and-dijit-Tree-td2680201.html
Is that the recommended option, or should I
a) stick to dojo.data.api until dijit.Tree supports dojo.store directly, or
b) use the dojo.data.ObjectStore wrapper
Thanks
There is now a tutorial on the DTK website that seems to cover pretty much exactly this topic.
http://staging.dojotoolkit.org/documentation/tutorials/1.6/store_driven_tree/
However, as I know linking to something without giving an answer is considered a poor practice, the general idea is that rather than using a dojo.data.ObjectStore to wrap around it and then potentially shoving it through a ForestStoreModel, you can simply augment your dojo.store-based store to add the methods that the Tree will look for. Here's a simple example from the tutorial:
usGov = new dojo.store.JsonRest({
target:"data/",
mayHaveChildren: function(object){
// see if it has a children property
return "children" in object;
},
getChildren: function(object, onComplete, onError){
// retrieve the full copy of the object
this.get(object.id).then(function(fullObject){
// copy to the original object so it has the children array as well.
object.children = fullObject.children;
// now that full object, we should have an array of children
onComplete(fullObject.children);
}, onError);
},
getRoot: function(onItem, onError){
// get the root object, we will do a get() and callback the result
this.get("root").then(onItem, onError);
},
getLabel: function(object){
// just get the name
return object.name;
}
});
It's worth noting that in this case, we're making some assumptions about what the data looks like. You'd need to know how your children relate and customize the methods below for that purpose, but it's hopefully fairly clear as to how to do that for yourself.
You can also just stick to dojo.data APIs for now, but this approach definitely feels more lightweight. It takes a couple of layers out of the stack and working with customizing a dojo.store-based store is much easier.
Given the two options you outlined, I'd say it's a matter of how well you know the different APIs.
dojo.store is more light-weight, and perhaps easier to understand, but the wrapper adds some overhead. If you think your project will live for a long time, this is probably the best way to go.
dojo.data is a legacy API, which will phased out eventually. If your project is short-lived, and only based on dijit.Tree, this might be your best option for now.
Personally, I'd go with dojo.store and write my own TreeStoreModel to get the best of both worlds. This approach is very similar to Brian's suggestion.
In case you're interested, I've written up a two-series post on how to use dijit.Tree with the ObjectStore wrapper, and implementing a JsonRest backend in PHP.
Is there a way to create macros in c#
ex:
string checkString = "'bob' == 'bobthebuilder'" (this will be dynamic)
if (##checkString)
//.........
else
//.........
Thanks
No, C# doesn't have macros. You could capture your logic in a delegate and apply that delegate in multiple places, potentially... would that help?
If you could describe the problem you're trying to solve rather than the solution you think you'd like, we may be able to help more.
T4 seems to be gaining traction these days for .NET work. It's not quite what you asked for, but it may be extremely beneficial in some cases (or it may just be a hint down the wrong path).
In most cases, esp. with generics, I do not wish for 'templates' or 'macros' in C# (or Scala). In the example above, you could simply use:
bool sameStuff = "'bob' == 'bobthebuilder'";
...
if (sameStuff) {
...
}
More complex cases can generally be dealt with refactoring methods or using anonymous functions.
Additionally, attributes (while a completely different approach) round out the case for many "traditional" uses of templates.
As mentioned, no, but there are a number of other approaches:
Conditional compilation via #if
Templating via T4 or something else (we use a port of Ned Batchelder's (mentioned) Cog
Aspect-Oriented Programming via something like PostSharp
As Jon said, lots of ways; it'd be better to describe exactly what you want to do.
Short answer: No.
Long answer: You can write a wrapper around the C/C++ compiler's preprocessor.
Most of the syntax will be accepted with the notable exception of #region/#endregion. You can just prefix those with #pragma before processing, and remove the #pragma part afterwards.
I use a lot of scala maps, occasionally I want to pass them in as a map to a legacy java api which wants a java.util.Map (and I don't care if it throws away any changes).
An excellent library I have found that does a better job of this:
http://github.com/jorgeortiz85/scala-javautils
(bad name, awesome library). You explicitly invoke .asJava or .asScala depending on what direction you want to go. No surprises.
Scala provides wrappers for Java collections so that they can be used as Scala collections but not the other way around. That being said it probably wouldn't be hard to write your own wrapper and I'm sure it would be useful for the community. This question comes up on a regular basis.
This question and answer discuss this exact problem and the possible solutions. It advises against transparent conversions as they can have very strange side-effects. It advocates using scala-javautils instead. I've been using them in a large project for a few months now and have found them to be very reliable and easy to use.