[prev in list] [next in list] [prev in thread] [next in thread]
List: barracuda
Subject: RE: [Barracuda] Re: Nothing happens when Enter button is
From: Jacob Kjome <hoju () visi ! com>
Date: 2003-07-31 23:52:44
[Download RAW message or body]
Hi Christian and Stephen,
At 04:17 PM 7/31/2003 -0600, you wrote:
>Just a couple of additional comments following on Jake's response here...
>
>a) I think BarracudaDiskRack was designed to illustrate the back button
>disabling stuff (which as Jake noted is broken in some versions of IE and
>most recent versions of NN/Mozilla)
Just to clarify. IE5, specifically, is truly broken in the true sense of
the word. It can't handle the javascript. It pops up a scripting error
dialog so the IFrame redirect is unable to actually succeed. I'm not sure
what the deal with Netscape4 is. It works sometimes and not
others. Strange stuff. Now, in Mozilla's case, form submission always
succeeds. What is broken in Mozilla is that the back button accumulates
history when it shouldn't. This really isn't the biggest problem in the
world since that app still works just fine. It just isn't all that
pleasing when the purpose the script is used for is rendered
useless. However, using back button disabling on Mozilla is still
functional and should not be considered "broken" in the sense that it is
broken in IE5.0 and Netscape4 (partially).
>b) Barracuda rendering for non-javascript browsers is totally doable - we
>just need input on what you want the renderers to do. So what we need from
>you is an explanation of "here's what the markup is getting rendered as" and
>"here's what I think it should be for such and such environment". THese
>changes are very easy to make - we just need feedback on what you want to
>see.
My latest additions to HTMLActionRenderer (see other email) should go some
way toward this. However, keep in mind that when you bind an action to a
component, that is the action the whole form is going to take, even if
there are multiple buttons. And the last button/submit that is defined in
the page is going to get the final action. So, for multiple button
interfaces where each button does a different thing and javascript is
disabled, either don't set an action to particular components and do this
stuff manually, or set the action on a component and only expect that one
component's submission logic to work. This really is where javascript is
immensely useful. This is why I say that BarracudaDiscRack is made with
the intention of requiring javascript to work. There are too many separate
things that need to happen and we've made the choice of setting BAction's
on each of these components. Disabling javascript will disable most of it
functionality in its current state. I'm not sure how this would be worked
around without rethinking assumptions about how BarracudaDiscRack's should
be set up. Thoughts?
Oh, and Stephen, I just tested both contrib apps. They both work fine
using the <Enter> key. Just click on a text box, radio button, or checkbox
and hit <Enter>. The form will be submitted. I tried this in both the
latest Mozilla and IE6. Things work fine. What exactly are you seeing not
work? Note that if you have focus on select boxes or textarea's, the
browser doesn't treat the <Enter> key as an even that would submit the
form. That is just the nature of select boxes and textareas. Note that I
compiled under JDK1.3.1_08 using Jikes and ran on Tomcat-4.1.24 under
j2sdk1.4.2. It all works great!
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: barracuda-admin@barracudamvc.org
> > [mailto:barracuda-admin@barracudamvc.org]On Behalf Of Jacob Kjome
> > Sent: Wednesday, July 30, 2003 8:55 PM
> > To: barracuda@barracudamvc.org
> > Subject: Re: [Barracuda] Re: Nothing happens when Enter button is
> > clicked.
> >
> >
> > Hi Stephen,
> >
> > At 08:50 AM 7/31/2003 +1200, you wrote:
> > >Hi Jacob,
> > >
> > >Re clicking on buttons and nothing happening. My first Barracuda
> > app (and
> > >only Barracuda app so far) is based on BarracudaDiscRack and I've found
> > >that if I use konqueror (the "default" browser in the KDE windowing
> > >environment on linux), or "lynx" (text based browser) or "links"
> > (another
> > >text based browser) then clicking on buttons doesn't elicit a response.
> >
> > I can understand the text-based browsers not working. They
> > probably don't
> > support much (or any) javascript or dom programming and since
> > BarracudaDiscRack is set to disable the back button, there is a lot of
> > javascript and dom stuff going on. In this case, the best thing to do
> > would be to disable the back button disabling and probably use
> > "NEVER_SCRIPT" to cause the HTMLActionRenderer not to use javascript
> > listeners for form submits. However, BarracuaDiscRack is really
> > set up in
> > a way that it requires scripting or it just isn't going to work. This
> > could be re-thought, but it should work on the major browsers.
> >
> > I'm slightly surprised Konquerer isn't working, although there is some
> > browser feature detection in the back button disabling that might be
> > messing things up. Do you have a script debugger in Konquerer
> > where errors
> > are showing up? I'd be interested in seeing what they are.
> >
> > > Links and lynx are very useful for remote support on servers where the
> > > client has limited bandwidth. I've found I have to use Explorer or
> > > Mozilla/Netscape.
> >
> > Yes, apps should be able to work in environments where scripting isn't
> > available....that is, unless it has been explicitly stated that the app
> > requires a client-side-scripting-capable browser. We should
> > probably state
> > that in BarracudaDiscRack and probably rethink the HTMLActionRenderer to
> > make it more friendly to non-javacript capable browsers. I've done a
> > little of that and plan to make one more change (which I mentioned way
> > below) which should make things even friendlier. However, it is by no
> > means perfect and any input on improving it is welcome.
> >
> > >Also, I've been unable to run the contrib apps by Diez using
> > Barracuda 1.2
> > >since nothing happens when the Enter button is pressed. (even
> > using recent
> > >versions of Mozilla as the client). I was able to run the
> > contrib apps in
> > >previous CVS versions of Barracuda (JVM may have been 1.3 back then).
> > >Barracuda is running on a machine with RedHat 8.0 and Sun's JVM 1.4.1_01.
> >
> > Hmm... not sure why that would be? It works for me. I'll test again
> > tonight on IE6 and the latest MozillaFirebird (which shares the same
> > rendering engine as Mozilla, so it should be equivalent).
> >
> > >It would be good to get this problem fixed - if you need some more
> > >details, sing out.
> >
> > Certainly provide the details I've asked for above. I don't think
> > BarracudaDiscRack will work without heavy scripting without some
> > relatively
> > major rework, though, so Lynx and Links are out, but Konquerer should
> > work. We'll just have to see why it isn't working. Maybe you
> > can test out
> > the following URL and let me know if that works for you....
> > http://www.ashleyit.com/rs/jsrs/select/php/select.php
> >
> > If it doesn't work, then BarracudaDiscRack certainly won't work
> > because the
> > back button disabling is based on jsrs remote scripting.
> >
> > Jake
> >
> > >Cheers
> > >Stephen
> > >
> > >
> > >
> > >Jacob Kjome wrote:
> > >
> > >>Hmm... I was hoping for at least one comment on this (Christian?).
> > >>
> > >>Anyway, other than the HTMLActionRenderer stuff below, I've locally
> > >>modified the ParamGateway.java and the ClientServerHTTPLib.js to make
> > >>them a bit more simplified. That is, I've reverted some of my previous
> > >>changes when I was a bit overzealous on the standards stuff (doing
> > >>everything in XHTML) when that doesn't really matter. Based on initial
> > >>testing, I think the way I have it is faster. I'll probably
> > commit this
> > >>shortly so people can check for themselves. Of course, this
> > only affects
> > >>anything If you use back-button disabling. I also modifed
> > >>ClientServerHTTPLib.js to be as close as possible to the original
> > >>jsrsClient.js to make it much easier to see exactly what modifications
> > >>were done for Barracuda's version.
> > >>
> > >>BTW, can anyone do some basic testing to see if they find that
> > Netscape4
> > >>works with back button disabling? Actually, that it works with
> > >>BarracudaDiscRack. What I am seeing is that it works on a
> > couple of the
> > >>screens, but as soon as you get to the screen to edit a
> > particular album
> > >>or the registration screen, when you click the buttons nothing
> > >>happens. Not sure what is going on there. I see that with an
> > without my
> > >>new changes. Additionally, IE5.0 seems to bug out on the jsrs stuff
> > >>where javascript errors are reported. Everything works fine in 5.5 and
> > >>6.0 (not sure about 5.0.1?). Anyway, if someone can confirm this stuff
> > >>and/or figure out why things aren't working properly on Netscape4 and
> > >>IE5, let me know. Weird stuff! Oh, and like I've said before, back
> > >>button disabling is broken in recent Mozilla builds including
> > the latest
> > >>release. I reported the issue at
> > >>http://bugzilla.mozilla.org/show_bug.cgi?id=208835 .
> > >>
> > >>Jake
> > >>
> > >>At 10:48 AM 7/25/2003 -0500, you wrote:
> > >>
> > >>>Forwarding to the list for all to view.
> > >>>
> > >>>Jake
> > >>>
> > >>>>Posted-Date: Fri, 25 Jul 2003 10:37:06 -0500 (CDT)
> > >>>>From: "Christian Cryder" <christianc@granitepeaks.com>
> > >>>>To: "Jacob Kjome" <hoju@visi.com>
> > >>>>Subject: RE: another release?
> > >>>>Date: Fri, 25 Jul 2003 09:33:56 -0600
> > >>>>
> > >>>>Can you send this on to the list, and then I'll respond
> > there? I want to
> > >>>>make sure we give the community a chance to comment on this...
> > >>>>
> > >>>>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:hoju@visi.com]
> > >>>> > Sent: Friday, July 25, 2003 9:19 AM
> > >>>> > To: Christian Cryder
> > >>>> > Subject: RE: another release?
> > >>>> >
> > >>>> >
> > >>>> > At 08:56 AM 7/25/2003 -0600, you wrote:
> > >>>> > >Hi Jake,
> > >>>> > >
> > >>>> > >I'm all for making a new release whenever you're ready - I don't
> > >>>> have any
> > >>>> > >pending changes that would hold anything up. 1.2.5 is fine for a
> > >>>> version
> > >>>> > >number. Regarding teh changes to HTMLActionRenderer, I'm
> > cool with what
> > >>>> > >you've done...ie. I don't see any reason to hold things
> > up based on any
> > >>>> > >uncertainties there - if we decide in the future we need to
> > >>>> > change them, we
> > >>>> > >can do so then.
> > >>>> >
> > >>>> > Do you have an opinion, though, on whether we should throw an
> > >>>> > exception at
> > >>>> > all? That is a simple change that won't take much time at all to
> > >>>> do. We
> > >>>> > just need to make a decision on it. I'd like it to be made
> > >>>> > before release,
> > >>>> > if possible. For instance, for the HTMLInputElement, we do this...
> > >>>> >
> > >>>> > if (!"submit".equalsIgnoreCase(el.getType())) {
> > >>>> > if ("button".equalsIgnoreCase(el.getType())) {
> > >>>> > //modify the <input> type to make this form
> > >>>> > submitable in
> > >>>> > //a non-javascript environment.
> > >>>> > el.setAttribute("type", "submit");
> > >>>> > } else {
> > >>>> > //whoops, it's an <input> element of
> > neither type
> > >>>> > "submit",
> > >>>> > //nor type "button". Probably overstepping
> > >>>> bounds in
> > >>>> > //modifying the type attribute here, so
> > >>>> > throw exception
> > >>>> > //instead.
> > >>>> > String errmsg = "Cannot render Input action
> > >>>> > listener;
> > >>>> > input type is not 'submit': "+el;
> > >>>> > logger.warn(errmsg);
> > >>>> > throw new NoSuitableRendererException(errmsg);
> > >>>> > }
> > >>>> > }
> > >>>> >
> > >>>> > Modifying the button type from "button" to "submit" is unlikely to
> > >>>> affect
> > >>>> > someone's custom javascript code (although depending on
> > how they coded
> > >>>> > things, it still could be a problem but, again, unlikely) but
> > >>>> > when we find
> > >>>> > it isn't a button, I'm not sure we should then go ahead
> > and throw an
> > >>>> > exception. Note that with the modifying of the "button"
> > to "submit", we
> > >>>> > are actually avoiding an exception that would have
> > happened before I
> > >>>> > modified the code. So, we are still better off than before, but I
> > >>>> wonder
> > >>>> > if we should throw an exception at all? Maybe just log the
> > >>>> > warning and let
> > >>>> > the developer worry about how the user is going to be able
> > to submit the
> > >>>> > form. Their custom script might just do the job, but we are
> > >>>> > interfering by
> > >>>> > blowing up their application before their script has a chance to
> > >>>> > do its work.
> > >>>> >
> > >>>> > This would simply be a matter of commenting out the "throw" line.
> > >>>>That's
> > >>>> > it. So, are you +1 or -1 for that? Is there anything
> > that I haven't
> > >>>> > thought of that might be a problem if we don't throw an exception
> > >>>> > here? Note that this decision will have more effect on the
> > >>>> > HTMLInputElement and HTMLButtonElement, but still affects the other
> > >>>> > elements. Should we ever throw an exception based on whether
> > >>>> > scripting is
> > >>>> > disabled? Does it help anything? I can certainly see cases
> > >>>> > where it hurts
> > >>>> > things. Maybe simply logging a warning and not throwing
> > an exception is
> > >>>> > the most prudent thing to do in all these cases?
> > >>>> >
> > >>>> >
> > >>>> > >So I guess what I'm saying is +1 on rolling a new release as
> > >>>> > soon as XMLC is
> > >>>> > >ready...
> > >>>> >
> > >>>> > Cool. Version 1.2.5 it is. It shall be done :-)
> > >>>> >
> > >>>> > 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:hoju@visi.com]
> > >>>> > > > Sent: Thursday, July 24, 2003 11:57 AM
> > >>>> > > > To: Christian Cryder
> > >>>> > > > Subject: another release?
> > >>>> > > >
> > >>>> > > >
> > >>>> > > > Hi Christian,
> > >>>> > > >
> > >>>> > > > When XMLC-2.2 is finalized (which should be any time now) I'd
> > >>>> > like to get
> > >>>> > > > it into Barracuda and then make a new release of Barracuda to
> > >>>> > provide to
> > >>>> > > > the Enhydra guys for the 5.1 release of Enhydra. The question
> > >>>> is, is
> > >>>> > > > Barracuda ready? I think it is, but are there any things you
> > >>>> > want to get
> > >>>> > > > into Barracuda before an upcoming release? What
> > should the next
> > >>>> > > > Barracuda
> > >>>> > > > release be called? I was thinking either 1.2.1 or 1.2.5.
> > >>>> > I'd say 1.2.5
> > >>>> > > > since there are a number or feature additions such as
> > >>>> > deferred parsing
> > >>>> > > > support in DOMFactory/DOMLoader, enhanced capabilities of the
> > >>>> > > > DefaultApplicationAssember (which have been actually
> > superceded
> > >>>> by the
> > >>>> > > > changes to the ObjectRepositoryAssembler), and enhanced
> > >>>> > > > ObjectRepositoryAssembler, and enhanced ObjectRepository
> > >>>> > (SoftHashMap), a
> > >>>> > > > more generic ApplicationGateway and a way to configure things
> > >>>> > more easily
> > >>>> > > > with A_Classes, enhanced HTMLActionRenderer, etc...
> > >>>> > > >
> > >>>> > > > BTW, with HTMLActionRenderer, I modified things like this...
> > >>>> > > >
> > >>>> > > > "Instead of throwing an exception, modify these [button or
> > >>>> > input of type
> > >>>> > > > button] elements by setting
> > >>>> > > > * their "type" attribute to
> > >>>> > "submit". However,
> > >>>> > > > if the pre-existing type
> > >>>> > > > * is something other than "submit" or
> > >>>> > > > "button",
> > >>>> > > > then throw the exception,
> > >>>> > > > * otherwise we'd be overstepping our bounds.:
> > >>>> > > >
> > >>>> > > > This was an improvement over previous behavior to
> > allow for apps
> > >>>> > > > to work in
> > >>>> > > > a non-javascript environment. However, I'm somewhat rethinking
> > >>>> > > > whether we
> > >>>> > > > should throw an exception at all and maybe let the
> > developer deal
> > >>>> > > > with the
> > >>>> > > > consequences of choosing a render strategy of intentionally
> > >>>> disabling
> > >>>> > > > scripting. The specific case that was brought up on the list
> > >>>> led to a
> > >>>> > > > situation where the developer wanted to do his own scripting
> > >>>> > on a client
> > >>>> > > > that supports it and not have Barracuda do any scripting, but
> > >>>> > > > Barracuda was
> > >>>> > > > throwing exceptions because input's and buttons weren't of
> > >>>> > type button or
> > >>>> > > > submit. What do you think? For more info, see the
> > >>>> > > > HTMLActionRenderer.manipulateActionElement() for
> > >>>> HTMLInputElement and
> > >>>> > > > HTMLButtonElement.
> > >>>> > > >
> > >>>> > > > Jake
> > >>>> > > >
> > >>>> >
> > >>>
> > >>>
> > >>>_______________________________________________
> > >>>Barracuda mailing list
> > >>>Barracuda@barracudamvc.org
> > >>>http://barracudamvc.org/lists/listinfo/barracuda
> > >>
> > >>
> > >>_______________________________________________
> > >>Barracuda mailing list
> > >>Barracuda@barracudamvc.org
> > >>http://barracudamvc.org/lists/listinfo/barracuda
> > >
> > >
> > >_______________________________________________
> > >Barracuda mailing list
> > >Barracuda@barracudamvc.org
> > >http://barracudamvc.org/lists/listinfo/barracuda
> >
> > _______________________________________________
> > Barracuda mailing list
> > Barracuda@barracudamvc.org
> > http://barracudamvc.org/lists/listinfo/barracuda
>
>_______________________________________________
>Barracuda mailing list
>Barracuda@barracudamvc.org
>http://barracudamvc.org/lists/listinfo/barracuda
_______________________________________________
Barracuda mailing list
Barracuda@barracudamvc.org
http://barracudamvc.org/lists/listinfo/barracuda
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic