Forum OpenACS Improvement Proposals (TIPs): Re: TIP #34 (Proposed): Application package ui separation

Collapse
13: Re: TIP #34 (Proposed): Application package ui separation (response to 1)
Posted by Caroline Meeks on 12/10/03 03:19 AM
Approve.

This is clearly a good idea and a direction we want to go. I also agree with Don that portlets should move in the same direction.

Once the coding is done we will definitely want to evaluate the results before we take it into to the official release.

To my thinking that now, at the concept stage and  then secondly when it is done, are the two points that OCT should be officially involved.

We should discuss, brainstorm and debate implementation choices and ideas as a community, but  we don't need to get an official OCT vote on each choice. The first time for anything is always an iterative experiment. Hopefully this will be based on BCMS and thus a second time, but that is no where close to Pind's Rule of Five.

I suggest we approve the basic idea continue this discussion outside the TIP process.

Collapse
14: Re: TIP #34 (Proposed): Application package ui separation (response to 13)
Posted by Lee Denison on 12/10/03 11:41 AM

Here is my attempt to clarify my intention:

Firstly, my original suggestion was that for each instantiation of an application there would be two instantiated packages; a functionality package and a ui package. This approach had the ad_conn problems. However Dave pointed out that there are no ad_conn problems if the funtionality package is a singleton - which is also the approach taken in bcms. So everything after Dave's post is with the singleton functionality package in mind, ad_conn is no longer an issue and there is no need for a mapping between functionality packages and ui packages.

The work I'm proposing can be thought of in two main stages:

  1. Factor existing ui pages into useful, reusable include files that live in the lib directory and maybe move the odd bit of code into a function. This isn't terribly contraversial and there is no implied change in thinking about how the package works.
  2. Split the package in two; a singleton functionality package (sql, lib and tcl dirs) and multiple instances of ui packages (www dir). This requires work to deal with issues like url generation, apm callbacks and package parameters as well as recognition that code in the functionality package must satisfy all ui packages.

In my post above I also considered a couple of 'nice to have's before creating a whole bunch of includes. Obviously I would like these modifications to be part of OACS rather than specific to my project but they are neither required nor central to this tip:

  • A modification to the way templates files are resolved to make it easier to use includes placed in the lib directory - for my project I have modified ad_return_template and the <include> and <master> tags to call a new function which resolves relative files the same way as the previous call to template::url_to_file. For absolute paths it checks the lib directory of the current package before checking from the server root. It also accepts paths of the form '<package-key>://path/to/template' which check the specified packages lib directory before resorting to the server root.
  • Secondly creation of an ad_include_contract. For my project I've broken ad_page_contract into functions which are now also used by ad_include_contract. ad_include_contract examines variables passed to the include rather than form variables. It basically works but current doesn't handle arrays passed to the include by reference. Also the filters currently registered for ad_page_contract need to be divided into those appropriate for page contracts, those appropriate for include contracts and those common to both.