Forum OpenACS Q&A: Re: Photo album for huge image library?

Collapse
Posted by Tom Jackson on

Keith hasn't even defined the problem completely and everyone chants 'CR'. This is total 'BS'. A standard paradigm is to extend the acs_objects table, more packages follow that paradigm than use the CR. If you don't want revisions hanging around for every object you create, or you don't want to do a few extra joins to get you data back out again, why do you have to do so?

Keith's stated concern is portability. Instead of chanting 'CR' at him, why not step up and show how portability can be achieved, and what the CR can do to enhance his project?

If we want standard tools, they should apply to acs_objects, not items in the CR. This is a general tool, this is a standard paradigm. Then every time we add a tool it applies to everything, because IMNSHO everything in the database is content.

But before something can be called a standard paradigm, it has to be shown it can easily solve problems that are common to the area. So far the examples I have seen, and the amount of work that appears to be required to create them, leads me to believe that using the CR is difficult.

Recreating the functionality in your own package will also be time consuming, so if you need most of the features of the CR you might decide it is worth figuring out how to use it.

Collapse
Posted by Talli Somekh on
So Tom... does this mean you've never tried to build on the CR?

And Keith's stated problems, as I read it, was portability *and* needing to have metadata, searchability, indexing, etc - all things the CR does very well.

The fact that you haven't seen an application being built on the CR doesn't mean it doesn't exist. It just means either those projects aren't open or you haven't built them.

Also, no one I have spoken to said the CR is difficult. Just that the docs suck.

talli

Collapse
Posted by Keith Paskett on
I suspect that good documentation on the CR is more the problem than it being difficult. I've found that to be the case with most things I use in ACS.

When I started learning Unix many years ago, I though every Unix expert had the opionion that "I learned it the hard way and so will you". Now I think it was/is more an "I know how to do that so why should I take time writing it down" attitude. Unfortunately that is the way I tend to work to often.

So what's the fastest way for me to figure out how to use the CR and what the specific benefits will be? Are the docs up-to-date, or do I search for threads in the forums?

Collapse
Posted by Tom Jackson on

With all these happy campers, you would think a few would have released their ideas to the OpenACS community so we could learn from them. Until someone does, why should we be so insistent that Keith follow all the rules and release his code. Are we trying to help Keith, or ourselves here? Just repeating 'CR' doesn't do much to help anyone. Anyway, instead of just saying I am wrong, just point to working examples somewhere that proves I'm totally mistaken. It wouldn't be the first time. Please include with the examples a time estimate: how long did it take to write the package? The fact that it can be done, or that this or that feature is supported is completely meaningless without knowing how much work went in to writing the application, how fragile the code is, how easy it is to modify or understand.

Maybe if a tutorial covered re-implimenting the notes example in the CR and showing all the benefits, how it saves time, etc. that would be a better way of letting someone decide if the CR is good for their application.

Btw, just because something is difficult to use or figure out doesn't mean you shouldn't use it. And once you know it the decision to use it or not for future work becomes easier to make. The biggest benefit of the CR is that it is integrated with OpenACS.