Forum OpenACS Development: New template tags - switch statement

Way to go, Dan.

Can I ask for a feature? 😉

Do you think it could be made to work something like this (if it doesn't already):

<switch @switch_var@>
    <case value="foo" value="bar" value="baz">
        You selected Foo or Bar or Baz
    </case>
    <case value="blargh">
        You selected blargh
    </case>
    <default>
        Your selection was invalid
    </default>
</switch>

I am sure your <switch> tag will come in handy in many places.

/Ola

Perhaps "<case value in foo bar baz ...>" is cleaner.

This a great feature. Will sure come in handy.

I like the <case in foo bar baz> better. Using regexp's work, but if we don't necessarily have to use them (which seems to be this case), it's probably better since using the regexp engine is much more expensive.

Thanks Dan!

-Roberto

Dan,

<if @z@ in "Greta" "Fred" "Sam">True</if>

is taken from the templating tag reference for "if" page (https://openacs.org/doc/acs-templating/tagref/if.html).

It seems to be in line with the above...

Yes, this last suggestion seems best ... switch statement ... cool!

Excellent, Dan.

Did you add it to acs-templating's documentation? If not, I can do it.

-Roberto

<blockquote> It's at the same place: http://www.brasileiro.net/code/
</blockquote>

Hi Roberto,

I assume your cool tarball will not be included in the 4.6 release and that it is a separate download?  Will you be linking to it from the OACS site or documentation, or perhaps be transferring the tarball itself to the OACS site?

In any case, it seems very useful and should be prominently highlighted.  But, as much as possible, I think we should avoid having to download these things from other sites.

Thanks...

Dan,

This is beautiful, thanks.

I only have one suggestion, which would be to move the condition entirely into the <case> par, for improved readability of the templates, like this:

<switch>
  <case @foobar@ true>
    ...
  </case>
  <case @baz@ eq "greble">
    ...
  </case>
  ...
  <case default>
    ...
  </case>
</switch>

That would make it easier to read the template, because you don't have to read both the <switch> statement and the <case> statement to find out what's going on.

/Lars

Looking in tag-init.tcl, I see that an elseif tag already exists, but I'm not sure why nobody ever uses it.  I sorta of recall a discussion in the past where it was mentioned that there were some problems with elseif, but looking at they code I don't see anything wrong with it.... and giving it a short test, I find that it does indeed work.

This addition is great and makes templates considerably more readable for non programmers. Though I disagree with Lars concerning his idea for storing the variable as well in the case statement for the following reasons:

• You have to mention the variable in every case statement. Despite the fact that this allows a switch for multi variable combinations it does add more code and you have to doublecheck every case statement whether the variable is the same as in the above case statement.
• As a grafik designer I'd see the switch statement, see what variable it concerns and decide quickly whether I'd want to change the code in between. That wouldn't work otherwise.

One suggestion would be to have the default behaviour as it is defined right now and add a flag "multiple" to the switch statement with no variable following. This would say that the variables are contained within the case tags as suggested by Lars. We'd just have to encourage people (either by code or by documentation), not to use the multiple functionality if the flag is not set correctly, otherwise you really don't know what might be happening :).

I realize that this isn't how Tcl's switch statement works.

Anyway, consensus seems to be against it. Never mind :)

/Lars

Roberto ... for a good time ...

Did you make the -cancel_url etc switches work with the "-confirm_template" feature of ad_form?

This (as yet) little known, even more rarely used feature partially automates the generation of "confirm"-style pages.  A chief benefit is that you can still use a single add/edit script and can associate it with a separate "confirm" template that formats and displayes the content (which might be, for instance, a bboard post or the like).

I also have a bunch of widgets from Greenpeace that folks might find interesting.  I've been hoping to find time to straighten them out for use with standard OpenACS and ad_form but if you're interested in playing more with form templating and widgets let me know and I can drop the GP widgets in your lap.

Also ... why don't we make your CSS'd lars-standard form template the OpenACS standard form template in HEAD and rename the current one "ugly-blue" ???

Anyone object to this?

Yes, I'd asked Jeff to look into standardizing some basic CSS stuff for OpenACS, in part motivated by the fact that Sloan had slightly forked some code in order to include Sloan-specific CSS stuff for SloanSpace.  Forking we and they want to avoid so we do want to regularize this stuff and get back to common sources.

Anyway ... Jeff would be an ideal person for you to talk to if you want your template CSS stuff checked for correctness.

Am I the only one for whom the great forms-latest breaks things?  I don't get a single element rendered -- only labels.  Don't get any errors either -- just blanks instead of text ans selects and only pictures (and no way to change values) for radio/check boxes.

It's as if formwidget fails to return the widget...

Roberto,

On 4.6-final (as found in download section of openacs.org/4).  I understand that your 'replacements' are against a 4.6, right?  Had it been HEAD (head it been had? ;^)), I would be less surprised, so to speak...