GUI and Web Frameworks

Struts framework is based on MVC2 architecture (Model 2), where a single controller servlet handles requests and dispatches to views. MVC2 improves on MVC1 by separating controller logic from views.

In MVC architecture, the controller acts as the intermediary between the view (presentation layer) and model (business logic/data). It processes user input, interacts with the model, and selects the appropriate view for rendering. The controller is the glue that coordinates view and model interactions.

Struts 1.3 follows the MVC (Model-View-Controller) architecture pattern. The Model represents business logic and data, the View handles presentation (JSP pages), and the Controller manages application flow (ActionServlet). All three components are essential parts of the Struts framework.

In Struts MVC architecture, the View layer consists of presentation components. HTML provides the structure and JSP (JavaServer Pages) enables dynamic content generation. DAO and VO classes belong to the Model layer (data access and transfer objects), while Action classes are part of the Controller layer.

In HP/Micro Focus UFT, the Action toolbar provides options to view the details of a single action or navigate through the entire test flow. Other panels like the Test Pane show the hierarchy, but the Action toolbar specifically controls these view actions.

The Sync method in QTP waits for the browser to complete the current navigation before proceeding with test execution. Wait is a generic delay, WaitProperty waits for a specific property value, and Exist checks if an object is present - none specifically handle browser navigation.

In Symfony's MVC architecture, the Model layer handles data access and business logic. Database Abstraction (via Propel or Doctrine ORM) is part of the Model layer. Layout belongs to View, Action belongs to Controller, and 'None of above' is incorrect.

In Symfony 1.x, action methods must return a value (typically a view name or response). An empty executeshow method with no return statement will cause an error because Symfony expects the action to return something. Option C is wrong because there's no return to render the template.

Symfony 1.x uses camelCase for action templates. The executeShow action maps to showSuccess.php (lowercase first letter, then camelCase).

In Symfony 1.x, $sf_params is a core template variable automatically available without explicit definition. $request, $response, and $sf_context require action setup.

This is a valid JSF navigation rule declaration. It correctly defines a from-view-id of /main.jsp, contains two properly structured navigation-case elements with from-action, from-outcome, and to-view-id, and follows the required XML nesting structure for faces-config.xml.

The convertDateTime converter's dateStyle property accepts four predefined values: short, medium, long, and full. These correspond to java.text.DateFormat style constants and determine the verbosity of the date display format. All four options shown are valid.

The updateActionListener is designed for command components like h:commandButton and h:commandLink. SelectBooleanCheckbox is an input component for boolean selection, not an action trigger - it doesn't support action listeners. Use valueChangeListeners or converters instead.

The globalOnly property on h:messages filters messages to display only global messages (those not associated with a specific component via for attribute). When set to true, component-specific messages are hidden and only application-wide messages appear.