Forum OpenACS Development: ETP and acs-subsite content folders

Collapse
Posted by Dave Bauer on
The main subsite gets it's own content folder -100. The ETP package puts content items to be served off the site root into this folder.

If you mount any additional subsites they do not automatically get a content folder. I am not sure if this is a bug or not. If acs-subsite should not create a folder I will have ETP create it when etp is used to manage a subsite root.

So, should acs-subsite create a content folder for each subsite package instance that is mounted?

Collapse
Posted by Jun Yamog on
Hi Dave,

In my opinion hopefully it does not.  Also based from old emails with Luke we should remove the hack of ETP working with acs-subsite since this can now be done by host node map.  I believe Luke only put that support so ETP can have a url in the root "/".  Or if OpenACS ever do support that the root site node is not an acs-subsite, we can mount ETP on the root.

This will also remove the parameters on acs-subsite that does belongs to ETP.

Collapse
Posted by Don Baccus on
I say not also ...

Jun ... we're never going to support / not being an acs-subsite, because in 4.7 my goal is to finish aD's subsite work that was a partial step in the direction of removing the "registered users" and similar kludges.  Main site members (equivalent to registered users) will replace registered users and user management for subsites will work in 4.7.  At least that's my goal.  Making user management regular will help my efforts to speed up permissions checking, too ...

Collapse
Posted by Dave Bauer on
ok.

This should probably be addressed some way. I suspect that site owners would like a convenient way to manage content at every level in the site hierarchy.

It seems very helpful to use ETP to manage content associated with an acs-subsite related content folder.

Maybe there is a better way to do this. Should ETP then create a content folder and assign the acs-subsite package_id to it? Or perhaps there is another way. I could not see how CMS addressed this, but i suspect they had thought of something. I'll take another look.

Collapse
Posted by Jun Yamog on
Hi Dave,

Yup what you suggested can work.  ETP centrally works with package_id.  Rather than making a new instance of ETP just make a new instance of the content folder and use the package id of the package you want to use in cr_folder.package_id.  In your case the acs-subsite.

The problem should arise only in theory is the name collision of the content item.  For example say the package you picked is bboard.  On the bboard you have 2 contents that you want etp to manage.  The names of those 2 contents must be unique in cr_folders AND www of the package.  This is why etp-* convention is made.

In the CMS that I am working on I did not decide to use this in favor of waiting for using the new portal code, or whatever other features of OpenACS may have.  I decided not to use package_id unlike ETP, but there are drawbacks too.

Maybe its a good topic for the OpenACS chat is how to make 2 or more package be accessible on a single site node?  Or maybe if this is a good thing to do or not.  The purpose of having portlets is to answer this situation, right?  I do not know about portlets so I can't comment on that.

Collapse
Posted by Don Baccus on
Why should ETP be written as a singleton package?  Why shouldn't it use its own package id rather than a subsite package id?

This is pretty much a central paradigm of the subsite-centric datamodel and programming paradigm.

Packages written to use subsites correctly will always work correctly when deployed on websites with a single subsite (the "/" subsite).  I don't see that shortcuts such as seem to be taken by ETP make it any more robust than writing it to be subsite aware in the first place ...

Collapse
Posted by Dave Bauer on
I think we have a misunderstanding.

ETP has a package instance mounted for each site node under which you would like to manage content.

Except at / or any other subsite root folder, where the acs-subsite package is already mounted. There what we do is use and index.vuh to grab the package_id of the acs-subsite, and look in cr_folders to see which folder has that package_id assigned to it.

This works for the main subsite because a cr_folder is assigned to that package_id. When a new subsite package is mounted, no cr_folder is created with the subsite package_id.

I manually created the cr_folders and set cr_folders.package_id to the acs-subsite package_id for the subsites I created at openacs.org for the OpenACS and dotLRN projects. This works, but it obviously not the best way to do that. I wanted a way to automate this, and was wondering if the additional subsites should be setup like the main subsite by the acs-subsite package or if ETP should handle it.

Collapse
Posted by Dave Bauer on
ok. I tracked down this problem. ETP is smart enought to create a folder on the package where you are trying to use it. What causes an error is if the directory that is the parent of the acs-subsite package does not have a cr_folder assigned to it.

Right now, ETP tries to get the cr_folder of the parent package and assign that as the parent of the new folder it creates.

So now my question is, should the cr_fodler hierarchy match the site-node hierarchy? Is it ok is an acs-subsite content folder in a subdirectory does not have a parent folder?

Collapse
Posted by Jun Yamog on
Hi Dave,

I think its best to have ETP handle it.  When you create a new subsection/ETP instance, you have the option to piggy back on an acs-subsite or create a new ETP instance.

Still my opinion in going forward on OpenACS code is to remove the ETP stuff on acs-subsite.  Of course if its your client project it would not matter.

Making content available to another package (acs-subsite) from another package (etp) maybe handled better with portlets.  (Not sure thought, dont know about portlets except the concept).  There was a time I asked DonB a long time ago (no sure if he still remebers it), is to make ETP piggy back on all packages by using the package_id on the cr_folders.  It was an interesting idea and possibly a workable one, although now I think it was a silly idea.  Because dotLRN seem to have showed the way for me how to get content from another package.

Collapse
Posted by Dave Bauer on
I think the issue here is that acs-subsite has to be mounted somewhere, and you can't mount any other package there. You can always put an adp page in www/subsite-name but really that is just a different kind of hack. If i want to create a new subsite that is all ready to go, I will need some way to add and edit content on the index page in that directory at least.

So maybe we can't solve this in this disucssion, but we need to decide the best way to handle this.

Collapse
Posted by Jun Yamog on
Hi Dave,

Why not make the acs-subsite cr_folder be the parent id?  Pages on an acs-subsite say foopage will be under that acs-subsite cr_folder instance.  So foopage.parent_id is the folder_id of the acs-subsite.

Will that do?

Collapse
Posted by Dave Bauer on
Jun,

Basiaclly that is what I am doing. I set the parent_id of the folder to 0.

I am finding that I can not reproduce the bugs I saw on openacs.org, so I am not even sure there is something that needs to be fixed.

Collapse
Posted by Lars Pind on
I was just sitting here looking into ETP again.

Over the past few days I've realized that what would really make sense was to be able to put up pages anywhere, in any package.

For example, at http://www.collaboraid.biz/events/, we've put up a page about accomodations, which obviously isn't part of the events package, but logically, the page belongs under /events. Another example would be a posting policy for forums. Or the forums index page, which lists the available forums, which I could very well see you wanting to customize so some forums are displayed in a larger font than others, or some other graphical means of emphasis.

The point is that if you're stuck with only what the application provides, you're limited in how effectively you can communicate, when it comes to applications that are both functional and informational.

The next step would be to be able to use ETP to customize the package-provided index.adp, event-info.adp, and similar pages, which are part of the application logic and live in the file system. But really, being able to mock with them on a per-package instance level would be really useful. Think also a blogger.com style site, where each individual blogger can change his templates through ETP.

The next step again would be to allow you to change the event-info.adp page, not on a per-package-instance basis, but on a per-event basis. I think something like that is really required for something like an events package, where the way you do it, and what's important, can differ in so many ways, as events really aren't just, and never will be, events.

Do you follow me?

The next question to ask, of course, is about implementation. What's ETP's relationship to the packages for which it defines pages? Another applications which I could see provide functionality like this would be and Portals. In combination with ETP. And depending on what it turns out to be, ETP is just a special variant of a CMS application.

Thoughts, anyone?

/Lars

Collapse
Posted by Dave Bauer on
Lars,

I had this same idea. For implementation we need a content folder per site-node. I am not sure about the interface. Maybe the improved ETP that uses the CR folder/item template assignment would be good.

Basically I want to be able to replace any ADP in the filesystem with a version saved in a content folder instead. That allows easy customization of the display of a package.

So I definitely want to explore this. CMS currently can manage content in any content-folder, so there are probably some ideas to borrow from there.