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

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?

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?

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'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?

/Lars

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.