Displays a form that is edited/inserted into the database.
Displays an existing record in the the form and updates the record in the database.
The NewEdit component presents a number of input fields for inserting, updating or duplicating a record in the database (see "Component mode"). There are different kinds of input fields ("Controls") for different kinds of data, such as text boxes, drop-down lists and so on. For a list of the available controls and their functionality, refer to "Controls" in the Softadmin® documentation. Here we will focus on how the controls can be presented and grouped within a NewEdit menu item.
You can split the input fields in columns. In the above example there are three columns.
If the browser window is too narrow, the input fields will not rearrange. Instead you will get a horizontal scrollbar.
The default buttons are "Save" and "Cancel", but you can change their wording, or specify a completely different set of buttons.
To prevent losing data, the NewEdit component will raise a warning if you try to leave the page without saving changes. It does not appear if you have not made any change to any of the input fields. The warning also appears if you close the browser window.
Every control can display one or more buttons to their right. In this example, the dropdown list with available customers is accompanied by a "New customer" button.
It opens a menu item to create a new customer, displayed in a popup window.
In this example, the user created a new customer named Carl Carlsson. When the new customer is saved, it is automatically added to the customer dropdown in the "Edit car" menu item. Notice that the user did not have to reenter all the other data, like Model, Year model, Price etc, since the New customer menu item took place in a popup window.
These are the controls available in the NewEdit component:
Retrieves the record to edit in the form.
Possible value | Description |
---|---|
column | The component expects n resultsets to follow and allocates the fields in the same resultset to a separate column. |
row | The component expects one resultset to follow where the n first fields are allocated to row one, the next n fields to row 2, etc... Fields on the same row will be aligned (middle) with each other. |
Possible value | Description |
---|---|
Center | Center aligned. |
Left | Left aligned. |
Right | Right aligned. |
Possible value | Description |
---|---|
boolean checkbox | Legacy alias. Use "checkbox" instead. |
boolean dropdown | |
chart | |
checkbox | |
Checkbox tree | |
colorpicker | |
date | |
datetime | |
dropdown | |
file | |
heading | |
heading with checkbox | |
hidden | |
html | |
info text | |
listbox | |
multi-listbox | |
multi-picker | |
multirow | |
password | |
picture | |
radio buttons | |
textarea | |
textbox | |
textbox with autosearch | |
textbox with autosuggest | |
textbox with dropdown | |
textbox with popup | |
time | |
uneditable text |
Possible value | Description |
---|---|
Default | Inherit layout from menu item. |
LabelAbove | Full width, label above. |
LabelLeft | Label to the left. |
NoLabel | Full width, no label. |
Standard | Deprecated. Use LabelLeft instead. |
Possible value | Description |
---|---|
Hyperlink | |
MailToLink | |
PhoneLink |
Allows you to validate the parameters supplied by the user before any other SQL is run in the component. This call is only made if the component has visible parameters, the SQL is a stored procedure, and 'Validate parameters' is checked.
Updates the record in the database.
NOTE: Fields that both have validation and are hidden (e.g. with Visibility JavaScript) are passed as NULL to the procedure.
May use SoftadminApi.Progress_SetTitle and SoftadminApi.Progress_SetStep.
SQL that can have several resultsets that are displayed at top of component.
Possible value | Description |
---|---|
Center | Center aligned. |
Left | Left aligned. |
Right | Right aligned. |
Possible value | Description |
---|---|
boolean checkbox | Legacy alias. Use "checkbox" instead. |
boolean dropdown | |
chart | |
checkbox | |
Checkbox tree | |
colorpicker | |
date | |
datetime | |
dropdown | |
file | |
heading | |
heading with checkbox | |
hidden | |
html | |
info text | |
listbox | |
multi-listbox | |
multi-picker | |
multirow | |
password | |
picture | |
radio buttons | |
textarea | |
textbox | |
textbox with autosearch | |
textbox with autosuggest | |
textbox with dropdown | |
textbox with popup | |
time | |
uneditable text |
Possible value | Description |
---|---|
Default | Inherit layout from menu item. |
LabelAbove | Full width, label above. |
LabelLeft | Label to the left. |
NoLabel | Full width, no label. |
Standard | Deprecated. Use LabelLeft instead. |
Possible value | Description |
---|---|
Hyperlink | |
MailToLink | |
PhoneLink |
Possible value | Description |
---|---|
Current | This is the current step. |
Done | This step has been completed successfully. |
Failed | Something went wrong in this step. |
Future | This step is later on in the process. |
Use this call to restrict which entries a user is allowed to view and edit, and to log which entries a user views.
Access to a menu item is normally controlled through functions and roles alone but some entities need more fine grained control. For example, a user may have access to the View Member menu item for normal members but not for members with a protected identity.
The menu items a user visits are always logged (in ADMINLogMenuItem) but for sensitive data you may need to log exactly what entries are viewed. Do the logging in this call as the common ways of viewing data (grid and InfoSQL) are not allowed to modify the database.
If you bind a scalar function instead of a stored procedure to this call then its name must end with '_GrantAccess'.
Avoid using nested transactions (since only the outermost matters regarding ROLLBACK or COMMIT). The following code only starts transactions when necessary, ie if one has not already been started. Make sure to look at the @IsUsingLocalTransaction parameter before any COMMITs or ROLLBACKs.
-----------------------
-- Begin transaction --
-----------------------
DECLARE
@IsUsingLocalTransaction bit
IF @@TRANCOUNT = 0
BEGIN
SET XACT_ABORT ON
BEGIN TRANSACTION
SELECT
@IsUsingLocalTransaction = 1
END
--------------------------
-- INSERT/UPDATE/DELETE --
--------------------------
<DML statements>
------------------------
-- Commit transaction --
------------------------
IF @IsUsingLocalTransaction = 1
BEGIN
COMMIT TRANSACTION
END
Example of how dynamic field info can be used to change the properties of fields in a NewEdit.
ALTER PROCEDURE Example.NewEdit_DynamicFieldInfoGetEditFields
AS
BEGIN
-----------------------
-- Fields to NewEdit --
-----------------------
SELECT
-- In this example, this field keeps its original field info
CONVERT(varchar(1000), NULL) AS [ExampleFieldChangedByDynamicFieldInfo1],
-- And these fields will have their field changed by dynamic field info
CONVERT(varchar(1000), NULL) AS [ExampleFieldChangedByDynamicFieldInfo2],
CONVERT(varchar(1000), NULL) AS [ExampleFieldChangedByDynamicFieldInfo3],
CONVERT(varchar(1000), NULL) AS [ExampleFieldChangedByDynamicFieldInfo4]
------------------------
-- Dynamic field info --
------------------------
/*
You don't have to SELECT all dynamic field info in one result set,
the presence of the column [ADMINFieldName] in the result sets tells
Softadmin® that the result set specifies dynamic field info.
The basic structure is to specify the field to change in a column [ADMINFieldName],
the other columns are the properties to be changed. NULL values are
interpreted as keeping the static field info.
*/
SELECT
-- Field to change
'ExampleFieldChangedByDynamicFieldInfo2' AS [ADMINFieldName],
-- Properties to change
'Look how I''ve changed the label but not the description' AS [FieldLabel],
NULL AS [Description] -- NULL value, original description will be used
SELECT
-- Field to change
'ExampleFieldChangedByDynamicFieldInfo3' AS [ADMINFieldName],
-- Properties to change
'Look how I''ve changed the description, width and height' AS [Description],
400 AS [Width],
225 AS [Height]
SELECT
-- Field to change
'ExampleFieldChangedByDynamicFieldInfo4' AS [ADMINFieldName],
-- Properties to change
'Look how I''ve changed the label, type and default value' AS [FieldLabel],
'Uneditable text' AS [FieldType],
'* Try and change me if you can *' AS [DefaultValue]
END
This code demonstrates how to use the process functions to maintain a progress bar during processing.
CREATE TABLE #ToPostProcess
(
ThingyId int not null
);
/* Choose things to post-process here */
INSERT #ToPostProcess (ThingyId)
SELECT n
FROM SoftadminUtil.Number_Range(1,5);
EXEC SoftadminApi.Progress_SetTitle
@TitleText = 'Post processing thingies';
DECLARE
@CompletedSteps int = 0,
@TotalSteps int = (SELECT COUNT(*) FROM #ToPostProcess);
DECLARE ThingyCursor CURSOR LOCAL FOR
SELECT
ThingyId
FROM
#ToPostProcess;
OPEN ThingyCursor;
WHILE 1=1
BEGIN
EXEC SoftadminApi.Progress_SetStep
@CompletedSteps = @CompletedSteps,
@TotalSteps = @TotalSteps;
DECLARE @ThingyId int;
FETCH ThingyCursor INTO @ThingyId;
IF @@FETCH_STATUS <> 0
BREAK;
/* Post-process Thingy with id @ThingyId here */
-- EXEC Example.Thingy_PostProcess @ThingyId = @ThingyId;
SET @CompletedSteps += 1;
END
CLOSE ThingyCursor;
DEALLOCATE ThingyCursor;
DROP TABLE #ToPostProcess;
The edit fields stored procedure should be named "<Schema>.<Table>_GetEditFields". The insert/update procedureshould be named "<Schema>.<Table>_InsertUpdate" (or just "Insert" or "Update" if the procedure doesn't handle both actions).