Forum OpenACS Development: Should we make the 'standard-lars' form style the default?

Request notifications

Should we make standard-lars the default form builder style?

And if so, should we make that change in 5.0 only, or should we backport it to 4.6 branch?

I'm  planning on adding a site-wide stylesheet and making the standard-lars form template use CSS. This would be part of it.


I think "yes!" on the first question. Definitely a good idea, but I don't see any real reason to change on 4.6 ... maybe others do?

Are you planning on performing a castling of the "standard" and "standard-lars" template by switching the files, or by changeing the default param to standard-lars?

The former would mean you'd have to remove (or, worse, change) the src attribute in the formtemplate tag in bug-tracker, for instance. I believe that this is the best solution, since people will want to be able to change the template in that package (as well as others) as simple as by setting a package param in acs-templating.

In other words, I propose that all openacs packages never make use of the form-template src attribute in the toolkit.

Does that make sense?

Ola, the idea to never specify src in the formtemplate tag is almost correct, but I don't think it can be a hard rule.

For example, in survey, I want to template the survey question display by offering multiple templates, and allow the administrator to choose a template which will then be specified as the src in the formtemplate tag.

That said, I agree its a good general guideline, and standard-lars should definitely be made the standard form template and enhanced with CSS so the colors can be specified from a sitewide, or package specific CSS file.

A site-wide css and standard-lars as default form template sound very cool.

What about adding the form template as parameter to acs-subsite, next to DefaultMaster, e.g. as FormTemplate, so that people don't have to mess around with symbolic links to change it anymore?

Yeah, I agree with the parameter and the subsite parameter. I've already added a site-wide parameter for default form builder template on acs-kernel, but I'll add another one on acs-subsite.


Standard lars as standard: yes.  I'd suggest renaming standard as blue-pad and standard-lars as standard myself.

An acs-subsite param that can override it: yes, I was planning on sneaking this into 5.0 soon anyway but if Lars wants to do it, fine w/me.

Get rid of the src arg to form template: emphatically NO.  Check out the "transparent-one-row" form template I used at GP to build one-line forms of the "search or text box and 'go' button" variety (often with more than one entry box.)  This kind of flexibility's important.

I notice that Lars added the marking of required elements to standard-lars, something I also did for the custom formtemplate used by Greenpeace.  I like this (obviously) but I think it should be a form create argument with the default "on".  Sometimes folks don't want the marking, for instance one might want to flag the form with an info line saying "all fields are required" ...

I wasn't suggesting to get rid of the src arg to form template. I just wanted to point out that it is bad to hard code the src in a package to, say, "standard-lars" (as I believe is done in Bug Tracker's main form). If you decide to change the form template site-wide, Bug Tracker will keep on rendering its forms using standard-lars. That is wrong to have in the OpenACS distribution, IMHO.

In the end, Bug Tracker like *most* other packages (survey and other packages may be exceptions, sure) should render its forms with standard-lars, by default ...

Ok. I added the 'show_required_p' switch and the acs-subsite parameter (to my local checkout).

I'm ready to commit, except these things are mixed up with some other changes I did.

I've made the changes on the oacs-4-6 branch, because that's where we're currently working. So that's where I'm going to commit them. Everybody's free to merge them over to HEAD, and if no-one else volunteers I will sometime later.

However, the above changes are currently tied up with a few other changes which I'd like to ask your advice on before I go ahead and commit:

- I've added a 'IndexRedirectUrl' parameter to acs-subsite, which will cause the index page to redirect to a given URL. This is useful if you have a subsite which essentially involves just one application, yet you still want to use acs-subsite's groups, etc. Very similar to what Don added to the top-level index page.

- I've added a password expiration feature. You can set the user's password to expire after a certain number of days. When the user logs on after that number of days, he'll be bumped to a page which asks him to change his password. He won't actually get his login cookie issued until he changes his password, and the new password cannot be identical to the old one.

- Similar, I've added an approval expiration feature, which causes users who haven't logged into the system in the last x number of days to have their membership approval state changed to 'needs_approval'. There are a few checks to make sure that if they're approved, but don't log in, they won't go unapproved again until after x number of days.

These are all client project stuff, so they're on 4.6.

Is it cool with you guys if I go ahead and commit those to 4.6 branch?


Ola, I did understand you that way originally, and, in fact, in my local checkout where I have this change sitting now, I've already removed all mention of standard-lars from bug-tracker :)


All excellent except I question the acs-subsite parameter that mimics my global hack.  I only question it because we will want a more general way of setting the acs-subsite's page when the portal system works (for instance.)

OK ... maybe this param's OK (thinking aloud) because it is only invoked if the acs-subsite's default index page is called, and if we add an override to deliver a portal page that's no longer true and the parameter is ignored.

Sound right?

All the expiration options you're discussing sound excellent to me, and thanks for adding the show_required_p option etc etc.

4.6 is fine I guess as long as you're willing to take responsibility for testing with these features enabled and disabled when we kick out 4.6.4.