Forum .LRN Q&A: General Comments and ZEN

Collapse
Posted by Malte Sussdorff on
I am going to work on General Comments and basicaly get rid of the old old code for adding a comment and copy the new forums/message/post code over and adapt it (so you have previews and can add attachments in one go).

Should I do this on HEAD or on oacs-5-3 branch? My assumption would be HEAD, but then some poor soul would have to make the ZEN changes on oacs-5-3, knowing it will all be in vain as in HEAD there is already a better version which has nothing to do with the current version (as the code predates ad_form).

Collapse
Posted by Dave Bauer on
Malte,

Start with the old improved general comments code
http://cvs.openacs.org/cvs/openacs-4/contrib/packages/general-comments/

I recommend NOT using the attachments package. I would suggest the new attach-image code under acs-templating/www/scripts/xinha. This would require using the richtext area though. I need to finish up a way to allow the uploads to work if javascript is turned off but I think the code in general is much simpler than attachments.

Collapse
Posted by Dave Bauer on
Oops. there is attach-image and attach file in acs-templating/www/scripts/xinha. They provide custom code to allow the user to pick previously uploaded files/images.
Collapse
Posted by Jon Griffin on
Why would you "copy" code. That is not a good way to program. If the code is reusable, put it into a library so it only gets changed in one place.
Collapse
Posted by Malte Sussdorff on
Hi Jon, why copy? How about:

* Different data storage
* Different labeling of functionality
* Slightly different behaviour

Though I am all for reusing code, this in my opinion is a clear candidate for "copy and adapt".

Collapse
Posted by Malte Sussdorff on
Thanks for the notice about contrib. I would never have looked there 😊.

As for attachments, no intention to use it. I would just provide an "file upload" widget and store the file in the CR with the comment_id as the parent_id. Download would be handled through the content-repository as will delete (though I would have to write that page).

Talking about content-repository. Has anyone successfully used /acs-content-repository/index.vuh for retrieving content files? Looking at it there seems to be a certain lack of functionality available e.g. at file-storage/www/download/index.vuh. But we should have a general method, instead of file-storage download, general comments download, contacts download (you get the picture).

Collapse
Posted by Emmanuelle Raffenne on
Malte,

dotLRN 2.3.0 beta release is scheduled by mid of april so please, do it on HEAD.

Collapse
Posted by Don Baccus on
As Emma says, it is too late to put new code on the oacs-5-3 branch. By now, I should think everyone is aware that after we close a branch and start releases (acs core 5.3.1 alpha and .LRN 2.3.0 alpha have both been released) that NO NEW DEVELOPMENT should go into the branch.

I second what Dave says. He did a partial rewrite of general comments and it's never been finished. This would be a good opportunity to do so, perhaps.

And, if there's any way to reuse rather than copy-and-paste code, we should do it. What additional functionality is the attachment code providing in forums that shouldn't exist in general comments? The whole idea behind common services like general comments is orthagonality - the notion that the same UI, functionality, etc should be presented whenever one can make comments on an object. Per-package customization is something that should be avoided ...

Collapse
Posted by Dave Bauer on
Malte,

acs-subsite/www/image.vuh and acs-subsite/www/file.vuh should do what you want.

Take a look at the attach-file and attach-image code. It already can "attach" an uploaded file to any object and should do what you want. Its exactly what I planned to do with general comments, but never had time or need to finish it.

Collapse
Posted by Gustaf Neumann on
I fully agree with Jon, copy&modify should not be the first choice, rather the last one. The more copies exist the more work it becomes to fix bugs, improve the base functionality. it, etc. Maintainability goes down.

The example looks exactly like a use case for subclassing in the OO-world, or, if there is no OO available as a case of modularization and configuration.

Collapse
Posted by Malte Sussdorff on
Be it as it may, I am dealing with the fact that the datastorage is different as are after submit action, the labeling of the AD Form is different and with forums you have the option to extend the entry fields per form, which is something not needed in general comments.

So what I will do is write a page with an ad_form which allows you to enter a Subject, a Text which is stored in general comments along with a file that is attached to it. I will *NOT* copy forums anymore

a) Because then I would have to explain why I did it 😊
b) It is probably more work to rip the forums specific code out of post.tcl then to create comment-add.tcl from scratch.

In an ideal world we would only have *one* include which can be included everywhere which we just give the object type and it will generate me the entry form based on acs-attributes. But this is something to get once we have a clarification on adding dynamic types and the like, not for single page with three entry items in general comments. Not to mention the fact that you might do some code after processing dependent on type before saving it in the database (though that could be handled with user exits / callbacks).

One question Dave: What is the logic behind file.vuh and image.vuh in acs-subsite, or, better asked, why do we mount acs-content-repository in the first place if the code is duplicated in acs-subsite?

And with regards to attach-file / attach-image, I think the goal for general comments is different. I am going to use the file-upload widget in case there does not exist Javascript enabled richtext, and then reuse content::item::new with the tmp_filename switch to attach the file to the comment and append the code for accessing this file (read f_href in attach-file) at the bottom of the code. No need for extensive sharing of the file and reuseability, as it is after all "just" an attachment.

What I do not like about the general comments package in contrib as an example: It does not allow you to preview the comment. So this is code which I will reuse from post.tcl as this is actually a place where I think it is decently solved. It also needs some serious cleaning up, so it might be quicker to write it from scratch (most of the files currently in there would go down the drain). I will reuse the commant-add-edit* code though and remove all the unnecessary pages.