Re: RE: BSelect and <input> elements of type radio and checkbox?

Hi,

Jacob Kjome wrote:

> Not entirely sure I agree with you here.  BTable wasn't so useful 
> since it didn't support all table features and did some annoying 
> things....that is, until Denny Chambers went through the work of 
> improving it.  Note that tables should never, ever, be used for 
> layout, period, end of story.  Tables are meant to hold tabular data, 
> and that is it.  Many might say that isn't possible, but that argument 
> doesn't hold up when you look at the design of many of the table-less 
> sites around today.  To that end, BTable does its job quite nicely.  
> It isn't meant as a replacement for BTemplate, but certainly serves as 
> one when you have a bunch of tabular data and you really don't need an 
> iterative model except for to display a bunch of pure data in a 
> tabular way.

I fully agree with you that tables _shouldn't_ be used for layout 
purposes. However, the real world sometimes doesn't give a dime on 
"should" ;)

But what I meant anyhow is that even rendering tabular data can mean a 
lot of different layout options - which I always rendered using BTemplates.

> In regards to a BSelect type of list-of-input-elements component, you 
> might be right.  I haven't explored this enough to rule that out.  
> however, there are usually some very basic things done with lists of 
> <input> elements of type radio or checkbox.  They usually have text to 
> the right or left of them to provide a label and they are displayed 
> all on the same line, on alternating lines, or on top of each other.  
> Dealing with the label is easy since a Map of values and their 
> descriptions could be provided to the component.  Then, there could be 
> a method saying whether to write the descriptions (in the labels) to 
> the left or right of the elements.  For layout, we could provide a 
> method to specify that and have valid options be one of the 3 I 
> specified with one of them being a default if not given.  Beyond that, 
> CSS can provide all the layout specifics.  I really don't see where 
> I'd need to have

As I said - very basic layouts can be supported. But I generally use 
table cells for that. I have very limited CSS expirience, so maybe you 
can come up with an example for me how you align a few rows of 
checkboxes and their labels like this table would do it:

<table>
<tr><td><input ...></td><td>label</td></tr>
...
</table>

If it is possible using CSS, is it possible in a way that is 
indepenedend of the number of entries? What I mean by this is that 
absolute coordinates on <div> elements aren't very helpful, as you 
explicitely have to calculate them for every checkbox. But I'm just 
speculating here, better you give me an example.

>>
>> From what I have seen so far, I personally think barracudas BTemplate 
>> is a very powerful and flexible mechanism. I currently have to work 
>> with struts, and I have to say that they don't offer anything similar 
>> to BTEmplate. The only thing I would like to see is a small 
>> expression-language inside of Template-directives that could 
>> calculate and filter some values. I think of stuff like this (BEL is 
>> "BarracudaExpressionLanguage"):
>>
>> <div class="Dir::BEL-{size('searchResultModel') > 0}">
>>   <!-- render the results -->
>>   <table>...
>>
>>   </table>
>> </div>
>> <div class="Dir::BEL-{size('searchResultModel') == 0}">
>>   <!-- render the "No results message"-->
>>   Sorry pal, nothing found.
>> </div>
>>
>> This would eliminate the need of some purely layout-driven template 
>> model items.
>
>
> Can you expound on what you mean by "purely layout-driven template 
> model items?  I guess just a quick example of what the above would 
> replace that makes BEL so much cleaner.


The complementary example not using BEL would look like this:

<div class="Dir::Get_Data.searchResultModel.hasResults">
  <!-- render the results -->
  <table>...

  </table>
</div>
<div class="Dir::Get_Data.searchResultModel.hasNoResults">
  <!-- render the "No results message"-->
  Sorry pal, nothing found.
</div>

So in the model you have to do something like this:

public Object getItem(String key) {
  if("hasResults".equals(key)) {
     BComponent bc = new BComponent();
     bc.setVisible(theBackingList.size() > 0);
      return bc;
  } else   if("hasNoResults".equals(key)) {
     BComponent bc = new BComponent();
     bc.setVisible(theBackingList.size() == 0);
      return bc;
  }
}
We use this sort of constructs all the time. With BEL, you could define 
such values only if they are needed. Other examples would be things like 
the number of results, which currently also are stored as explicit value 
in the Model. The point is that right now the developer has to have more 
or less all possible layouts for the data she provides in the model  in 
her mind so the html can be written accordingly. With BEL at least some 
of this layout-logic is pushed to the layout people (and thus hopefully 
far away from me :))

Diez