Freemarker: How to check for ?api-able type (v 2.3.26) - hashmap

In Freemarker, I have a Map<Map<...>> in the model.
Due to FM glitch, querying for 2nd level Map needs ?api. However, that escapes the normal value existence checks and complicates things.
This is what I have:
<#if sortedStatsMap[rowTag.name]?? && sortedStatsMap[rowTag.name]?is_hash>
${mapToJson(sortedStatsMap[rowTag.name]?api.get(boxTag.name))!}
</#if>
This ends up with:
APINotSupportedTemplateException: The value doesn't support ?api. See requirements in the FreeMarker Manual.
(FTL type: sequence+extended_hash+string (wrapper: f.c.DefaultToExpression$EmptyStringAndSequence),
TemplateModel class: f.c.DefaultToExpression$EmptyStringAndSequence,
ObjectWapper: freemarker.template.DefaultObjectWrapper#1074040321(2.3.26, useAdaptersForContainers=true, forceLegacyNonListCollections=true, iterableSupport=trueexposureLevel=1, exposeFields=false, treatDefaultMethodsAsBeanMembers=true, sharedClassIntrospCache=#1896185155, ...))
The blamed expression:
==> sortedStatsMap[rowTag.name]! [in template "reports/templates/techReport-boxes.ftl" at line 152, column 84]
If I try
sortedStatsMap[rowTag.name]!?is_hash
then this also fails because if missing, it gives me empty_string_and_sequence and ?is_hash can't be applied, reportedly. (Says that in an error.)
What's the proper logic to check whether I can use ?api.get(key)? Or the right way to use ! to handle missing values or a missing key?

You can check if a value supports ?api with ?has_api. Though maybe you don't need that; the example and the problems related to it should be clarified (see my comments).

Related

make menhir find all alternatives?

I would like to change the behavior of menhir's output in follwoing way:
I want it to look up all grammatical alternatives if it finds any, and put them in a list and get me back this ambigouus interpretation. It shall not reduce conflicts, just store them.
In the source code of menhir, it seems to me, that I have to look in "Engine.ml". The resultant syntactically determined token comes in a variant type item "Accepted v" as a state of a checkpoint of the grammatical automaton. This content is found by a function "accept env prod" before, that is part of a bundle of recursive functions, that change the states.
Do you have a tip, how I could change these functions to put all the possible results in the list here and proceed as if nothing happened? Or do you think, that this wont work anyway?
Thanks.
What you are looking for is a GLR parser generator (G is for generalized). Menhir is not such tool, and I doubt you could modify it easily to do what you want.
However, there is another tool that does exactly what you want: dypgen.

prolog recursive searching with contraints

I have a house with rooms that are defined with connections for when you can go from one room to another eg.
connection(garage,sidehall).
connection(sidehall,kitchen).
connection(kitchen,diningroom).
canget(X,Y):-connection(X,Y).
canget(X,Y):-connection(X,_),
write('player goes from '),write(X),write(' to '),write(Y),nl,
canget(_,Y).
Im trying to figure out how make it so the player can only get from one room to another when they have a specific item, such as you can only be in the kitchen when items = gloves.
canget(X,Y,Item):-connection(X,Y,Item),canbein(Y,Item).
canget(X,Y,Item):-connection(X,Somewhere,Item),canbein(Somewhere,Item),canget(Somewhere,Y,Item).
tried defining canbein with:
canbein(kitchen):- item(sword).
canbein(sidehall):- item(hat).
but that doesnt work!
Have defined my items as such, not sure if this is right either:
item(gloves,sword,helm,cheese).
Basically, have i declared my item values correctly?
How can i use the specific item value to make canget x to y false?
Thank you!
Well, I see a few problems with your code. Firstly, you call canbein with two arguments (from canget predicate). However, canbein is defined as single-argument predicate. Therefore, the call always fails as no canbein/2 predicate exists.
I suggest the following modification:
canbein(kitchen, sword).
canbein(sidehall, hat).
Than, the item definition is not required. Let's think about what happens during the unification of
canget(X,Y,Item) :- connection(X,Y,Item), canbein(Y,Item).
Let's assume the following setting X=sidehall, Y=kitchen, Item==sword. This predicate should be OK. Assuming the conection predicate is OK, prolog tries to find canbein(Y, Item) i.e. canbein(kitchen, sword) and it succeeds.
On the contrary, if the Item is different the unification fails, hence it works as expected.
The second problem is the item predicate. By your definition, it expects 4 arguments. That's nonsense, of course. You should declare it like
item(gloves).
item(sword).
item(helm).
item(cheese).
However, I don't think this predicate is necessary at all. Just to be clear, try to call item(X) and obtain all results (the four declared). Try it with the prior definition - what should you even ask for?
I hope it helps :)

How to use SWRL rules on Protegé 4.3 using Pellet

I've just started doing work on ontologies with Protegé and I'm trying to understand how to use SWRL rules. I'm afraid I don't get the concept or how to correctly treat them, as I'm not able to produce any output. I'll explain a bit more a simple case I created to test this:
I've created three individuals, called A, B and C. Each one with a test property, that has a boolean range. On the property assertions tab of each one I've initialized their values, so they are test(A,true), test(B,true) and test(C,true). To test how rules work, I created a rule like this: test(A,true), test(B,true) -> test(C,false). The way I understand it is that, if A and B's test property is true, C's one would turn false. To do so, I start the reasoner (Pellet) but nothing happens. I mean, it says the reasoner is active and no "inconsistent ontology" messages appear, but C's test value doesn't change. I'm sure this must be a really simple confusion but I can't seem to find it anywhere nor check if the rule has been activated.
Thank you in advance.
The inference doesnt work like that, you cannot retract test(C, true) if you've asserted it. Your ontology probably includes both test(C, true) and test(C, false) which is completely legal unless you've specified otherwise; in which case then you'd see the inconsistency.

Case sensitivity inconsistency in SharePoint + oData?

I am using jQuery to get information from SharePoint 2010's listData.svc. I noticed some inconsistencies with regards to case sensitivity in my queries:
The following command is case sensitive:
...&$filter=substringof('String', property) eq True
The following command is case insensitive
...&$filter=substringof(tolower('String'), tolower(property)) eq True
The following command is also case insensitive but much shorter:
...&$filter=substringof('String', property) or substringof('String', property2)
However, the case insensitivity using the short method is lost for the entire filter when one part is using a property more than two levels down. So in the following command the entire filter becomes case sensitive again:
...&$filter=substringof('String', property/property/property) or substringof('String', property2)
Is this an issue with SharePoint's service? Or am I just doing something wrong?
It seems like a bug in ListData.svc.
If comparisons (delegated to SQL server at the end of the day) are case-sensitive in any query they should always be case-sensitive.
Clearly the tolower call makes things match whether cases match or not, so we can ignore that.
However I have no idea why doing an OR on another property works.
Either it is a bug in SharePoint or perhaps you've inadvertantly picked an OR clause that returns the data your were expecting by accident.

automapper - simplest option to only write to destination property if the source property is different?

NOTE: The scenario is using 2 entity framework models to sync data between 2 databases, but I'd imagine this is applicable to other scenarios. One could try tackling this on the EF side as well (like in this SO question) but I wanted to see if AutoMapper could handle it out-of-the-box
I'm trying to figure out if AutoMapper can (easily :) compare the source and dest values (when using it to sync to an existing object) and do the copy only if the values are different (based on Equals by default, potentially passing in a Func, like if I decided to do String.Equals with StringComparison.OrdinalIgnoreCase for some particular pair of values). At least for my scenario, I'm fine if it's restricted to just the TSource == TDest case (I'll be syncing over int's, string's, etc, so I don't think I'll need any type converters involved)
Looking through the samples and tests, the closest thing seems to be conditional mapping (src\UnitTests\ConditionalMapping.cs), and I would use the Condition overload that takes the Func (since the other overload isn't sufficient, as we need the dest information too). That certainly looks on the surface like it would work fine (I haven't actually used it yet), but I would end up with specifying this for every member (although I'm guessing I could define a small number of actions/methods and at least reuse them instead of having N different lambdas).
Is this the simplest available route (outside of changing AutoMapper) for getting a 'only copy if source and dest values are different' or is there another way I'm not seeing? If it is the simplest route, has this already been done before elsewhere? It certainly feels like I'm likely reinventing a wheel here. :)
Chuck Norris (formerly known as Omu? :) already answered this, but via comments, so just answering and accepting to repeat what he said.
#James Manning you would have to inherit ConventionInjection, override
the Match method and write there return c.SourceProp.Name =
c.TargetProp.Name && c.SourceProp.Value != c.TargetProp.Value and
after use it target.InjectFrom(source);
In my particular case, since I had a couple of other needs for it anyway, I just customized the EF4 code generation to include the check for whether the new value is the same as the current value (for scalars) which takes care of the issue with doing a 'conditional' copy - now I can use Automapper or ValueInject or whatever as-is. :)
For anyone interested in the change, when you get the default *.tt file, the simplest way to make this change (at least that I could tell) was to find the 2 lines like:
if (ef.IsKey(primitiveProperty))
and change both to be something like:
if (ef.IsKey(primitiveProperty) || true) // we always want the setter to include checking for the target value already being set

Resources