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

Hi Diez,

At 11:27 AM 6/19/2003 +0200, you wrote:
>Hi,
>
>>Yes, using the IterativeModel along with BTemplate.  My idea to use 
>>BSelect would allow for list-type behavior with radio buttons and 
>>checkboxes in the same way as select boxes work using only a single 
>>component and no helpers such as BTemplate and IterativeModel.  The logic 
>>is essentially the same.  But as Christian has pointed out, the details 
>>in rendering need to be worked out and this may require a separate 
>>component that, maybe, extends BSelect and provides behavior and features 
>>specific to <input> elements of type radio and checkbox (such as adding 
>>labels or dealing with other surrounding text).
>
>Hmm. I personally think that except from a very basic layout style, you 
>won't come far here. To me, this looks like BTable and what some folks 
>wanted to do with it - make it a general purpose table renderer for 
>different layouts and stuff, fetching information from the bound dom. 
>Never heard of that again.

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.

>This will effectively duplicate the behaviour of BTemplate. You'll end up 
>having specially marked nodes to put your text into. And you can never 
>come up with so much configurability as webdesigners come up with crazy 
>ideas how the want things layouted.

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 "specially marked nodes".  The only node 
that you would deal with is a single <input> element and might be dealt 
with like this in the mockup...

<label for="mycheckboxlist" class="discardMe">First Checkbox</label>
<input type="checkbox" name="blah" id="mycheckboxlist">
<label for="mycheckboxlist-2" class="discardMe">Second Checkbox</label>
<input type="checkbox" class="discardMe" name="blah" id="mycheckboxlist-2">
<label for="mycheckboxlist-3" class="discardMe">Third Checkbox</label>
<input type="checkbox" class="discardMe" name="blah" id="mycheckboxlist-3">

So, the only thing left over after an XMLC compile would actually be the 
<input> element that wasn't discarded and we would bind the list of 
checkboxes to that node...effectively re-writing that node since it really 
is only mockup data and add in any labels and new <input> elements to 
account for each list item.

Again, this doesn't replace BTemplate.  It simply allows you to deal with 
list data without requiring an Iterative model, especially when this might 
be the only reason you were using an Iterative model.


>>I've used your idea's of child models in the past for my projects and 
>>they seem to be a very necessary feature.  I think this is a good idea 
>>and shouldn't break existing code using BTemplate.  I'd like to see more 
>>information about it.  Maybe you can add the functionality and modify 
>>your existing contrib app to utilize this and show how it makes the code 
>>cleaner and makes adding child models more convenient and standardized. 
>>We can always pull it out if it doesn't seem to be the right thing to do.
>
>Ok, I'll do it.

cool.  Can't wait to see it.

>>I think we really need to concentrate on making the component model and 
>>especially BTemplate as easy and flexible to use as other templating 
>>models.  The event model is, hands down, better than anything else I've 
>>seen out there, but the component model can make it tough to do some 
>>complex things.  Whether this is just a matter of the learning curve or 
>>real limitations in the component model is up for debate (and documentation).
>
> 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.


>And resource-bundle based localization as immediate support in BText could 
>be a nice idea.

Yes, that would be cool.  As useful as compile-time localization is, it 
doesn't deal with runtime text.

>I agree of course that the lack of documentation _is_ a problem.
>
>Regards,
>
>Diez

Jake

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