Forum OpenACS Development: CMS forms + widgets versus Classified Ads

Hi

I just starting looking at the Classified Ads package as an example of a package that uses the CR. I notice that CA uses it's own widgets procs and tables and even attributes procs and tables in some cases. Is this because the CMS widgets/attributes procs are outdated or not useful? ETP seems to do it's own display of FORM widgets with 'ad_ ' procs. What's the right choice for use in new packages that will be declaring content_types, attributes and widgets?!
TIA

Also Classified Ads may've been written as part of the 4.x development process (back in the Ars Digita days) before the CMS merge with ACS 4 was completed.

We are planning to mainstream the CMS widget/attributes stuff and the way they're used to allow autogeneration of forms and other good stuff over the next few months.  They're definitely not out of date but rather we'd like to see this functionality extended to all objects.

Hi,

Thanks Jun. That is what I was referring to (ded's Classifieds).

I was not able to get the aD CMS to create a FORM using [content::get_revision_form db content_type item_id form_name]. It gave me errors and trying to track them down involved too many layers of not-my-own-code and lots of database tables:( The error was briefly "can't read "rows:rowcount": no such variable" while executing "template::util::array_to_vars row."

But I was able to get the Classifieds code (calling it from my first package I'm building) to build a FORM from a content_type by calling [classified-ads::widgets::get_widget_params -content_type $content_type -form_id $form_name].  I used all aD CMS code (so does Classifieds underneath until it gets to the widget stuff) up until the step where I register and customize widgets. So using the aD CMS UI, I can see my content_types and attributes but the "Register Widget" link shows up as if I don't have associated widgets for my attributes (the aD CMS doesn't recognize them is all).

I have to say that the Classifieds code to add widgets and customize their attributes with a single call to ca_attributes__register_widget per widget, is pretty clean -- easy to use and easy to follow. The params closely mirror the ad_form/ACS Templating parameters you'd expect to use. This makes it much easier (since I recently learned to use template::form etc and ad_form). The aD CMS calls to register widgets and customize their attributes require many more proc calls and fill more tables than the Classifieds code to create the same FORM (theoretically of course, since my FORM didn't actually get rendered in the CMS version).

Also, the Classifieds code has the option of making a widget  sitewide or specific to a package instance.

btw, what is the cool code of Rob Locke? I feel like I'm missing something now...

We really want to tie this to acs constructs, not SQL DDL, because we want to be able to override them easily.  And one way to do this is to define a new type that doesn't exist in SQL.  For instance the rich text widget in the form templating code combines SQL text and boolean columns to form a text item that may be flagged as HTML or plain text.

We need functionality of this sort.

We need to straighten this mess out.  We need to start reusing code rather than reinvent it.

Tammy,

Are you customizing the existing CMS package? Basically any parts of CMS that are generally useful should be moved into a seperate service package. Some of the parts might belong in the content repository, and some others might be generally useful as part of acs-templating. Others might be more specific to a content management system. It is my goal to end up with a package that provides CMS service to another package that presents the CMS user interface.

I am going to be working on ETP in the next couple of weeks to bring it more in line with standard content repository features. I am also coordinating with Jun and his BCMS package (in contrib) so that we can eventually have a clear set of tools for building a CMS.

Tammy,

Sure, it would be interesting to see how you are using the system to generate forms.

As I said, we should be able to enhance the form-builder part of acs-templating to make these widgets available to all packages. One part of CMS that assigns the CMS widgets to attributes of objects will have to be generalized. Acs_attributes does some of this, but I think there is not 100% overlap in the functionality.

Jeff Davis has used the existing form generation stuff in the CMS to autogenerate forms for the photobook application that has been done for Sloan recently and will soon show up in .LRN.

He would be a good person to talk to.  He might know if it would be easy to extend for normal objects.

Thanks Don,

So Jeff Davis is the point man on this.  I guess Tom Jackson, Rob Locke and Tammy can ping him about this.  It not currently near my radar to do automatic form generation.  Guys ping up Jeff Davis on this so maybe some form of direction can be made.