Forum OpenACS Development: Liferay integration

To achieve the goal of Liferay integration and probably mashups in OpenACS, I am leaning towards writing a page "/acs-subsite/www/include", which will allow me the following:

Call yourserver.com/include/package_key/include_name?variables

This will result in OpenACS evaluating the include_name of the package_key (e.g. /packages/project-manager/tasks) and return the contents, just if I would call <include src="/packages/project-manager/tasks" variable1=@variable1@ ...>

The reason to put it into site-map is that it will allow me to do the following:

/subsite1/include/project-manager/tasks and pass the package_ids of all instances of project manager to the tasks include.

Alternatively I could call:

/subsite1/include/project-manager/tasks?include_subprojects_p?1 which would include all project-manager instances in the subprojects as well

Additionally I could think about a second page which does the following:

/subsite1/include_url/pm/tasks and pass the package_id of the package instance mounted at /subsite1/pm/

The method with the package_id would probably work with .LRN as well, if we only change the includes to not set the list_of_package_ids automatically to the config from .LRN, but allow them to be passed in as a variable instead.

Are there any objections to this approach? Am I not general enough? Would this make sense in the first place to others in the first place or should I keep it private?

The value is that you can call a URL and get the content of an include e.g. in /lib without having to write a page to display it separately, enabling you to easily include content from OpenACS in other websites.

P.S.: Yes, I do know that there exists a problem if you want to do true includes without the user having to log in. But that is a separate problem that needs to be tackled. For my use case at the moment we just assume the cookie from the login exists.

Would it, as a first step, be okay to check if the user has read permission on the package? I am pretty sure that all includes are called after a permission check on the package and if they need to limit this further, the include itself uses the user_id (this is the fact in forums, projects and file-storage as far as I looked).

But I see your point for sure and there seems no easy solution for it. I would probably add a parameter in the .info file of the package to declare if it is safe to included all includes in /lib. But this should be a discussion on a larger scope on how to include and exchange content from and to OpenACS in the first place.

Exporting data via a search syndication is probably a good thing in most szenarios (do we have something written up on that topic?), but for our use case we have two constraints:

a) Data exchange has to happen via webservices (I suggested using the Basecamp API for data exchange with the Project Manager, which was flat out denied).

b) We use a different Java based system for portlet display.

In an ideal world, I would just write Liferay portlets that query data using XML as you describe or the webservices and display the content. But... I have no intention to rewrite all the includes in project-manager, contacts, forums, file-storage, invoices and some selected ones in acs-subsite into liferay.

In the long run we are going to use the CAS server for authentication, so we can be sure the user is logged in (and auth::require_permission works). But that is a different topic.

Almost :) Right now it stores RSS 1.0 (i think) XML in the syndiation table. Eventually you'd want to store the raw data and have a template or tdom script to convert to whatever XML format you prefer.

Overall what you want is to take the Tcl datasource and use it with a different output format, instead of HTML. Of course there are plenty of ways to do this :) You can just use XHTML, and use semantic markup and CSS to organize the data. You can use RSS/ATOM, etc, you could use XHTML with embedded microformats (basically the same thing as the first option, but sort of standardized). This of course depends on what the other end of your web service is expecting.

An interesting option would be to document the datasource with the -properties switch of ad_page_contract, and have a way to request XML. Then you could just output the properties frm the ad_page_contract in a defined XML format from the Tcl variable values. That seems like a pretty good way to go, but would require a change in ad_return_template. If you look at ACS 4 its pretty clear that there was an intention to make it work this way in the first place, but I guess noone knew _why_ you'd want to do that back then.

Again, I just don't think automatically exposing include templates, which are put in lib so they aren't available at a URL by themselves, is the best plan. You could even write some sort of index.vuh that took the URL, figured out which include to work with, then handle the output.