Forum OpenACS Development: new acs-rels, orgs, persons functionality (widgets etc.) to commit
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.
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 ?
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.
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.
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).
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.
- 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).
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.