I'm trying to cache the db calls for Yii2 exists validation, but can't work out where to initiate it.
Because I'm using a multi-model form with a lot of relations, the overhead is getting a little too much.
Any ideas?
You'd better not. Actually, there is an issue on Yii2 official Github project where one of the framework's core developers, Alexander Makarov aka #samdark, explains why caching ExistValidator is a bad idea:
Exist validation isn't the kind of validation to be cached. Each second database may change its state so it should be validated just before it's saved.
This is not supported by Yii, you either have to :
Extend the ExistValidator and implement your caching logic there
Add a custom ActiveQuery class to your model in question and override
the exists() and count() methods
Related
in react router 4.x getComponents as been removed but in the docs I cannot seem to find any means to replace it. We use it quite much in our application as it makes the views quite simple as no cases need to be handled where data is not yet present. In some cases the view is re-used with data from other api calls. Is there any way this can be replaced without putting the initialisation logic into the components?
regards
I have been working on this : https://www.npmjs.com/package/react-router-v4-transition. Which may help you. In the example I give you could do a component that does the job of getComponent instead of Transition. It should be quite stable, and I use it myself in a project that needed that kind of feature.
Application Insights does not support tracking for MySQL dependencies out of the box, so I would like to add it as my project relies heavily on MySQL.EF6.
Per the documentation here: https://azure.microsoft.com/en-us/documentation/articles/app-insights-api-custom-events-metrics/#track-dependency
It is possible to add tracking, however to avoid having to wrap every call I make to my database, I would like to override the MySQL.EF6 Library functions of SaveChanges, SaveChangesAsync, Find, FirstOrDefault, etc.
However I am unsure how to accomplish anymore than the SaveChanges/SaveChangesAsync as they are easily overrideable in my DbContext class.
You can try using EF6 logging - https://msdn.microsoft.com/en-us/data/dn469464.aspx.
Spring Security uses UserDetailsManager to manage users & authorities.
I want use same implementation JdbcUserDetailsManager to manage user page by admin (user CRUD, managing groups, pagination). But unfortunately there is no implementation for paging, manage groups and so on.
So I've got an issues:
User CRUD because of json convertation for REST.
Group CRUD because of json convertation for REST.
User paging because of UserDetailsManager has no correspond implementation.
Group paging - no implementation.
User JSON to POJO (for create\update operations could be used UserDetails has implementations InetOrgPerson, Person, User but... i've got json convertation issue, can not mark classes with #JsonIgnore).
User POJO to JSON (for read operation i can not remove from data any important fields (for example: password)).
All of this issues have few solution ways:
1.1. Create one more user object similar to User, add expected JSON annotations OR in rest controller create builder to build User object from input parameter map (builder is good pattern by i think this is ugly way to manage something if it was implemented once)
1.2. add spring-datajpa repository (duplicates some security part of JdbcUserDetailsManager) OR extend from JdbcUserDetailsManager and add unimplemented part to manage users, groups...
Solution is the same with 1.
If 1. implemeted using spring-data-jpa - no problems, other case it needs to implement correspond factory builders to provide paging in dynamic way.
Solution is the same with 3.
Solved on 1., 2. steps.
Solved on 1., 2. steps.
Which solution way i should follow (implement managers spring-data-jpa based with additional POJOs or expand functionality for JdbcUserDetailsManager) ?
Describing situation, i think i'll implement solution using spring-data-jpa and extra POJO-entities to have all CRUD and JSON manipulating abilities. This way seems better saving implementation time, and code will be more cleaner for support generation.
If i mistook in my choice, let me know please. also please let me know if my issues already solved in spring (sorry i did not find solutions for described issues). Also i believe someone wants other solution architecture - i would discuss or consider clever ideas.
As part of a extensive test-case, I'm building an ajax-based CMS-like application which provides CRUD-functionality on various documenttypes, e.g: articles, tags, etc.
on the server and client-side I'm considering to use JSON-schema ( http://json-schema.org/ ) as a way to do user input validation in a DRY way (i.e: 1 validation-schema, to be used both on the server and client-side, no duplicate-code and all that) . This seems great, because:
JSON-schema is both implemented in JS and Java, so one schema could in theory handle client-side and server-side validation
all CUD-operations requests and responses are JSON (through ajax)
However besides the usual validations on user-input I would like to have some additional checks on the server (e.g: like checking if the name of a Tag a user wants to create already exists)
Ideally, I want these type of checks to be included in my general server-side validation code (which as said would be based on JSON-schema). However, I'm not entirely convinced that this is the right approach, because these additional checks are not based on the provided JSON-data alone, but need additional data to validate (e.g: the names of existing tags in the system to check if a tag-name already exists).
So, would it be a good idea (design / architectual wise) to incorporate additional checks like the one described above in the json-schema based validation-framework on the server-side? Would this be an elegant solution? Or would you keep them seperate altogether? If not, why not and what other alternative approached would you suggest to stay DRY concerning client and server-side validation?
What do you think?
Some additional context/ goals of the text-case below for some background info.
Thanks,
Geert-Jan
Some context / goals:
ajax-based CMS using REST approach
CUD-requests are performed through ajax using a rest approach (i.e: mapping on POST, PUT, DELETE respectively). Requests and responses are all done through JSON.
CMS without forms. Instead use in-place editing (e.g using Aloha-editor: http://www.aloha-editor.org/
staying DRY.
templating: done through Mustache templating on client and server-side. Intial rendering and incremental rendering through ajax are done based on 1 and the same template. I wanted to go for something different than Mustache (bc. of it's lack of expressive power), but it works for this prototype at least. (See previous question for alternatives, on which I'm still looking for an answer: Client-side templating language with java compiler as well (DRY templating) )
DRY input-validation: as described above
Validation flow ( in case of failure):
user creates/updates/deletes item.
a validation-failure on the client would instantly give feedback to the user as what to repair. (The Javascript JSON-schema-validator would ideally return JSON which is formatted to the user)
when client-side validation succeeds, the CUD-operation is performed using ajax.
if server-side validation fails, a status-code 400 (Bad request) is returned, with a Json-object containing the validation-failure(s) which is picked up by jquery's error-callback
$.ajax({
....
error: function(xhr, status, error) {
var validationJSON = JSON.parse(xhr.responseText);
//handle server-side validation failure
},
....
});
JSON-object containing server-side validation failures are presented to the user (analogously to client-side)
It is very possible and one of the most gratifying things to have a single definition of validations in one place (per model) on the server that can then generate appropriate JS for client-side and AJAX-based validations.
Yii framework for PHP has a fantastic architecture for accomplishing this in an elegant way that stores all the validation rules together in the model (divvied up into appropriate "scenarios" as needed). From there, it's a matter of flipping a few switches to make a particular form client-side or AJAX-validateable. I believe Yii's interfaces for this were based on Rails.
Anyway I would highly recommend checking out the following key points from Yii's design; even if you don't know PHP, you can use this for inspiration:
CModel::rules() => The DRY source for model validation rules
CActiveForm => Used to generate form elements based on model attributes
See for example CActiveForm::textField()
CValidator => Base class for validators which provisions for the ability to client-validate
I think it's wise to pursue DRY validation rule declaration and in my experience it is not at all unrealistic to achieve that 100% and still have rich forms—and rich validation rules. (And boy will you love life when you don't have to manage all that client-validate JS...)
Hope this helps.
I have a function in one of my views that formats data coming from the DB before displaying it. Since I use this function in many views, I'd like to make a global function that would be accessible from every view. How would I do that ?
As mentioned in the other answers, creating a helper is probably what you are looking for. See the cookbook entry for more information.
To make your helper available in all your views, add the helper to the $helpers array of your AppController (app/Controller/AppController.php).
Creating a helper (as Headshota and preinheimer explained) is the best idea if the function is complex..
But if your function is simple,
you can open the file app/config/bootstrap.php
write your function in this file and that's it..
the function will be accessible anywhere (models, controllers, views, etc)
hope that helps...
I think you want to create a view helper, here's an example one: Minify Helper
Yes you have to create your owns View Helpers.
You will find the documentation in the Section "View > Helpers" of the cook book : here
But the section "Core Libraries > Helpers" just explains how to use the ready-to-use cakephp Helpers like HtmlHelper or FormHelper: here
Likewise you can note that this is the same logic with firstly controllers and components, and secondly model and behaviours.
Then the cook book presents the core components in core-libraries/toc-components
How to create your own is explained in controllers/components
The core behaviours are presented in core-libraries/toc-behaviors
The how to create your own is in models/behaviours
This system is really efficient and makes cakePHP a handy framework (thank you the great documentation) that implement efficiently the Model-View-Controller design pattern.
If you understand that question correctly, you never ask yourself this kind of issue about cakePHP and by the same time, about the MVC pattern.