I was wondering, since an update of Symfony2.1 (I can't target the commit though) why I no longer have the "formatter" attribute on my jQueryDateType
if ($form->getConfig()->hasAttribute('formatter'))
returns false
The whole class is here : https://gist.github.com/d3c74c12d60e20df84c3
the getParent() function was missing and solved half of the problem.
Related
I have code using AutoMapper 3.2.1.0 that uses the method ToNullSafeString().
I upgraded the NUGet package to 4.1.1.0, and I can no longer find the method in their package.Does anyone know the recommended approach to replacing the function? Is there a new construct that is functionally equivalent? If so, I cannot figure what it is. Nor can I find any mention of why it was removed.
This question has actually been answered pretty well in a couple of comments below it. For completeness, here are a couple of actual implementations of solutions.
Short answer
Probably both the simplest and the best solution: Replace all instances of .ToNullSafeString() with ?.ToString(). This does the same, but uses functionality built into newer versions of .Net instead of relying on an external extension method.
Alternative answer
If you've got a bunch of calls to the ToNullSafeString() method from the earlier version Automapper, and for some reason or other you can't or don't want to go through all your code and edit it away right now, you can use this instead.
Add the following class to your project, and make sure it can be reached from any classes that previously called the Automapper-method. Those calls will then automatically point to this instead.
public static class NullSafeStringHelper
{
public static string ToNullSafeString(this object value)
{
return value?.ToString();
}
}
I replaced all of my JNDI lookups with JNDI.lookup() method because it seemed convenient, dealt with dynamic return types, etc. All was great...but now I just noticed that the checked exceptions that I had to catch before are no longer there.
I assumed this was because it would have just returned null if the JNDI variable didn't exist but it doesn't. It now just throws an unchecked exception.
Any idea why? Is there a way of just returning null for non-existant variables instead?
I created a bug for this on the omnifaces website: https://github.com/omnifaces/omnifaces/issues/141
Not sure if this is intended behavior or not.
Is there a way of just returning null for non-existant variables instead?
It does that for NameNotFoundException. The problem was here not in OmniFaces, but in the environment, which was GlassFish 4.1 in your specific case. It unexpectedly wrapped the NameNotFoundException in another NamingException, hereby causing the underlying NameNotFoundException to slip through and bypass the return null condition.
This has been fixed with help of Exceptions#is() utility method as per this comment. It will be available in OmniFaces 2.2.
I tried it with PostgreSql provider. Digging into code I see that:
OrmLiteDialectProviderBase.ToCreateTableStatement() method strangely always passes null as scale parameter to GetColumnDefinition().
PostgreSQLDialectProvider.GetColumnDefinition() ignores all parameters except fieldType
Is this intended to be so? Is there a workaround to make CreateTable consider fields length?
P.S. Is there an active issue tracker for ServiceStack? Link at https://github.com/ServiceStack/ServiceStack/wiki/How-to-contribute is broken.
I have created a simple bean using this example from Per
http://per.lausten.dk/blog/2012/02/creating-your-first-managed-bean-for-xpages.html
And I can access the bean using
helloWorld.setSomeVariable("test") and
get the value using helloWorld.getSomeVariable()
But when I try it using EL language it doesn't work
helloWorld.SomeVariable
I get an error that SomeVariable doesn't exists in helloWorld
I'm probably doing some simple error, but I can't see what.
I believe the problem is that EL is likely case-sensitive the bean-style name of the property is "someVariable". Beans assume that you're using camel-case for the method names, so EL downcases the first letter after "set" and "get" for their translation.
EL seems to be case sensitive in my regards and your property is defined as someVariable and not SomeVariable. have you tried helloWorld.someVariable.
Using core data I'd like to fetch some data. My model uses some abstract entities, see attached picture, where QuantifiedIngredient is an abstract class.
I'd like to fetch Ingredient entities that have at least one RecipeQuantifiedIngredients, but in the middle is QuantifiedIngredient, which is an abstract class.
How can I do that, how can I test the actual type of an abstract class inside a NSPredicate? Any idea or suggestion?
The only clue I found was:
How can you reference child entity name in a predicate for a fetch request of the parent entity?
Would work a custom property in my QuantifiedIngredient to know if it is a RecipeQuantifiedIngredient? For instance isRecipeQuantifiedIngredient?
Thanks a lot for your help.
If recipe is required in RecipeQuantifiedIngredient, you could try to make a fetch, that checks, if there is any ingredient.recipe. I think, that will work.
The custom property, in kind of flag, will work for you too. You'll just need to set and unset it whenever you add or delete all the recipeQuantifiedIngredient.
I don't want to take the time to translate this into CoreData-speak so here is my thought in SQL:
SELECT * FROM quantifiedIngredients WHERE recipe <> NULL
or something like that. This is essentially Nikita's suggestion of using a flag, except that the 'flag' is the existence of a property. I don't know how CoreData will react when faced with GroceryQuantifiedIngredients that don't have the recipe, I think KVO will throw an exception. You might be so bold as to add a category:
#interface GroceryQuantifiedIngredients (KVOHack)
-(id)recipe;
#end
#implementation GroceryQuantifiedIngredients (KVOHack)
-(id) recipe { return nil; }
#end
This would of course require CoreData to enumerate all quantifiedIngredients, but I presume it will have to do so anyway, and a the return nil should optimize into tiny code. The other consideration is whether this will have a bad effect on the rest of your code; you will have to make that call.
Another idea which pops to mind as I finish this up is to do something like this (I'm getting really loose with my pseudo-code now):
SELECT * FROM quantifiedIngredients WHERE [i respondsToSelector:#selector(recipe)];
See what I mean? I forget whether CoreData lets you play with some kind of cursor when working with predicates or fetchedThingamabobbers, if it does than I think this is your best bet. Anyway it's Sunday afternoon so that stuff is left as a exercise for the reader.
+1 for a good question.