Forum .LRN Q&A: .LRN Planner code leakaing into application packages.

1: .LRN Planner code leakaing into application packages.

Posted by Dave Bauer on 07/13/09 08:03 PM

This is implemented backwards:

(see https://openacs.org/xowiki/planner_for_dotlrn)
-----
Specific callbacks: These callbacks need to be implemented for each package because it must return the url for different actions on an specific object type.

1. search::url
2. dotlrn::blocks::edit_url
3. dotlrn::blocks::delete_url

Standard callbacks: These callbacks are implemented once in the dotlrn package because there's no difference in the code needed for all packages.*

1. dotlrn" dotlrn::blocks::extend_form
2. dotlrn::blocks::insert_object

-----

I think this may duplicate existing functionality in acs-subsite to get object URLs see: https://openacs.org/api-doc/proc-view?proc=callback%3a%3asubsite%3a%3aurl%3a%3acontract

For these kinds of features that will touch many packages, it is important to discuss the plans and implementation before coding to avoid this type of problem.

The application packages could be fixed to add this subsite callback and it could be used by the Planner PLUS any other application that might use it. This would then be generally useful and improve the toolkit, instead of assuming that dotlrn is special and requires different coding that then rest of OpenACS.

I don't see anything in there that is not useful outside of dotlrn that couldn't have been implemented generically.

I suggest before changes are made to the specific applications that the authors check out the subsite::url callbacks and reuse them, or open a discussion about alternative implementation, if the subsite::url is not sufficient.

2: Re: .LRN Planner code leakaing into application packages. (response to 1)

Posted by Alvaro Rodriguez on 07/14/09 05:49 AM

Hi Dave,

I was about to post in the forums about this package, I have not finished that wiki page... I've corrected the callbacks, it is not dotlrn::blocks:: but planner::, I know for this matters I could implement the subsite callbacks, in fact I am using the current search::url, the packages that had it already implemented I'm using that existing one, for the ones that's not implemented I did, for the other callbacks:

2. dotlrn::blocks::edit_url -> planner::edit_url
3. dotlrn::blocks::delete_url -> planner::delete_url

I believe for this callbacks are a very specific case for the planner and I didn't think that would be helpful to other packages that's why I didn't implement them as subsite::...

About dotlrn as the namespace, this was not my approach, the real code is not like that, that was some old writing that went in the wiki page without I noticing it, I've updated it. If it is better to define all callbacks in subsite namespace, let me know and I can do that. This package works with a script that will patch the packages in order to work all together.

This package is not part of a official release and I'm not committing anything to other packages, I now this package includes some things that could be generic to use in the toolkit and I'm sure this needs some work, I'm just doing this so that people can start using it, thanks for the feedback, this is good in order to improve this package and hopefully one day it could be part of dotlrn official release.

I will be making an announcement about this package, we can always talk this over in a .lrn meeting.

3: Re: .LRN Planner code leakaing into application packages. (response to 1)

Posted by Dave Bauer on 07/14/09 01:08 PM

Ok, my mistake :) I still think you can reuse the subsite::url feature which allows you to specify specific URLs for edit/delete etc.

Changing the namespace from dotlrn to planner doesn't really change the issue, but if it doesn't affect other packages, then it isn't an issue for me.

Thanks for the clarifications!

4: Re: .LRN Planner code leakaing into application packages. (response to 3)

Posted by Alvaro Rodriguez on 07/14/09 04:20 PM

I didn't notice the -type parameter in the proc you pointed me before: https://openacs.org/api-doc/proc-view?proc=callback%3a%3asubsite%3a%3aurl%3a%3acontract, you're right I could have used that, I didn't know that when I started developing this package. I'll be improving this package along the way and that will be on top of my to-do list :D.

Thanks for the comments and suggestions.

5: Re: .LRN Planner code leakaing into application packages. (response to 1)

Posted by Dave Bauer on 07/14/09 04:33 PM

You are welcome. I think this is a very useful tool to let teachers organize content in their class.

6: Re: Res: .LRN Planner code leakaing into application packages. (response to 1)

Posted by Rocael Hernández Rizzardini on 07/14/09 07:06 PM

Will be good to know how people see the callback approach used to create (insert) objects. Not sure if there is a better way of doing it besides creating a new method? for doing such kind of changes.

As a side note: The planner at some point should be able to work even without .LRN installed.

7: Re: Res: .LRN Planner code leakaing into application packages. (response to 6)

Posted by Dave Bauer on 07/14/09 07:32 PM

Yes, that is a shortcoming, but I don't see much reason why there can't be a general interface for adding an object. We have one for adding cr_items already.

Don is researching this area now so we might have a solution eventually.