When asp.net hits JSF the difference between the input methods

Asp.net|js in most applications, users must be allowed to enter data into the system, so validation requirements exist in almost all applications. In this article, the two sample applications display a list of available rooms and allow the user to display any reservation information related to the room. For each room there is a corresponding link-direct display to the user an online form-you can immediately make a new reservation. The following shows a screenshot of the booking form for both applications.


Asp. NET Booking Form

JSF Booking Form

In these forms, the user first enters the name of the person or group to be subscribed to. The user then enters the start and end times for a new subscription. As a developer, you have to consider all the possible behaviors of a user-it may not be consistent with what the application expects. Asp. NET and JSF provide the appropriate components to help implement input validation. Asp. NET validation controls are attached to the related form item and are validated when the form is submitted. Asp. NET validation controls include RequiredFieldValidator, RegularExpressionValidator, RangeValidator, and CompareValidator. To properly validate a component, developers need to write custom code or use a CustomValidator component. In the life cycle of a asp.net page, the CustomValidator is used for validation before the data is sent back to the server. This is because the ASP.net validation controls generate the necessary JavaScript to implement checksums at the client, thereby reducing server burden. However, ASP. NET always performs this checksum on the server side and ensures that checksums are always performed.

JSF also provides some standard validation components, although not as rich as asp.net offers. To write your own validation logic, you can also overload a JSF component's validate method or a validation proxy to another class that implements the validator interface (you can also write your own validation component, but this is a more complex solution). JSF lacks the built-in JavaScript functionality provided by the ASP.net checksum component. After the component tree is restored, a checksum occurs immediately on a JSF page on the server side, but this must occur before any event handlers are invoked. Of course, you can always provide your own custom JavaScript checksum. With these basics, let's analyze how the subscription data for each user in these applications is properly calibrated.

These forms are fairly simple, but there are still validation issues to consider. For the initial subscriber, it is not significant to allow a user to book a room and not enter a name to specify who is in the reservation. Therefore, you should require a "reservation Team" field. In ASP.net, this is done by dragging a RequiredFieldValidator control from the control Panel onto the form. The ControlToValidate property should read "Lblreserveteam". On the Properties panel, you can specify the error text that the user should receive. I added the following error message: "Must enter a reservation team". The corresponding JSF text domain component that describes the subscription team does not require a separate checksum component because the component already contains a "required" attribute. Simply checking this property enables you to force the user to enter a value.

Next, you can limit the length of the text in the Reservation team field. You may recall that the corresponding database field is only 45 characters in length. Therefore, the user should be restricted to enter less than or equal to 45 characters. In a JSF application, a lengthvalidator component may be dragged from the validators part of the palette to the field and specify 45 as its maximum length. As for its error text attributes, you can enter "reservation team cannot exceed characters". Asp. NET does not have a standard validation control to limit the length of the domain. Instead, you can rely on the RegularExpressionValidator control-it allows you to specify the maximum length through a regular expression such as "^[ss]{,45}$".

Start and end times should be checked to ensure that the start time is less than or equal to the end time. Asp. NET provides a comparevalidator-that is suitable for comparing two domains in most cases. However, since the calendar component is used here, you do not have to implement this feature-because CompareValidator does not support this component. In this particular example, I have to assign these dates to two text fields and validate them. Another option is to write the validation logic in the Page_Load event procedure itself. Because JSF does not have a standard checksum component to compare these two domains, I have to write validation logic-by implementing the Validate method of the start time component:

public void Calendarstart_validate (Facescontext FC, UIComponent UIC, Object o) {
if (This.calendarStart.getSelectedDate () after (This.calendarEnd.getSelectedDate ()) {
throw new Validatorexception (new Facesmessage
("The start time must come before"));
}
}
You will notice that a facesmessage component is referenced in the JSF checksum logic above. In JSF, a message component is required to display the output text associated with a domain. To do this, I added a message component from the palette and attached it to the correct form field-by dragging it onto the field. Once this operation is incomplete, the error message for the corresponding error component is displayed when the checksum fails. In asp.net, you do not have to perform this step because the controls themselves can display error messages.

Another set of important JSF components is called a "converter." These components are responsible for implementing back and forth transitions between the form data and the object model. There are some default converters in JSF that can be used to implement ordinary transformations (such as converting a string to an integer, converting a string to date, and so on). For more complex transformations that invoke application objects, you can create custom converters. As you can see in the above code, this JSF calendar component has a method getselecteddate. This is because the component already includes its own converter. Although this JSF application does not require the use of converters, you should be familiar with the use of JSF converters because they help to reduce code writing and run-time conversion errors. By contrast, ASP. NET does not provide a standard set of converters.

In addition, you should add a different checksum to these forms. The checksum queries the database to make sure there are no subscriptions that conflict with the user's selection time. To implement the possible complexity here, you should use a CustomValidator control in the ASP.net program. Similarly, in JSF, this logic will be placed in the Validate method of the component or in another class that is being delegated to process validation.


adding ASP.net validation controls

Add JSF Checksum component