Forum OpenACS Q&A: break out of a multiple tag?

I want to do the equivalent of

<multiple name=elements>
    <if @elements.id@ eq height_in>
      <break>
    </if>
     .... more processing

Is there any way to break out of looping through a multiple adp tag?

thanks:)

Of course if you have two templates for one multirow datasource, the condition to 'break' or 'continue' could be different. It should be possible for the designer to decide what rows, or what part of a multiple tag gets processed. I don't think this is currently possible. It sure would be nice.

Well actually what I'm doing is surely considered a major hack approach but I'm trying to get something done relatively quickly and painlessly here (getting some functionality up is more important now than elegance or generic reuse)...

What I am doing is creating a custom form resource/style (replacing standard-lars) that is paired with a specific form to handle pairing certain widgets into single table rows, etc.

I know I could do this with an adp using the formwidget/formerror/etc tags but then I would have to write a lot of html table code and include every formwidget and it would be long and tedious. But the generic form style is not gonna work either since it lays all widgets out one per table row. I need several to be paired in a single table row in some cases etc.

Maybe the correct way to be doing this is using something I ran across in the Templating System docs:

Starting with an autogenerated form template

In most cases, the simplest way for the designer to get started is to edit the autogenerated form template. This template will have all the necessary formwidget and formgroup tags.

But how do I get my autogenerated form template with the formwidget tags in it?!

Of course my form adp will still be long and any added widgets will need to be added by hand (the tcl and adp kept in sync) versus picked up in the style multiple name=elements loop for free.

It's frustrating how very close the standard form style comes to a perfect form rendering for almost no effort (formtemplate tag only). Then for just a tiny bit of customization from that for a single form, I have to write a load of formwidget | formerror | formgroup tags and my own HTML structure. Sigh. If only I had time/knowledge right now to add

1. more flexible form sections -- template::element::create accepts a section and if not defined yet, defines it. Any elements later added via template::element::create can be added to existing or new sections.
2. associating widgets so that when "linked" to each other, the standard template displays them in the same row, separated by their labels (if they have them).

This would rock! Then I'd be able to just use a single formtemplate tag for all my forms, even the huge ones generated from CR content_types:)

Alas I am a newbie and am struggling to implement a site with specific functionality in a decent time frame to prove we can use ACS for our purposes. So hacking a form style template seems the way to go now!

Which brings me back to: should I continue to hack the custom-per-form style templates (only for really large, CR-generated forms that have to be "per designer's specs" visually) or figure out how to get my autogenerated template containing the formwidget etc tags and hand tweak that?

sorry for the verbosity and tia:)

btw, I still think it'd be mighty handy to be able to break or continue from within a multiple tag;(

As you say you *always* want to write your queries to return the exact number of rows you're going to display, I totally agree.

But (knew this was coming!) in my case, I have selected just what I need out of the database and am only wanting to break or continue so that I can pair certain of these selected widgets together in my resulting HTML table. Not because I don't want them at all! If I could break or continue in my form style, I could have a special case for just a few widgets , thus pairing them in a table row. So there are gonna be special cases where it's not bad programming (and most languages have these commands). And regardless of language enforcements, etc, programmers will always come up with ways to do the wrong thing!

Anyway that aside, I can do what Tilmann suggested with the enclosing if to accomplish the effect I'm after. But it is much harder to see the logic this way. You have to find the end of the if which is just not visibly available, since the file is long. Easy to work around yes but just not as clear to anyone reading the code, IMO. But not to start a flame about minor issues, I'm quite happy with my end result:)

thanks again everyone

You may be on to something with the <group> tag! I can't find any attributes my form elements that I want to group share though. Is there a way I can add an attribute to my form elements? Then I could use <group> like is done for the section element in form styles.

Functionally, the 'sections' do put a separator in but the code to do it in the adp looks like <group column="section"> so I think it does this by adding an attribute to each element in a 'section.'

Thanks Jeff:) How did I miss that?! I have been looking at form style standards all day. Bad eyes? Not to mention that, looking at the sample you posted, it seems so obvious now. Sigh. Programming is sometimes not so easy on the ego!

I agree that the mixing of tcl code and templating tags to get something to work is a real abuse of the templating system. I can't think of a great reason to be using 'break' after considering Don's comments that the database/tcl code should be doing this job.

The code snip provided above seems to be using some obfuscated logic to put one element on the page. I think an extra bit of tcl code, or even a database query would be a cleaner way of getting what you want, and documenting what it is you are trying to do.

But maybe there are good reasons to use 'break'. What are they? Is 'continue' in the same boat? When would it be useful? What are the benefits over using 'if'?

I can share why I would like to use continue in my code (copied from above in this thread).

But (knew this was coming!) in my case, I have selected just what I need out of the database and am only wanting to break or continue so that I can pair certain of these selected widgets together in my resulting HTML table. Not because I don't want them at all! If I could break or continue in my form style, I could have a special case for just a few widgets , thus pairing them in a table row.

Anyway that aside, I can do what Tilmann suggested with the enclosing if to accomplish the effect I'm after. But it is much harder to see the logic this way. You have to find the end of the if which is just not visibly available, since the file is long. Easy to work around yes but just not as clear to anyone reading the code, IMO. But not to start a flame about minor issues, I'm quite happy with my end result:)

And actually, it turned out harder to debug too as the many if ... else's in my adp weren't paired up how I intended at first. It is just more clear to my eye to have a clear if... continue at the top of a loop instead of a not so immediately visible long if ... else (itself containing lots of if ... else conditions). Just my current situation;)