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

> My thought is that it would have something like this in the template.....
>
> <input type='checkbox" name="blah" value="1" id="blahcheckboxes">
> <input type='checkbox" name="blah" value="2" class="discardMe">
> <input type='checkbox" name="blah" value="3" class="discardMe">
> <input type='checkbox" name="blah" value="4" class="discardMe">

Ok, I see where you're going with this now.

> BTemplate directive.  Then you would build up a DefaultListModel
> and a DefaultSelectionModel, both of which you would provide to a
> BSelect component and then return that BSelect component to the
> view.  The result would be the creation of a new <input> element
> for each item in the list.  Currently, this is how it is displayed....

...

> Yep, but other components behave differently when bound to
> different elements so, I think using BSelect for things other
> than <select> elements is consistent with the way Barracuda's
> component model works.

Yeah, I DO agree with you here...there's nothing wrong with components
behaving differently depending on what they're bound too...that's kind of
the whole purpose. I'm not at all opposed to making BSelect work this way
for these components (provided it doesn't break anything, and from the looks
of it, it won't).

One thing that is still not clear to me is how you would handle the labels
that would need to go along with each checkbox? In the examples above, you
show only <input> components, but in reality, you'd need a way to set some
kind of label with each one of those, and at that point I think BSelect may
run out of steam...you might be able to use the key portion of ItemMap for
the text, and the value for the value, but how are you going to identify
what portion of the template is "label"? And how do you determine whether it
comes before or after the input component? And what if there's other
"non-label" text scattered in there as well? Just seems like there are a lot
of non-obvious technical details that would have to be ironed out.

In the end, it might make more sense to create an entirely different
component that isn't quite as low-level as either BSelect or
BToggleButton...

INteresting discussion... :-)

Christian
----------------------------------------------
Christian Cryder
Internet Architect, ATMReports.com
Project Chair, BarracudaMVC - http://barracudamvc.org
----------------------------------------------
"Coffee? I could quit anytime, just not today"


> -----Original Message-----
> From: [email protected]
> [mailto:[email protected]]On Behalf Of Jacob Kjome
> Sent: Wednesday, June 18, 2003 3:13 PM
> To: [email protected]
> Subject: Re: [Barracuda] RE: BSelect and <input> elements of type radio
> and checkbox?
>
>
> Hi Christian,
>
> See comments below...
>
> At 11:07 AM 6/18/2003 -0600, you wrote:
>
> Hi Jake,
>
> > I guess my question is, why doesn't the BSelect component work
> > when applied to <input> elements of type "radio" or "checkbox"?
>
> <snip>
>
>
> That said, I think the difficulty arises in that the "grouping" of the
> elements is loose, based solely on name, whereas with a <select>
> element you
> are dealing with a well defined structure that can be easily
> traversed/modified by the component rendering code. The biggest question I
> would have is "how are you going to find all the input elements with that
> particular name?" Maybe Elements.getElementByTagName(String tagName) would
> do the trick...but I wonder what kind of performance impact it would have?
> ie. would it require a complete traversal of the tree, or is the XMLC
> implementation smart enough to create references to it so it
> could return a
> NodeList without actually expanding everything else.
>
> Elements.getElementByTagName(String tagName) wouldn't do the
> trick on its own because it would only return elements with a
> particular tag name, not elements with a particular value for the
> "name" attribute.  You could could get a handle on the form
> element and do formElement.getElementsByTagName("input") to get
> all the input tags, but then you'd have to find those with a
> particular value for the "name" attribute and check whether they
> were of type "checkbox" or type "radio".  Anyway, I'm not sure
> that is necessary....
>
> My thought is that it would have something like this in the template.....
>
> <input type='checkbox" name="blah" value="1" id="blahcheckboxes">
> <input type='checkbox" name="blah" value="2" class="discardMe">
> <input type='checkbox" name="blah" value="3" class="discardMe">
> <input type='checkbox" name="blah" value="4" class="discardMe">
>
> Then you would bind to the node with id "blahcheckboxes" either
> using XMLC (or other DOM implementation) directly or use a
> BTemplate directive.  Then you would build up a DefaultListModel
> and a DefaultSelectionModel, both of which you would provide to a
> BSelect component and then return that BSelect component to the
> view.  The result would be the creation of a new <input> element
> for each item in the list.  Currently, this is how it is displayed....
>
> <input id="blahcheckboxes" name="blah" type="checkbox" value="1, 2, 3, 4">
>
> It should be...
>
> <input id="blahcheckboxes" name="blah" type="checkbox" value="1">
> <input name="blah" type="checkbox" value="2">
> <input name="blah" type="checkbox" value="3">
> <input name="blah" type="checkbox" value="4">
>
> Of course, the DefaultSelectionModel would have defined which of
> these <input> elements might be "checked".
>
>
>
> The other issue which would need to be considered is how you are going to
> handle those items in the DOM when they don't have a name (ie. in our
> mockups, we generally DON'T name the elements - we prefer to let the
> Barracuda components set the name). Not sure if that's a big issue or not,
> but its something that would have to be explored.
>
>
> No problem.  Just name the BSelect component just like you would
> for a <select>.  It would just give that same name to each and
> every <input> element generated.
>
>
> > If this does not seem like a good idea to you, how would you deal with,
> > say, a set of 10 checkboxes where the instructions are "check all that
> > apply to this question" or a set of 4 radio buttons where the
> instructions
> > are "select whichever applies to you".
>
> I would probably embed a Get_Data directive in each of them, like this:
> (Get_Data.FooModel.SomeOption.1, Get_Data.FooModel.SomeOption.2, etc).
> Notice the additional data parameters that I am adding on (.1, .2, etc).
>
> This allows me to implement the getItem(TemplateDirective td) method in my
> model, which can then do something like this:
>
>     String key = td.getKeyName();
>     if (key.equals("SomeOption")) {
>         String data = td.getData();
>         BToggleButton btg = new BToggleButton();
>         btg.setName("GroupName");
>         btg.setValue(...set the value based on the data...);
>         return btg;
>     } else {
>     ...
>
> What I am doing here is
> a) handling all the checkboxes in one spot within the code
> b) setting different values based on the data parameter in the directive
>
>
> Are you reading this Vijay?  Here's the answer to your question
> without going though some of the more complicated steps that you
> were having to do.  Yes, that is pretty easy.  But there should
> also be a pure component way to do this without depending on
> BTemplate to help out.  Being able to use a BSelect along with a
> DefaultListModel and a DefaultSelectionModel would enable this
> functionality.  So, I think it is something to look into implementing.
>
>
> So in my mind, this is probably still the way I'd do it even BSelect did
> work the way you've suggested (although I'm not diametrically opposed to
> adding that support there - I just always find myself thinking of
> BSelect as
> a component primarily aimed at manipulating <select> elements, rather than
> groups of check bozes or radio buttons)
>
>
> Yep, but other components behave differently when bound to
> different elements so, I think using BSelect for things other
> than <select> elements is consistent with the way Barracuda's
> component model works.
>
>
> Does that help at all? There are a lot of different ways to skin
> a cat, and
> this is certainly just one of them. But I think its pretty clean and
> straightforward...
>
>
> yes, definitely.  Your way is probably the way to go with the
> current Barracuda functionality.  Even if the new BSelect
> functionality is implemented, your way using BTemplate +
> BToggleButton may very well still be the better approach.  But I
> still think that <select> boxes and <input> elements of type
> "checkbox" and "radio" are so similar in behavior that they ought
> to be able to be treated in the same way by the user.  Obviously
> it is more complex for the component, but that is what the
> components are there for....to hide this complexity from the user.
>
>
> > You know, it would be really great if we created a FAQ where we
> > detail how one uses Barracuda components to deal with common
> > situations with form elements.
>
> I agree. I keep hoping to be able to sit down and really upgrade all the
> documentation, but I don't expect it to happen before this fall,
> given where
> we are in our project cylce right now. :-( It IS on my list of
> things to get
> to though, along with a sample project that would make it easy
> for people to
> get up and running quickly and provide some examples of everything.
>
>
> cool
>
>
> Comments and feedback welcome...
>
>
> yes, lets get some feedback going here.  I know there have been
> proposals in the past for writing FAQ stuff like this or even
> books on Barracuda.  The more information we can share, the
> better we will make life for all current and potential Barracuda
> users.  I still cringe when someone asks me whether they should
> use Barracuda or not and I have to make a decision on whether to
> recommend Barracuda based on whether I believe they can overcome
> the steep learning curve.  Better documentation would make this
> decision a no-brainer.  I'd love to recommend it to everyone
> without reservation.
>
> Jake
>
>
> Christian
> ----------------------------------------------
> Christian Cryder
> Internet Architect, ATMReports.com
> Project Chair, BarracudaMVC - http://barracudamvc.org
> ----------------------------------------------
> "Coffee? I could quit anytime, just not today"
>
>
> > -----Original Message-----
> > From: Jacob Kjome [mailto:[email protected]]
> > Sent: Wednesday, June 18, 2003 10:05 AM
> > To: Christian Cryder
> > Subject: BSelect and <input> elements of type radio and checkbox?
> >
> >
> >
> > Hi Christian,
> >
> > Can you comment on the thread "preselect a radio button based
> on a value"
> > which I commented on a couple of times on the list?
> >
> > http://barracudamvc.org/lists/archives/barracuda/2003-June/006485.html
> > http://barracudamvc.org/lists/archives/barracuda/2003-June/006486.html
> >
> > I guess my question is, why doesn't the BSelect component work
> > when applied
> > to <input> elements of type "radio" or "checkbox"?   Besides the
> > structural
> > difference between a <select> box with multiple nested option
> > elements and
> > <input> elements which are separate entities, they can act in almost
> > exactly the same way.  When said <input> elements are given the
> > same value
> > for the "name" attribute, they work together in almost exactly
> > the same way
> > as a <select> box.  The benefit of this would be to allow for defining a
> > single component to deal with creating a list of <input> elements
> > and would
> > also allow for using the DefaultListSelectionModel for defining which
> > elements are pre-selected.
> >
> > If this does not seem like a good idea to you, how would you deal with,
> > say, a set of 10 checkboxes where the instructions are "check all that
> > apply to this question" or a set of 4 radio buttons where the
> > instructions
> > are "select whichever applies to you".  The checkbox case is, for all
> > intents and purposes, exactly like a <select> box with multiple
> > selections
> > enabled and the radio button case is just like the a single selection
> > <select> box.  BToggleButton really doesn't work for this, does it?  You
> > have to return that to each individual <input> element you want to make
> > checked or not checked.  That isn't the list behavior that is required.
> >
> > You know, it would be really great if we created a FAQ where we
> > detail how
> > one uses Barracuda components to deal with common situations with form
> > elements.
> >
> > Jake
> >
>
> _______________________________________________
> Barracuda mailing list
> [email protected]
> http://barracudamvc.org/lists/listinfo/barracuda