I have a problem in using checkbox in ProcessMaker 4. In version 3 I had this code:
$("#amount").setOnchange(function(newValue, oldValue) {
$('#myCheckbox').show();
var amount2 = $("#amount2").getValue();
if(newValue >= amount2){
$("#myCheckbox").setValue("1");
}
else{
$("#myCheckbox").setValue("0");
}
});
how can I implement this in version 4?
You should be using watchers.
Create a watcher that monitors the amount variable for changes. Whatever code you put in the watcher will execute each time the variable changes. There you can add the code to set the value of the checkbox variable to whatever you need.
When configuring the watcher remenber to define the input variables wich is basically a json maping whatever variables will be available to the watcher script to your current variables in the screen...
Example:
{"Variable_in_script":"{{Variable_in_screen}}"}
Related
On my process, I have a variable that is an array of objects similar to the following:
"llista-finques" : [
{
"FIN_ID": "H10",
"FIN_NOMBRE": "PLUTO VIVIENDAS",
"FIN_PROPIETARIO": "H10",
"FIN_LINIA_NEGOCIO": "Horizontal"
},
{
"FIN_ID": "H11",
"FIN_NOMBRE": "PLUTO PARKING",
"FIN_PROPIETARIO": "H11",
"FIN_LINIA_NEGOCIO": "Horizontal"
},
{
"FIN_ID": "H12",
"FIN_NOMBRE": "PINTO VIVENDES",
"FIN_PROPIETARIO": "H12",
"FIN_LINIA_NEGOCIO": "Horizontal"
},
{
"FIN_ID": "H16",
"FIN_NOMBRE": "ZURUBANDO",
"FIN_PROPIETARIO": "H16",
"FIN_LINIA_NEGOCIO": "Horizontal"
} ......
I am trying to create a Calculated Propery in one of my forms that needs to create a subset of this array filtering by object property. In order to do so, I was hoping to use the following javascript for the calculated field:
return this.llista-finques.filter(finca => {return finca.FIN_PROPIETARIO === this.Id_client});
For some reason this code produces no result, and after many tests, I have arrived at the conclussion that the variable "this.llista-finques" is simply not accessible from the script, although it is available in the process data.
If I change the Calculated Property script to simply return the value of the variable as bellow:
return this.llista-finques;
or even someting that simply should return a string:
return this.llista-finques[0].FIN_ID
the calculated property produces no result.
If I do exaclty the same with any of the other process variables that are not arrays of objects the calculated property seems to work correctly.
Al the testing I have done is using the screen preview debuging tools of Processmaker 4.
Is there a limitation on the kind of variables I can use for calculated properties? Is this a processmaker bug?
This is embarassing ... after testing and testing and testing I figured out that the problem was due to the name of the variable I was using. Can't use a name with the character '-' ....
Once I corrected the variable name it all worked as expected.
I want to load a JSONStore based on a provided param to the adapter mapped load function.
Let me explain it better.
The JSONStore initialization is like this:
collections[EMPLOYEE_COLLECTION_NAME] = {
searchFields : {ENAME: 'string', EMPNO:'integer'},
//-- Start optional adapter metadata
adapter : {
name: 'EmployeesDB',
add: 'addEmployee',
remove: 'deleteEmployee',
replace: 'updateEmployee',
load: {
procedure: 'getEmployee',
params: [region],
key: 'resultSet'
}
}
//-- End optional adapter metadata
};
//Initialize the people collection
WL.JSONStore.init(collections, options)
As you can see in the code above, even after the param region was passed to the adapter collection init, is it supposed to change during my app life cycle, so there are moments where region let's say is SOUTH, others is NORTH and so on.
I realized that even though I change this value after the store was created, the mapped load function in the adapter getEmployee (see below) always get value that region contained at the time the jsonstore was initialized regardless I change the region variable value later on. Looks like the adapter binds conf is getting at collection creation time, and never changes it
function getEmployee(data) {
WL.Logger.info('Show param:'+data);
return WL.Server.invokeSQLStatement({
preparedStatement : selectStatement,
parameters : []
});
}
Is there a way to pass parameter to the Jsonstore load function that can change after the store was initialized ?
I wanted to avoid close and init the collection again to save time and resources.
By the way, what I really need is to have flexibility on what I load from the database based on a adapter parameter that is bound to a collection.
Try something like:
WL.JSONStore.get(EMPLOYEE_COLLECTION_NAME).adapter.load.params = ['...']
Before calling WL.JSONStore.get(EMPLOYEE_COLLECTION_NAME).load().
If you want more flexibility, you can always call WL.Client.invokeProcedure and inside the onSuccess callback you can call: WL.JSONStore.get(EMPLOYEE_COLLECTION_NAME).add(['...'], {push: false}). The push: false section will make sure JSONStore understands that the data added is up-to-date with the data on the backend. This means it won't show those documents when you call: WL.JSONStore.get(EMPLOYEE_COLLECTION_NAME).getPushRequired() or WL.JSONStore.get(EMPLOYEE_COLLECTION_NAME).push().
when reading SmartGWT DateTimeItem: accept 12 hour format I found that using TimeDisplayFormat offers the options to display the seconds as, e.g. dateTimeItem.setTimeFormatter(TimeDisplayFormat.TOPADDED24HOURTIME); well, but there was no change in the displaying of the date.
As the code states that TimeDisplayFormat is deprecated, and one should use the DateDisplayFormatter instead, I tried dateTimeItem.setDateFormatter(DateDisplayFormat.TOSERIALIZEABLEDATE);, but still no change.
The value gets set via dateTimeItem.setValue(myDate);
Any idea what (else) I have to set to the DateTimeItem in order to get the seconds displayed as well?
I'm using SmartGWT 3.1
PS: I tried dateTimeItem.setDisplayFormat(DateDisplayFormat.TOSERIALIZEABLEDATE); as well, but still no change
It seems DateDisplayFormat.TOSERIALIZEABLEDATE is having some issue in SmartGWT 3.x.
dateTimeItem.setDateFormatter(DateDisplayFormat.TOSERIALIZEABLEDATE); works correctly in SmartGWT 4.0.
dateTimeItem.setDisplayFormat(DateDisplayFormat.TOSERIALIZEABLEDATE); did not provide required behavior even in 4.0, probably due to a default system wide format setting.
You should be able to use a value formatter as a workaround in 3.0.
dateTimeItem.setEditorValueFormatter(new FormItemValueFormatter() {
public String formatValue(Object value, Record record, DynamicForm form, FormItem item) {
if (value != null && value instanceof Date) {
return DateTimeFormat.getFormat("yyyy-MM-dd HH:mm:ss").format((Date) value);
}
return null;
}
});
Check DateItem.setEditorValueFormatter as you might have to set input format, etc. as well.
hi use the following code in your dateitem timeSheetDate.setShowPickerTimeItem(true); timeSheetDate.setTimeFormatter(TimeDisplayFormat.TOSHORTTIME); and also you can use timeSheetDate.setTimeFormatter(TimeDisplayFormat.TOTIME);
I'm using the Laravel Lang class for localization of my web app. I've added two languages to the languages array in application/config/application.php. This changes the default language it uses for localization to whatever the first part of the URI indicates (e.g. bla.com/en/bla and bla.com/co/bla). Now I need to be able to check what the current default language is in my view. However, the Lang class provides no way of checking this as far as I've been able to figure out, as the Lang::$language variable is protected. Is there any way of checking this apart from manually parsing the URI?
The cleanest way to know the current language of your website in Laravel appears to be :
Lang::locale();
https://laravel.com/api/5.8/Illuminate/Translation/Translator.html#method_locale
It's different than this command that will return the default language of your website :
Config::get('app.locale');
An alternative, a bit shorter way could be using something like this:
app()->getLocale()
The advantage of this is that IDEs such as PHPStorm recognize this function and can help you develop much faster.
BenjaminRH's answer is very good, and his suggested approach works perfectly. I've improved the snippet a bit. Now it detects the browser language and checks if that language is supported according to the application's config file.
It's a quick hack, but it works on my app. Note that the application language is also set now. Feel free to use ore improve it.
Route::filter('before', function()
{
// current uri language ($lang_uri)
$lang_uri = URI::segment(1);
// Set default session language if none is set
if(!Session::has('language'))
{
// use lang in uri, if provided
if(in_array($lang_uri, Config::get('application.languages')))
{
$lang = $lang_uri;
}
// detect browser language
elseif(isset(Request::server('http_accept_language')))
{
$headerlang = substr(Request::server('http_accept_language'), 0, 2);
if(in_array($headerlang, Config::get('application.languages')))
{
// browser lang is supported, use it
$lang = $headerlang;
}
// use default application lang
else
{
$lang = Config::get('application.language');
}
}
// no lang in uri nor in browser. use default
else
{
// use default application lang
$lang = Config::get('application.language');
}
// set application language for that user
Session::put('language', $lang);
Config::set('application.language', $lang);
}
// session is available
else
{
// set application to session lang
Config::set('application.language', Session::get('language'));
}
// prefix is missing? add it
if(!in_array($lang_uri, Config::get('application.languages')))
{
return Redirect::to(URI::current());
}
// a valid prefix is there, but not the correct lang? change app lang
elseif(in_array($lang_uri, Config::get('application.languages')) AND $lang_uri != Config::get('application.language'))
{
Session::put('language', $lang_uri);
Config::set('application.language', $lang_uri);
}
});
In the newer Laravel versions, you can get the current language with:
Config::get('app.locale');
This would work fine
lang="{{ app()->getLocale() }}"
I've figured out a solution to the language problem (thanks to nickstr on the IRC and the accepted answer to this question). It involves storing the current language as a session variable, which is updated when the language uri segment is changed.
Route::filter('before', function()
{
// Do stuff before every request to your application...
// Default language ($lang) & current uri language ($lang_uri)
$lang = 'he';
$lang_uri = URI::segment(1);
// Set default session language if none is set
if(!Session::has('language'))
{
Session::put('language', $lang);
}
// Route language path if needed
if($lang_uri !== 'en' && $lang_uri !== 'he')
{
Return Redirect::to($lang.'/'.URI::current());
}
// Set session language to uri
elseif($lang_uri !== Session::get('language'))
{
Session::put('language', $lang_uri);
}
});
This might help.
Config::get('application.language')
You can use
https://github.com/mcamara/laravel-localization
Laravel Localization uses the URL given for the request. In order to achieve this purpose, a group should be added into the routes.php file. It will filter all pages that must be localized.
// app/routes.php
Route::group(array('prefix' => LaravelLocalization::setLanguage()), function()
{
/** ADD ALL LOCALIZED ROUTES INSIDE THIS GROUP **/
Route::get('/', function()
{
return View::make('hello');
});
Route::get('test',function(){
return View::make('test');
});
});
/** OTHER PAGES THAT SHOULD NOT BE LOCALIZED **/
Once this group is added to the routes file, an user can access to all languages added into the 'languagesAllowed' ('en' and 'es' for default, look at the config section to change that option). For example, an user can now access to two different languages, using the following addresses:
http://laravel.com/en
http://laravel.com/es
http://laravel.com
I use App::getLocale() which is probably the most supported way as the App::setLocale('EN') method is used in the documentation.
You can use this method everywhere. If it throughs an error somewhere, you can use \App::... to make it work.
I'm using Laravel 5.0.
Your can get current language in laravel blade by:
{{Lang::locale()}}
The Lang class is specifically for outputting the correct language and as you say manages the language internally.
Looking through the API there is no method to help you directly with this and parsing the URI to get the language would seem the appropriate course of action.
You can always just do this to retrieve the language string in the URI:
$language = URI::segment(1);
Examining Laravel Requests
I'm writing an application that pulls changesets from TFS and exports a csv file that describes the latest changes for use in a script to push those changes into ClearCase. The "latest" doesn't necessarily mean the latest, however. If a file was added and then edited, I only need to know that the file was added, and get the latest version so that my script knows how to properly handle it. Most of this is fairly straight-forward. I'm getting hung up on files that have been renamed or moved, as I do not want to show that item as being deleted, and another item added. To uphold the integrity of ClearCase, I need to have in the CSV file that the item is moved or renamed, along with the old location and the new location.
So, the issue I'm having is tracing a renamed (or moved) file back to the previous name or location so that I can correlate it to the new location/name. Where in the API can I get this information?
Here is your answer:
http://social.msdn.microsoft.com/Forums/en/tfsgeneral/thread/f9c7e7b4-b05f-4d3e-b8ea-cfbd316ef737
Using QueryHistory you can find out that an item was renamed, then using its previous changeset (previous to the one that says it was renamed) you can find its previous name.
You will need to use VersionControlServer.QueryHistory in a manner similar to the following method. Pay particular attention to SlotMode which must be false in order for renames to be followed.
private static void PrintNames(VersionControlServer vcs, Change change)
{
//The key here is to be sure Slot Mode is enabled.
IEnumerable<Changeset> queryHistory =
vcs.QueryHistory(
new QueryHistoryParameters(change.Item.ServerItem, RecursionType.None)
{
IncludeChanges = true,
SlotMode = false,
VersionEnd = new ChangesetVersionSpec(change.Item.ChangesetId)
});
string name = string.Empty;
var changes = queryHistory.SelectMany(changeset => changeset.Changes);
foreach (var chng in changes)
{
if (name != chng.Item.ServerItem)
{
name = chng.Item.ServerItem;
Console.WriteLine(name);
}
}
}
EDIT: Moved the other solution up. What follows worked when I was testing against a pure Rename change but broke when I tired against a Rename and Edit change.
This is probably the most efficient way to get the previous name. While it works (TFS2013 API against as TFS2012 install), it look like a bug to me.
private static string GetPreviousServerItem(VersionControlServer vcs, Item item)
{
Change[] changes = vcs.GetChangesForChangeset(
item.ChangesetId,
includeDownloadInfo: false,
pageSize: int.MaxValue,
lastItem: new ItemSpec(item.ServerItem, RecursionType.None));
string previousServerItem = changes.Single().Item.ServerItem;
//Yep, this passes
Trace.Assert(item.ServerItem != previousServerItem);
return previousServerItem;
}
it would be used like:
if (change.ChangeType.HasFlag(ChangeType.Rename))
{
string oldServerPath = GetPreviousServerItem(vcs, change.Item);
// ...
}