Forum OpenACS Development: Re: The future of OpenACS

Collapse
7: Re: The future of OpenACS (response to 1)
Posted by Malte Sussdorff on
In contrast to Don I can only say that I agree with your templates concern, yet, we solve it differently. In all our (new) installations we have a customer package which contains a /templates directory and a /www/resources directory. First thing before we start working on that customer is take all the templates from OpenACS and XoWIKI into /templates and store all CSS and Javascript files in /www/resources. Then we start editing there.

Reason: When we upgraded in the past we *always* blew it up because we forgot something that changed in a template or in a CSS file. This is not happening anymore and we just do a comparison if we need to update the our custom CSS / template with a version from OpenACS. With the latest upgrade and overhaul we decided to exchange the templates (custom) with the ones from OpenACS and modify the OpenACS ones to include the visible changes (visible for the user that is).

=> Yes, we keep everything in one place but no, we do not do this in OpenACS itself which is fine.

If there is interest, someone can probably quickly write up a "create customer package" script, which will create a package and copy all templates and CSS files into the package. Additionally it would change the parameters to use the new location for the templates. This might go as far as change the location for the /lib/ code from acs-subsite (e.g. login, user-new, user-info, email-confirm).

Furthermore I think we could add a function there that let's us edit the templates and CSS files from the browser. And if we do this, we could make each file an object in the content repository and save the published version on the harddisk.

I am willing to help anyone write this code. I am also willing to provide code snippets and explanations how to do this in XoTCL, if someone wants to learn this. Sadly I wont have the time to write it all by myself (and, more to the poinnt, involve myself in testing it out).

There is no need to refactor everything in XoTCL. I start doing this if I need to work considerably on content items by using Generic::CrItem functions from xotcl-core, making my life easier, but there is no need in my opinion to do this for existing code. As Don mentioned, it also makes working on core much harder for developers that have no knowledge of XoTCL. And finding the places where suddenly variables pop up from or where a function is defined is harder when you have inheritance.

Gustaf, what would be helpful here would be an API Browser for classes which lets you search for something like "xowiki::FormPage new" and display you the new function wherever it is defined with the link to the file it is defined on (in this case I think it is ::Generic::CrItem new, but I might be wrong). Or, if this exists, and explanation for an XoTCL dummy like myself where to find it 😊.

I will write up a customization document this week on how we do customizations, based also on the feedback from the community in the customizations thread. If this is going to become a best practice is something for you to decide then.

Also, one should note that most of your needs come from the use of OpenACS as a CMS, which is where XoWIKI is getting at . Just to put them into context.

So keep on using OpenACS, keep on bringing the feedback and don't feel bad about selective memories of other people. Just don't hope we can do much about it unless you find someone committed.

Tom, is your package available somewhere to look at and would it be a worthwhile addition to OpenACS as a whole. It seems to me that it is highly useful for custom build content types, yet I do not understand how this would work on the existing types like users. Yet I see a huge benefit if this work could make it into a generic dynamic attribute solution, as it would fill the missing gap. Do you store the templates in the database or do you write them to disk as well?

Collapse
8: Re: The future of OpenACS (response to 7)
Posted by Stefan Sobernig on
Gustaf, what would be helpful here would be an API Browser for classes which lets you search for something like "xowiki::FormPage new" and display you the new function wherever it is defined with the link to the file it is defined on (in this case I think it is ::Generic::CrItem new, but I might be wrong). Or, if this exists, and explanation for an XoTCL dummy like myself where to find it

On Gustaf's behalf, xotcl-core, since its very beginning, comes with a two flavours of "api browsers", a native xotcl or object-centric one, and a seamless OACS api browser integration. After having installed xotcl-core, point your browser to /xotcl/ and enjoy! Alternatively, look for objects and/or methods in the good old api browser, and you won't be disappointed.
Collapse
10: Re: The future of OpenACS (response to 8)
Posted by Malte Sussdorff on
Hi Stefan, /xotcl is a nice Browser, sadly it does not help with my specific request at all. I need to move up the class hierachy and show all methods (even the undocumented ones) and when I reach it, I have no way of accessing the source of the class function let alone see where it (originally) is defined. I am aware that you can overwrite them on the fly, so the "where do they come from" might not be correct, but at least showing the body of the function would help (http://cognovis.de/xotcl/show-object?show%5fsource=0&object=%3a%3axowiki%3a%3aPage&show%5fmethods=2)

The above works nicely when a function is documented with ad_instproc, sadly it miserably fails for anything else.

Furthermore, when I type in e.g. "get_object_type", I see the generic class procedure (which is documented, so things are fine). Sadly, unless I know that a FormPage is a CrItem, I would not understand what xowiki::FormPage get_object_type does. So, I would love to see, if I type in "xowiki::FormPage get_object_type" that the API Browser finds me the Generic::CrItem get_object_type procedure and displays this (probably along with a hint that this is the version being used by xowiki::FormPage).

Does this make my problems a little bit clearer with the currently provided documentation? I do have the slight feeling, regardless what can be done with the API Browser and the XoTCL browser we still need make a lot more procedures using ad_instproc and Classes using the -ad_doc parameter for us to really "digg" XoTCL in OpenACS.

And I agree with Gustaf that on the XoTCL Browser having "Show all methods including inherited ones" will probably lead to pages of procedures / methods being displayed, but at least it helps us reading the code.

Not having developed in Java or other OO languages, how do the IDEs for them solve the problem of inherited Methods and the documentation for them. Any Pointers?

Collapse
12: Re: The future of OpenACS (response to 7)
Posted by Tom Jackson on
Tom, is your package available somewhere to look at and would it be a worthwhile addition to OpenACS as a whole. It seems to me that it is highly useful for custom build content types, yet I do not understand how this would work on the existing types like users. Yet I see a huge benefit if this work could make it into a generic dynamic attribute solution, as it would fill the missing gap. Do you store the templates in the database or do you write them to disk as well?

You can browse the package at http://rmadilo.com/files/cams/

This is not the same thing as building custom types, but look at the data model. Each content type begins with a title and content. You can add attributes to the type. When you add content, you first enter the title/content and then you can add the attributes. For instance, your content type could have an image attribute, or call it whatever you want MyImage, whatever. When you add an attribute, you define the content type and the form widget. If it is a file widget, you can upload a file, or more than one file for the attribute. The package name CAMS stands for Content Application Management System. The idea was to allow developers to create certain types of applications focused on content: how to get it into the system and how to display it.

Templates are used for the master, content type and content item. In addition, the content of each item can be treated as a template. Special tags can be included in the template to format/insert the attributes associated with a content item. So if you upload an image, you can use the same data to insert a link to the image, or display it inline, anywhere in the content.

New templates are stored in the database, they are content items. But they are also 'compiled' and stored as files for use. The 'compiling' just applies any attributes, so that the same base template could be reused.

Some applications are here: http://whogeenie.com/cams/

Collapse
13: Re: The future of OpenACS (response to 7)
Posted by Don Baccus on
Furthermore I think we could add a function there that let's us edit the templates and CSS files from the browser.
Note that this is a totally different issue than "where package-specific resource files should go", and I didn't disagree with it.

So if it's good to put all templates in /templates, and all resources in /www/resources, then clearly all tcl scripts should to into /tcl and all library scripts should to into /lib and all package info files into /info, right?

If you don't please so, please create a coherent argument as to why customized (or untouched) tcl scripts should be treated differently than customized (or untouched) resource files.