Re: 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" <[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 &quot;type&quot; attribute to
>>>> > &quot;submit&quot;. However,
>>>> > > > if the pre-existing type
>>>> > > >   *      is something other than &quot;submit&quot; or
>>>> > > > &quot;button&quot;,
>>>> > > > 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
>
>
>_______________________________________________
>Barracuda mailing list
>[email protected]
>http://barracudamvc.org/lists/listinfo/barracuda