|
Xomega allows you to easily generate a WPF, Silverlight or ASP.NET search form based on a single operation defined in the model, which accepts a structure of the search criteria as an input and returns a list of structures as an output. In addition, Xomega provides a way to support advanced criteria, where one can use criteria values in conjunction with flexible operators, which provides the users with a very powerful search tool. You can also read this article on how the powerful search forms are supported by the Xomega Framework. In order to generate a powerful search form in Xomega, you can use the following steps. - Define a service operation in the Xomega model with search criteria as an input and a list of row structures as the output. You can build it from scratch or, if the structures it returns are largely based on the fields of a specific object, you can take the read list operation after generating the Model CRUD Operations for the object and customize it as necessary by adding or removing parameters.
- For each criteria parameter that allows multiple values to search by, set the list attribute true.
- If you want to allow specifying an operator for a certain criteria parameter, then add another parameter with the type set to operator, and the name set to the name of the original criteria parameter followed by the string " operator", e.g. "my criteria operator".
- If the type of the criteria parameter allows searching in a specific range, e.g. a date or a number, and therefore requires an additional field, then add another parameter with the same type, and the name set to the name of the original criteria parameter followed by 2, e.g. "my criteria2".
- Specify a Xomega UI data object for the input structure, e.g. MyFormCriteria.
- Specify a Xomega UI data object for the output structure, e.g. MyFormRowObject.
- Generate the Xomega UI the objects.
- Open properties of the proper search form generator located in the WPF, Silverlight or ASP.NET subfolders of the Presentation Layer generator folder.
- Set the Output Path parameter to where you want the generated forms files to be output. Use the {File} placeholder to to make the file name based on the corresponding operation name. You can also use the {Module/} placeholder to place the files in different folders based on the modules of the corresponding objects, for example ../MyProject.Client.WPF/Gen/_{File}.xaml.
- Set the Form Namespace parameter to the namespace that should be used by the form.
- You can also set the Form Name parameter to make the generated form use a specific name rather than generating it based on the operation full name.
- In order to generate only a search form based on a specific operation, you can set the List Row Object parameter to the name of your data object for the output structure, e.g. MyFormRowObject.
- Right click on the model file that contains your search operation and select the Generate > WPF/Silverlight/ASP.NET Search Form from the context menu to run the generator. This will generate a search form for each search operation defined in the file, unless you specified the List Row Object for your operation as in the previous step.
- Add the generated forms to your UI project. For the ASP.NET forms right click on the form and select the Convert to Web Application from the context menu to generate the designer code files for the form.
- Review the generated form. If the model needs to be updated to fix any issues with the form, then make the necessary changes in the model and regenerate the form following the steps described above.
- To start manually customizing the form, you want to rename the file and potentially move it to the right place first, so that your changes wouldn't be lost the next time the search form generator will be run.
The sample below demonstrates a read list operation on an error log object that is used to generate a search form for the errors. The error time and error time2 input parameters can be used to pass the date range when the value of the error time operator is set to BETWEEN. You can pass a list of error severities to filter by. You also don't have to specify the operator parameter for the criteria that don't need an operator, e.g. an error line, which defaults to the EQUALS operator. Code:
<operation name="read list">
<input>
<param name="error time operator" type="operator"/>
<param name="error time" required="false"/>
<param name="error time2" type="date time" required="false"/>
<param name="user name operator" type="operator"/>
<param name="user name" required="false"/>
<param name="error number operator" type="operator"/>
<param name="error number" required="false"/>
<param name="error number2" type="integer" required="false"/>
<param name="error severity" required="false" list="true"/>
<param name="error procedure operator" type="operator"/>
<param name="error procedure" required="false"/>
<param name="error line" required="false"/>
<config>
<xfk:data-object class="ErrorLogCriteria"/>
</config>
</input>
<output list="true">
<param name="error log id"/>
<param name="error time"/>
<param name="user name"/>
<param name="error number"/>
<param name="error severity"/>
<param name="error state"/>
<param name="error procedure"/>
<param name="error line"/>
<param name="error message"/>
<config>
<xfk:data-object class="ErrorLogRowObject"/>
</config>
</output>
</operation>
|