Creating a view with the style YQL Query: Flexible works slightly different from ordinary views. The differences are described below.
  1. You create a view with "YQL Query: Flexible" as the type. (You didn't guess this one, right?)
  2. The option Query settings is available (under Advanced settings. The following settings can be adjusted:
    1. Alternate API URL: This allows using another engine than the default YQL engine, assuming that it understand the YQL language. This field is usually blank.
    2. API method: For now only JSON method is supported. XML support is on the roadmap.
    3. YQL base table: This is the name of base table to query from. You can find the name at the YQL Console. It usually has the form anwers.search or twitter.followers.
    4. Number of items: This sets the number of items that will be retrieved from the external table. Only the retrieved items are available for internal post-processing in Views, including splitting results with a pager. Note that all rows are fetched on each call to the table -- setting this to 1000 will cause a slow response even if you only show the first 10.
    5. Custom open tables: This setting is used if the table source is not Yahoo! (or whatever alternate API URL you may be using). In the YQL Console this is indicated by the src attribute in the table description. Any custom open table should be specified in the following format: USE (table_url) AS (table_alias); (Note the trailing semicolon.)
    6. YQL base object: The base object YQL will be querying from. If this is left empty, the first object in the result set will be taken as the base object
  3. There is a new and required setting when configuring fields: Field name. This is the name of the result field that should be outputted in the view. Consider it an equivalent of field_cck_name, but since all the data is kept externally the name must be entered manually. One way of browsing the available fields is YQL Console, find your table in the lower right-hand box Data tables and click on it to browse the results of a sample query. (Note that some tables requires API keys to display any results at all.)
  4. Managing filters works in analogue to adding fields. If the query should contain a part where id='twittername', you enter 'id' as field name and 'twittername' as value. You may use operators and exposed filters as usual.
  5. Managing arguments works very similar to filters. (As of September 18th 2010 argument handling is available in dev version.) The field name must be specified. The options for actions to take if no argument is present are not yet implemented. (Feel free to join efforts to improve the module!)
  6. The sort criteria work similar to filters and arguments -- the field name on which to sort must be specified.