How to set the immediate Association of the words returned from the request in ace editor? - ace-editor

How to set the immediate Association of the words returned from the request in ace editor?I want to associate the words back from the request immediately, but I tried all kinds of methods.

Related

Oracle APEX Array

In my apex app, I have an array I want to store as an application item. When I try to do this like (APP_ITEM_ARRAY is an "application item"):
declare
TYPE array_t IS TABLE OF VARCHAR2(255);
lv_arr array_t;
begin
:APP_ITEM_ARRAY := lv_arr;
end;
I get an error (expression is wrong type). So for now I'm testing using an apex_collection, which seems usable on my pages. But I'm a little unsure, are these part of the users session?
How best to store (pl/sql) arrays in session state for Apex to use across pages?
In my use case, the array is actually a list of groups the logged in user is in...so I also need an easy way to determine whether the user is in a group, or not, ala some kind of "exists" or "member of" and then on my pages I'll use that...show hide Buttons, Nav Items, etc.
In apex, a page item is always a string under the hood, so it's not possible to a value of a complex datatype to it (and it explains the error too). It's possible to use collections too but that would be overkill for this kind of functionality.
To store multiple values in a single page item (for example for items of type checkbox - where you can select multiple values - or like in your case), a colon-delimited string is used. There is a pl/sql API APEX_STRING that has functions and procedures to convert an object of type apex_t_varchar2 (which is basically an array) to a string and back.
Example:
DECLARE
l_groups apex_t_varchar2;
BEGIN
l_groups := apex_t_varchar2('user','administrator','manager');
:P1_PAGE_ITEM := apex_string.join(l_string1);
END;
/
Side remark: what I just explained answers your question, but why would you store that information a page item ? Just leave it in the database and when you need to know if a user is in a group, just use a database function. Or better, use an authorization scheme to determine what functionality is available to a user based on the group he is in - that is what those are made for.

Best Way to call WebAPI endpoint for child entity from Mobile and Web

There are two tables Item and ItemExtras both have similar table structure in database.
We have two price fields in UI, One is Price and ExtrasPrice.
Item Price and other fields will be saved in Item table.
And ExtrasPrice field needs to insert new entry in ItemExtras table if it is there.
What is the best way to create and request end points (CRUD)?
Create two separate end points for Item and ItemExtras
Create two separate end points for both but handles ItemExtras CRUD(By calling endpoints) from Item end points.
Create endpoints which handles both tables CRUD.
Normally it depends on the domain logic and requirements. Since there are none and you're asking for the best way, here's my opinion about this:
Since the ItemExtras is a child entity of Item, you can never create or update an ItemExtras without having an Item first. What would be the meaning of an ItemExtras record in your database if there's no parent Item record for it?
I would go for a single endpoint, to create the entire Item object, including the ItemExtras. Something like this:
POST /api/items
You can create two endpoints to give the clients of your API the flexibility, but making two API calls is probably something you want to avoid. What if the API call for creating an ItemExtras succeeds, but the API call for creating an Item fails? Then you have "incorrect" data in your database, as mentioned before (there's no use of having an ItemExtras without having an Item).
Calling another endpoint from your own API (your option two) feels weird to me. Why have multiple endpoints if they're going to call each other anyway?
Should you ever need to update an ItemExtras, without updating any details about the Item itself, you can create an endpoint like this:
PUT /api/items/{itemId}/ItemExtras/{itemExtrasId}
This also forces the clients of your API to have an Item record, before they can update an ItemExtras record.
Hope this makes sense.

How to fetch the variable value in service now when ordering item from service catalog?

I have successfully ordered an item from service catalog using REST API. While ordering I sent a JSON data in the request body containing certain key value pairs which are meant to be stored in variable of the catalog item. After the successful order, the response generated contains the sys_id, request_number, request_id, table name. Now, when I want to fetch the values passed to variables, the only way available is to make a GET call using the REST API for Tables. So, I am fetching the record using the generated sys_id and table name which is generated as response of order API. The table name is sc_request.
But that is not providing the variable value information in the response body of the GET call.
You should be able to get the values of variables using the Table API. If you go to the REST API explorer in ServiceNow, notice the field "sysparm_fields". put the name of your variabe(s) in there like this "variables.var_name". This will retrieve their values and display values in the response.

How do I prevent a parse.com user from seeing parts of their user data? aka set ACL per field on User class?

I add new users.
Let's presume we add a field of 'additionaldata1' on the parse user class
I do NOT want the user to be able to see the data stored in 'additionaldata1' and as such don't want it returned when I query the current parse users.
Seeing as the code is a web.app I don't want it to be possible for a user to 'hack' the local code in order to bring back 'all' their user object data.
So my question is how do I ensure that certain fields such as 'additionaldata1' are NEVER returned on the parse.com user object? Do I have to set up an additional class that is related to the user but set the ACL as non-read? Or can I set ACL per field on the user class?
EDIT//
UPDATE: I believe I worked this out myself. It doesn't appear to be possible to set ACL per field on a class. As such I have to add this data into an additional class with a RELATION and then set the ACL on that class table to 'no read' and 'no write'. That way only cloud code can see the class values due to the master key and I can run any validation and queries via cloud code where I need that data to be secure / private from the user.
This case is mentioned in Parse Docs under one-to-one relational data https://www.parse.com/docs/relations_guide#onetoone_anchor.
They recommend that you split up the data into two tables and use a one-to-one:
In Parse, a one-to-one relationship is great for situations where you need to split one object into two objects. These situations should be rare, but two examples include:
Limiting visibility of some user data. In this scenario, you would split the object in two, where one portion of the object contains data that is visible to other users, while the related object contains data that is private to the original user (and protected via ACLs).
Splitting up an object for size. In this scenario, your original object is greater than the 128K maximum size permitted for an object, so you decide to create a secondary object to house extra data. It is usually better to design your data model to avoid objects this large, rather than splitting them up. If you can't avoid doing so, you can also consider storing large data in a Parse File.

Is it possible to use arguments with firebird events : POST_EVENT 'event_name' + string args?

I've a trigger that detects a change on a field PHONE_EXT and POSTs an EVENT. I would like to post the Phone_ID with the event in order to use this ID in the client. Is this possible? How?
CREATE TRIGGER tr2 FOR employee
ACTIVE AFTER UPDATE POSITION 0
AS
BEGIN
IF (new.PHONE_EXT <> old.PHONE_EXT) THEN
POST_EVENT 'phone_ext_changed'; <-- I would like to pass a string parameter with record ID
END
AFAIK, you cannot pass parameters, but you can get what you want with one of this ideas:
If in your client you're interested in events over specific records, you can append the ID of the changing record and post that event. The clients register the events in which are interested using the specific ID's of interest. See example 1.
if your front-end are interested in all changes but you want to know which particular records changed, you can "flag" the records as "recently changed" (using another field on the same record, or a detail table, for example). Upon client notification and action it reverts or clears the flag. This approach may be powered, for example, using auxiliary tables to track missing records from specific clients, it depends on your needs.
Example 1
begin
if (new.phone_ext <> old.phone_ext) then
post_event 'phone_ext_changed_'||new.ID;
end
Example 2
begin
if (new.phone_ext <> old.phone_ext) then
begin
new.recent_ext_change = 1;
/* or maybe */
new.last_ext_change = cast('now' as DateTime);
/* or maybe */
insert into changed_phone_ext values (gen_id(some_generator, 1), New.ID, 'now');
/* finally, post the event */
post_event 'phone_ext_changed_';
end
end
I'm using both with success in different applications/situations.
You can use it as follows:
Set a context variable in the trigger and place the desired information in it.
Ex.:
Create trigger evento_ai0 for evento
active after insert position 0
AS
BEGIN
Post_Event 'Evento_inserido';
"Creating the context variavble"
rdb$set_context('USER_SESSION', 'REGISTRO' , 'Registro inserido: '||new.eve_id);
END
To capture the saved information use:
Select rdb$get_context('USER_SESSION', 'REGISTRO') from rdb$database;
This is not possible. The event is a name only, if you add ids or other qualifiers, it simply becomes a different event because it has a different name. When subscribing to events, you can only subscribe by name, you can't use wildcards, and it is not possible to include parameters.
Events are for simple and cheap notification, and Firebird can even coalesce multiple 'posts' of the same event into a single notification to a client, so parameters or values are not supported.
The basic idea is that a client subscribe to events, and then determines what changed and what it needs to react to. You can 'help' the client by - for example - populating a support table that is cheap to query.
Also consider reading the article "The Power of Firebird Events", it is a bit old, but a lot of it still applies as Firebird events haven't changed much.

Resources