Forum OpenACS Development: new acs-rels, orgs, persons functionality (widgets etc.) to commit

1: new acs-rels, orgs, persons functionality (widgets etc.) to commit

Posted by Mark Aufflick on 07/21/04 05:07 PM

Well I am finally getting time to polish up a bunch of fixes and features that Dave Hill, Walter McGinnis and I developed earlier this year for one of their clients.

My question is really where people think I should put the acs-rels stuff. Currently, rels code is spattered around a couple of packages like subsite, acs-tcl etc. There is web UI, ad_form widgets, tcl and plsql api code, and no obvious correct home.

Maybe I should also attempt a cleanup of the acsrels stuff at the same time - i would love to move it into a namespace (and of course write wrappers with the old names marked deprecated for compatibility.

Opinions?

2: Re: new acs-rels, orgs, persons functionality (widgets etc.) to commit (response to 1)

Posted by Malte Sussdorff on 07/21/04 05:58 PM

I would put it into its own namespace and put it into its own package if possible (acs-relationships).

3: Re: new acs-rels, orgs, persons functionality (widgets etc.) to commit (response to 2)

Posted by Jeff Davis on 07/21/04 06:05 PM

can you put a context diff versus the baseline release somewhere we could look at it?

4: Re: new acs-rels, orgs, persons functionality (widgets etc.) to commit (response to 1)

Posted by Mark Aufflick on 07/22/04 03:27 PM

Malte, that's my thinking too.

Jeff, It's against pre-5.0 right now so I will port it to 5.1 and tidy it at the same time then post diffs etc. before comitting.

Does anyone have a problem with the idea of moving all relationship related api (tcl and plsql) into a new package called acs-rels ?

5: Re: new acs-rels, orgs, persons functionality (widgets etc.) to commit (response to 4)

Posted by Jeff Davis on 07/22/04 03:50 PM

I don't think the datamodel or plsql should be moved into a seprate package since it's in acs-kernel now and for example groups-body-create.sql use acs_rel__new and acs_rel_type__new.

I don't feel as strongly about the tcl api, although I would probably be inclined to put it in acs-tcl in an namespace; I am not sure I see a lot of value in it being in a seperate package since it would always have to be present and in acs-core.

As usual, anything we can remove from acs-subsite is probably good.

6: Re: new acs-rels, orgs, persons functionality (widgets etc.) to commit (response to 1)

Posted by Mark Aufflick on 07/22/04 03:58 PM

I agree it would be a very small package, but the problem with putting it in acs-tcl is that it has UI.

In fact some acs-rels stuff is already in acs-tcl, but the ui components are in acs-subsite.

I probably agree about the datamodel and plsql staying in acs-kernel. It is pretty key to the whole system.

Maybe instead of an acs-rels package we need an acs-util package (or similar) - to be used in a similar way to acs-tcl, but it can have ui as well.

7: Re: new acs-rels, orgs, persons functionality (widgets etc.) to commit (response to 6)

Posted by Malte Sussdorff on 07/22/04 04:33 PM

Risking to sound dump: how about adding a UI part to the acs-tcl package ?

8: Re: new acs-rels, orgs, persons functionality (widgets etc.) to commit (response to 7)

Posted by Jeff Davis on 07/22/04 05:38 PM

I think adding it to acs-tcl or adding an acs-util package is the wrong way to go. If you look at acs-subsite for example one of the biggest problems is that it is such a catchall, you can't have a subsite which does not have admin pages, there are a ton of pages in the url space you may or may not want in a given subsite.

I think there is nothing that says the api can't go in acs-tcl and the ui in a rel-ui package (that's what I would prefer really).

9: Re: new acs-rels, orgs, persons functionality (widgets etc.) to commit (response to 1)

Posted by Don Baccus on 07/22/04 11:49 PM

Hmmm...there's a lot of other cruft in acs-subsite that builds on rels - group UI, relseg UI, and all that stuff. It would be nice to have all that kernel UI stuff out of the subsite dumping ground - "acs-kernel-ui" perhaps? But then ... why not have kernel ui in the acs-kernel package? I have to admit, though, that it doesn't particularly bother me that this stuff's in acs-subsite.

For a long time I've wished acs-tcl was restricted to utility Tcl procs not related directly to our kernel datamodel (i.e. things like ad_page_contract) with kernel Tcl API in acs-kernel...currently we have some kernel Tcl API in acs-tcl, other bits in acs-subsite, and that's just wrong.

11: acs-tcl package (response to 9)

Posted by Andrew Piskorski on 07/23/04 06:56 AM

Yes, it sure would be nice to be able to take the stock OpenACS acs-tcl package (with ad_proc, ad_page_contract, the db api, watchdog procs, etc. etc.), drop it into a plain old AOLserver with no OpenACS, and have it Just Work. Last time I did something like that, it required lots of fiddling just the parts I needed to work at all.

13: Re: acs-tcl package (response to 11)

Posted by Malte Sussdorff on 07/23/04 10:52 AM

Hi Andrew, could you do the effort again (taking out the acs-tcl package) and clean it up so that:

- All procedures that are required by acs-tcl that are independent of OpenACS but somehow made it into a different directory, are moved into acs-tcl.
- All procedures in acs-tcl that rely on code in OpenACS are moved to acs-kernel.

If I'm not mistaken this should enable us to maintain an acs-tcl package that is clean of OpenACS dependend code and can be reused everywhere else. We might even upload all these enhancements to the AOLserver CVS 😊.

I'd assume if we want to make a policy out of this, we would have to TIP this, therefore it would be nice to get some feeling if people agree to be doing this. I for myself am sold to the idea and it makes a lot of sense to me (as I was always wondering why we have acs-kernel and acs-tcl and this differentiation posted by Andrew makes utter sense and should be published in guidelines).

14: Re: acs-tcl package (response to 13)

Posted by Andrew Piskorski on 07/24/04 07:00 AM

Malte, since it's clear now that other people would like it too, yes, I'm willing to work on acs-tcl as you describe. Not right now though, and I can't give you a timeline either, as I have other things on my plate at the moment. But I'll definitely add it to my list as of now.

10: Re: new acs-rels, orgs, persons functionality (widgets etc.) to commit (response to 1)

Posted by Mark Aufflick on 07/23/04 04:39 AM

An acs-kernel-ui module sounds like a nice idea.

So you end up with:

acs-kernel : seriously low level data model, plsql, tcl api's
acs-tcl : stuff that builds on acs-kernel and provides tcl api's
acs-kernel-ui : stuff that buils on acs-kernel (and possibly acs-tcl) and provides gui pages, ad_form widgets etc.

12: Re: new acs-rels, orgs, persons functionality (widgets etc.) to commit (response to 10)

Posted by Andrew Piskorski on 07/23/04 07:06 AM

Mark, no. The idea is that acs-tcl should, ideally, be just Tcl code, entirely independent of the OpenACS data model. Therefore it must not "build on" acs-kernel at all. A nice bonus of that organization is that (with some extra hooks), you should be able to use all of the acs-tcl code outside of OpenACS entirely. All other OpenACS packages, on the other hand, are of course perfectly free to use all the functionality in acs-tcl - that's the primary reason for acs-tcl's existence, after all.