Forum OpenACS Development: Re: How OpenACS coding could get its groove back

Collapse
Posted by Jun Yamog on
Hi Joel,

Great work!  I better update mine to use /lib instead of /resources.  Also make a /test :)

Great work!

Collapse
Posted by Joel Aufrecht on
Branimir and I came up with the tongue-in-cheek assertion that ACS has many fewer contributions and shared libraries than Java because, in Java it's so complicated to accomplish anything at all that, once you've done it, you've already done it in a global, reusable fashion and you might as well share it; whereas in OpenACS, it's just soo easy to make little tweaks that solve your problem, but really hard to contribute them back. In the terms of this thread, the groove can be the enemy of the community, because it can lead to lots of customized OpenACS work not being shared or sharable.

Here's a concrete example. I want the separator character in my breadcrumb trail to be a <, not a :. Since I've made this same change five times on five different sites, I already know that I just find ad_context_bar (it's in acs-tcl). ad_context_bar takes an argument to override the default :, but since it's called from so many places, it's not practical to use that. The Right Way at this point would be to create a new parameter in acs-subsite that overrides the default, but that would involve changes to two packages and upgrade scripts and testing etc. Instead, I do it the Wrong Way: I just change a single character in one file and I've solved my problem. And forked my code. And I'll have to do again in the future, and newcomers who want to change their own sites will each have to waste an hour or two tracking down the code to ad_context_bar and figuring out how to change it.

How can we make it easier to do the Right Way?

Collapse
Posted by Vamsee Kanakala on
I totally agree with Joel. I recently spent a whole day scratching my head over how ad_context_bar really worked, and why there seems to be almost half a dozen ways to do the context bar. In the end I did resort to the 'Wrong Way' :)

-Vamsee.

Collapse
Posted by Malte Sussdorff on
I don't think there are many possibilities in general to make things the right way. The task you mentioned (create a new parameter, test it) is something which we could put up in a task tracker and maybe someone will find the time and actually implement it. But for the experienced developer it is (at this stage) easier to fork, keep a note on the fork and resolve any conflicts that might arise from a CVS update.
Collapse
Posted by Nagita Karunaratne on
Somewhere in the aD literature (not that it means that its correct) is the argument that trying to make a piece of software serve every possible situation it's likely to encounter will exponentially increase the size and in the end will not 100% solve the problem.

How this applies to a toolkit of multiple intergrated modules, I don't know ...

Collapse
Posted by Andrew Piskorski on
Joel, on your specific little ad_context_bar example, there's at least one much easier "right way" to do it:

You're saying that the default separator character is hard-coded into the proc. Ok, simply change that to instead read the default from the AOLserver config file, defaulting to the current hard-coded character if the parameter is not defined at all in the config file. Then define whatever character you want in your own config file. There, you're done, it was really easy, and your change should also be suitable for contributing back to the toolkit.