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

At 06:29 PM 6/19/2003 +0200, you wrote:
>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.

Ah yes, absolute positioning used on main elements of a page is a big no-no 
and is very abused by css designers that don't know what they are doing.  I 
only ever use absolute positioning within the context of a relatively 
positioned element.  For instance, within a small defined area of a box, I 
might place text in the upper right, but this in no way affects the layout 
of the rest of the page and the box that the absolutely positioned element 
exists in can be moved anywhere and the absolutely positioned element will 
follow it wherever it goes.

An example can be seen here (use Mozilla or a recent opera for best 
results.  IE is just plain wrong, but doesn't mess up too bad):
http://www.visi.com/~hoju/barracuda/barracuda.html

Each text entry in the box up at the top ("Event Model", "Component Model", 
"Form Mapping Model") is absolutely positioned, but only within the context 
of its container (the outer box).  If you expand and contract the browser 
horizontally, you can see that box flow naturally with the page.

As far as layout independent of the number of entries, why wouldn't this work?

<div>
<input> <label>
</div>
...
...

You can always defined a margins on the <div> and/or <input> so that the 
<label> text and any other <input>+<label> would be properly spaced.  Of 
course, that particular example would be the case if the developer gave the 
component a structure value which defined entries to be on top of each 
other rather than horizontal or a certain number on a line and then 
wrapping.  So, the structure part is defined in the component and any 
layout after that is defined by CSS (colors, margins, etc...).


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

That makes more sense now and I really like the idea.  It really frees the 
developer from dealing with interface specifics.  Do you have time to look 
into implementing BEL for BTemplate?  I think it would be an excellent 
addition.

Jake


>_______________________________________________
>Barracuda mailing list
>[email protected]
>http://barracudamvc.org/lists/listinfo/barracuda