I have observed that some validators (Alnum, Alpha, Float, Int and PostCode) are localized into "Zend\I18n\Validator" package instead of "Zend\Validator" how the zend documentation explains.
Somebody knows because it's so.
Can I use these validators without problems?
Yes you can use them without problems. You may have to change your "use" statement or you can refer to them using their full namespace. In my current project I'm using the AnnotationBuilder to validate forms that contain floats using the #Annotation\Validator() syntax. It works quite well.
The only issue I came across was I needed to install/enable the php-intl extension on my server.
Related
I would like to use Confirm Prompt but currently Confirm Prompt supports only few languages such as en-us, fr-fr etc. I would like to use Confirm Prompt for 2 different languages which are not supported by default. I know I can use fields as confirmChoices and choiceOptions to manually specify confirm choices but that would mean that I have to create 1 ConfirmPrompt for every language which is not included in Confirm Prompt by default.
The easiest way to add support for more languages, which are not included by default, would be to add them to defaultChoiceOptions map. But this map is declared as private static, hence it can not be modified.
So I am thinking about extending ConfirmPrompt class and overriding onPrompt and onRecognize method which will be exactly same as in ConfirmPrompt class but it will use myCustomDefaultChoiceOptions which will be non static and public field in my custom class => problem solved.
But this is hackish solution and I can not understand why this map is not public and non static in Bot Framework SDK.
Hence I am asking, is there any other solution (natively supported by framework) which allows me to add support for different languages in ConfirmPrompt?
This was actually a change pushed out a couple of months ago (by me). You'll need to update your packages.
choiceDefaults is private (and non-static, now), however, it can be updated by passing it into the constructor.
The easiest/best way to do this would be to build your PromptCultureModel for each language/locale/culture (so you can also use it easily with ChoicePrompt), then create the object with those PromptCultureModels that matches ChoiceDefaultsConfirmPrompt, and then pass that into the constructor.
You can see how I did this in it's test here.
Note: When you overwrite choiceDefaults, you lose all of the currently-supported languages. You can easily add them to your PromptCultureModel object via PromptCultureModels.getSupportedCultures().
Note: I've got a to-do to add some additional languages, but it's on the backlog since you can now add your own.
I am implementing a Wagtail powered blog within a larger (primarily DRF) driven app. I'm attempting to use drf-yasg for my documentation.
Since installing wagtail, the docs are now throwing
'Request' object has no attribute 'wagtailapi_router'
It looks to be related to the introspection that drf-yasg does, and all I can find about excluding views from drf-yasg is done at the code level. Being an installed module obviously I want to avoid that.
Has anyone got these 2 (3) components playing nicely together?
It's been a very long time since you asked this question, but as I found this while looking for an answer myself, I thought I might share what worked for me.
Note that I'm not using drf-yasg, but rather DRF's own schema generator. They do however have a lot in common.
The problem in my case was that the schema generator URL was defined like this:
path(
"schema/",
get_schema_view(title="My API Schema"),
name="openapi-schema",
),
What I needed to add was a patterns= argument that referenced my API specifically, leaving out the other non-API urls (like Wagtail):
path(
"v3/schema/",
get_schema_view(title="My API Schema", patterns=router.urls),
name="openapi-schema",
),
I hope that helps... someone :-D
Recently I came across someone's code. The Alloy Markup is empty with just <Alloy />. In its controller, it adds a view using $.addTopLevelView().
How come I can't find any documentation regarding this function?
Good point. It might be because it's considered private, although it would normally start with _ to indicate that since JS doesn't actually support private methods.
It is also against the very idea of Alloy to not use the XML file for the markup but instead use "classic" Titanium code in the controller together with this method.
However, it might be a good idea to do a PR against the following file to request this to be documented:
https://github.com/appcelerator/alloy/edit/master/Alloy/lib/alloy/controllers/BaseController.js
I've seen Missing inverse property in asp.net webapi odata $metadata and the WebAPI $metadata I'm dealing with behaves as described in this article: it doesn't reuse associations for bi-directional navigation properties.
When using jaysvcutil 1.3.5 all navigational properties come up as $$unbound.
$data.Entity.extend('API.Models.Document', {
...
'Document_Versions': {
'type':'Array',
'elementType':'API.Models.Document_Versions',
'inverseProperty':'$$unbound' }
});
Other than manually updating the inverseProperty information is there anything to get the desired result automatically?
Update based on #Robesz answer
Manually adding inverseProperty information to the static .js converted by JaySvcUtil is doable, but I'm asking if there's an option to accomplish that with the dynamic conversion as well.
There seems to be to options
make modifications to the .NET WebAPI. Might be challenging, because their seem to be good reason for their implementation, but maybe somebody already successfully did that.
modifying the conversion XSLT that JayData using to take that behavior into account.
We've just arrived to the same results with WebAPI OData, but after editing the generated context file manually and adding the inverseProperty everything is working fine
This should be most probably handled by extending JayData's XSLT conversion. I've created an issues for that on https://github.com/jaydata/jaydata/issues/155.
I have a CakePHP ticketing app where I am using Revision Behavior to keep revision history of each tickets. The problem I have using this behavior is, it does not display validation error messages. Here is the line I have added in the model.
public $actsAs = array('Revision' => array('limit'=>10));
When I comment this line, it displays error messages and otherwise it does not. Also, when I debug it using x-debug, I see validationErrors variable is set and has all error message values set properly.
Please shed some light here.
Edit: I am using Cake 2.1
First, be sure to get the last version of this behavior : http://alkemann.googlecode.com/svn/trunk/models/behaviors/revision.php
for integration in CAKE 2.X, the problem comes from line 980 in the createShadowModel() function:
$Model->ShadowModel->alias = $Model->alias;
The behavior gives the same alias to the base model and its shadowmodel it will save in the _revs table and that seems to mess up the validation messages.
The problem is that this behavior is loaded automatically when you access your model, and the createShadowModel() function is called even if your input doesn't validate.
One of the solution would be to comment out this line from createShadowModel() and then to add it only to every function in the behavior that will make an operation in the DB . There is surely a better way than that, like detecting in the setup() if there is need to go further to initialization, but couldn't find how to do it. So that's my first step towards at least allowing to use this behavior in Cake 2.X.
There are a few things that could be happening here. Too much for one to simply tell you what is happening since we don't have any of your code. However, I am pretty certain that this behavior, being that it was written in 2008, will have issues with CakePHP version 2.1, which just released its first alpha. There have been a lot of changes to the infrastructure of Cake that could cause this not to work. I'd say this would probably work with version 1.3 and definitely with 1.2, but getting support for 2.1 probably won't happen without updates.
That said, this is a behavior, which should only alter model code. So, there should be not impact (theoretically) on your view. Are you sure you are using the proper conventions in your code to display errors (even though commenting it out changes displayed messages).
I'd look for a 2.0+ compatible version of the behavior. Or, you could throw the code on Github and start to port it yourself. You may get some help from some Cake people.