Re: Nothing happens when Enter button is clicked.
Stephen <[email protected]>
| Newsgroups | gmane.comp.java.enhydra.barracuda.general |
|---|---|
| Message-ID | <[email protected]> |
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. 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. 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. It would be good to get this problem fixed - if you need some more details, sing out. 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" <[email protected]> >>> To: "Jacob Kjome" <[email protected]> >>> 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:[email protected]] >>> > 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:[email protected]] >>> > > > 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 >> [email protected] >> http://barracudamvc.org/lists/listinfo/barracuda > > > _______________________________________________ > Barracuda mailing list > [email protected] > http://barracudamvc.org/lists/listinfo/barracuda