Re: Re: little extension of BLink

At 11:28 PM 10/29/2003 +0100, you wrote:
>Jacob Kjome <[email protected]> wrote:
>
> > However, these values are not
> > defined by the HTML4.01 spec that I can find.
>I would disagree, see:
>http://www.w3.org/TR/html401/present/frames.html#adef-target
>
>quote: "The target attribute may be set for elements that create links (A,
>LINK), image maps (AREA), and forms (FORM)."

Yes, I already mentioned those elements as taking a "target" 
attribute.  The point of my comment was about the specified values you want 
to add as constants.  Please point out where those are defined by the 
spec.  I don't think they are.

> > supported by the various browsers, but are not a standard.  In most
> > cases, this use of the target attribute should be replaced with
> > scripting anyway, especially in the case of "_blank" such as...
> >
> > <a href="foo.html" onclick="window.open(this.href);return
> > false;">Foo</a>
>Will not work when JavaScript is diabled, but target="_blank" always works
>(as JavaScript is still a security risk, it is legitim that users want to
>deacticate it).

Yes, exactly.  Users should not be forced to have a window opened.  They 
should have control over how they follow links.  If they don't want to open 
a new window, they shouldn't have to.  Disabling javascript is the way 
they'd do it.  They lose control over their web experience when 
target="_blank" is set, unless the browser provides specific preferential 
overrides for that (I think Mozilla might?).

> > Also note that the case for having get/setTarget() in BLink is a
> > questionable one.
>Why? Since the methods exist why shouln't use them?

I'm not suggesting I am going to take them away.  I'm just pointing out 
that they don't apply to the majority of the elements described in the 
Javadoc as suggested element to use BLink on.  Again, <input> and <button> 
don't take a "target" attribute according to the spec.

> >  Take note of the examples described (in the
> > Javadoc) for BLink's use; <a>, <input>, and <button>.
>In my opinion the problem is that BLink mixes up to much. Sorry if I say
>this, but the design is not the best. BLink should only be the counterpart
>of <a> (and maybe <area>) element, whereas BAction should be the counterpart
>of <input>, <form> and so on. As a consequence BLink should not extend
>BAction. But I don't want to start a new discussion. I can live with the
>status quo.

I think I opened up a can of worms.  See Christian's response.  BLink is 
there for components you want to set a BAction on, but also want to set the 
text on.  A solution already exists, however.  You can bind two separate 
components to the same view.  See an explanation at:
http://www.jguru.com/faq/view.jsp?EID=780950

Here's the relevant info..

<quote>
In addition, you can create your BInput and add a BAction to it like...

Binput binput = new BInput();
//set up BInput object whatever way you want here...
BAction baction = new BAction(new MyEvent());
baction.addScriptFunction("myValidationScript");
binput.addStepChild(baction);
return binput;

Both components will be bound to the same View.</quote>

The thing is, this didn't always exist in Barracuda.  I think I recall 
seeing Christian's commit message on this saying that it always should have 
been this way.  BLink will have to stick around for backward compatibility, 
but you can avoid it by using the technique above.  Sorry, I had forgotten 
about this when I replied previously.

> > than having a BComponent for every tag, but it does require diligence
> > on the developer's part to keep from generating illegal markup.
>It would be much better if the components functional specification wouln't
>allow this, for example setTarget() on <input>.

See above.  Furthermore, since get/setTarget() was added for developer 
flexibility to BLink, maybe another solution would suffice.  There does 
exist get/setAttr() methods in BComponent.  Maybe for stuff that is rarely 
used (like the "target" attribute), this would be the way to provide 
developer flexibility and avoid having getter and setter methods that don't 
apply to all elements the component might work on.

thoughts?

Jake