Fwd: RE: another release?

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
> > > >
> >