Mailing-List: contact commons-user-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Jakarta Commons Users List" <commons-user@jakarta.apache.org>
Received-SPF: pass (hermes.apache.org: domain of dion.gillard@gmail.com
 designates 64.233.170.192 as permitted sender)
Message-ID: <b22dff980409090608405e95a5@mail.gmail.com>
Date: Thu, 9 Sep 2004 23:08:02 +1000
From: Dion Gillard <dion.gillard@gmail.com>
Reply-To: Dion Gillard <dion.gillard@gmail.com>
To: Jakarta Commons Users List <commons-user@jakarta.apache.org>,
	S Schrem <sschrem@yahoo.com>
Subject: Re: Jelly and a new beta release
In-Reply-To: <b22dff980409071010192b89e8@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
References: <b22dff9804090621053deadfbf@mail.gmail.com>
	 <20040907162929.62853.qmail@web41413.mail.yahoo.com>
	 <b22dff980409071010192b89e8@mail.gmail.com>

I'm figuring by the silence and lack of issues raised in Jira that you
don't have the time / motivation to get back to us, or I did a bad job
explaining where we're at with Jelly.

I'll go ahead with the new beta release and we can always pick these
issues up for the next beta or release.


On Wed, 8 Sep 2004 03:10:31 +1000, Dion Gillard <dion.gillard@gmail.com> wrote:
> On Tue, 7 Sep 2004 09:29:29 -0700 (PDT), S Schrem <sschrem@yahoo.com> wrote:
> > [x] -1 - No, don't release! Here's why....
> >
> > I've been developing with Jelly b3 (in isolation) for
> > a while and have encountered and fixed various
> > problems. These problems occur in the core
> > implementation, core tags, Swing Tags, etc. I admit
> > that I have not checked to see if these have been
> > resolved in the CVS version.
> 
> That's a problem. If you're interested in getting things fixed in
> Jelly, file these as bug reports. We'll help work through them.
> 
> > Throughout
> >   Add to all occurences of code like:
> >       ClassLoader classLoader = this.getClass
> > ().getClassLoader () ;
> >     the following
> >       if (classLoader == null)
> >         {
> >         classLoader = ClassLoader.getSystemClassLoader
> > () ;
> >         }
> >     as some JVMs (e.g. IBM's J9) return null if
> > SystemClassLoader was used, in that case add explicit
> > call to get SystemClassLoader
> 
> Sounds reasonable. File an issue for this one.
> 
> > org.apache.commons.jelly.tags.core.ArgTag
> >     Register ArgTag's converters with
> > ConvertUtilsBean's singleton.
> >     Use converters registered with ConvertUtilsBean's
> > singleton.
> 
> Functionally what does this provide?
> 
> > org.apache.commons.jelly.tags.core.IncludeTag
> >     Fixed setExport
> 
> Done in CVS I think.
> 
> > org.apache.commons.jelly.JellyContext
> >     runScript(), inherit flag seemed to clobber
> > existing variables
> 
> File an issue, with a test case if you can.
> 
> > org.apache.commons.jelly.tags.core.UseBeanTag
> >     doTag(), remover 'var' attribute so it doesnt get
> > passed to setBeanProperties
> 
> Done in CVS.
> 
> >     Added a new 'ref' attribute which is
> > systematically set to the bean instance before tag
> > body is invoked.
> 
> Why? What does this give us?
> 
> > org.apache.commons.jelly.tags.swing.DialogTag
> > org.apache.commons.jelly.tags.swing.ComponentTag
> >     Refactored so that they share a new common parent
> > class AbstractComponentTag.
> >     Support layout constraints on contentPanes.
> 
> Layout constraints are fixed in CVS. Raise an issue for the other.
> 
> > org.apache.commons.jelly.tags.swing.ActionTag
> >     doTag(), call invokeBody immdediately if 'class'
> > or 'action' attribute is specified.
> 
> This may be fixed in CVS.
> 
> > org.apache.commons.jelly.tags.swing.FontTag
> >     Made it actually work.
> >     Now supports java.awt.font.TextAttribute.
> 
> I can't tell from this description whether it's fixed in CVS or not.
> 
> > org.apache.commons.jelly.tags.swing.GbcTag
> >     Made it Java 1.3 compatible.
> 
> Done in CVS.
> 
> > org.apache.commons.jelly.tags.swt.*
> >     Better parent widget management.
> >     Including:
> >     org.apache.commons.jelly.tags.swt.WidgetTag
> >         WidgetTag used to be a class, I have made it
> > an interface, DefaultWidgetTag is a copy of the
> > original WidgetTag.
> >         DefaultWidgetTag has better parent widget
> > management.
> 
> Pretty sure this isn't done in CVS. File an issue please.
> 
> >     org.apache.commons.jelly.tags.swt.OnEventTag
> 
> ???
> 
> > New Tags written:
> >     Improved bean creation and property getter and
> > setter tags that mirror 'core' tags.
> >     W3C DOM Document Tag
> >     TreeSelectionListenerTag
> >     TreeUIManagerTag
> >     more BorderTags
> >     ActionListenerTag, unlike, JellySwing ActionTag,
> > it adds itself to the immediate parent ComponentTag or
> > ArgTagParent if 'var' is not specified.
> >     JXPath tags (jXPathContext, jXPathIterator)
> >     FormAttachmentTag (swt/jface)
> 
> I dont want to add more functionality to the beta. New taglibs etc can
> wait till a release of the core.
> 
> > Requests:
> > My number one request, jettison BeanUtils. It is slow
> > but more importantly, does not indicate that a method
> > has not been found via introspection (at least as used
> > by Jelly).
> 
> Got a patch? File an issue for this one.
> 
> > Make Jelly Java 1.3 compatible.
> All except the Jetty taglib are 1.3 compatible. The core definitely is.
> 
> > Add instance and static member access to JEXL.
> Huh? Do you mean for fields? JEXL aint Jelly. JEXL has had a 1.0
> release, and new functionality can be added to 1.1. I don't see this
> as major for a Jelly beta release though. File an issue against JEXL
> for this one anyway.
> 
> > org.apache.commons.jelly.JellyContext
> >     Should discern between variables with a value of
> > null and variables that don't exits.
> 
> Done in CVS.
> 
> > org.apache.commons.jelly.tags.core.UseBeanTag
> >     Better management of bean storage. i.e. It is up
> > to the subclass (in processbean, after invokeBody) to
> > decide whether to store the bean or insert in in the
> > tah hierarchy.
> 
> Sounds like a reasonable enhancement. File an issue.
> 
> > More controversial, have bean based tags look for a
> > parent BeanSource with a bean of the approriate type
> > rather that a parent Tag of a specified Type.
> >     This is what I have done in a set of parallel
> > 'core' tags I have developed.
> Hmm...that's changing the scope of the 1.0 stream of Jelly I think.
> 
> > Again, I am not sure where Jelly b4 stands with
> > respect to the above, but should it be of interest, I
> > am willing to explain some of the above in more
> > detail.
> 
> Hopefully I've given you an idea of where it stands.
> 
> I don't see anything mentioned above as a *blocker* for releasing the
> beta though.
> 
> It would *really* help if you would work with us on Jelly and help
> make it better. You have some good ideas (and implementations by the
> sounds).
> 
> I also think we would benefit from getting a stable Jelly 1.0 out the
> door without functional rewrites and architectural changes. These
> things can be done once the code has been released and we have a
> better base to work from.
> 
> 
> --
> http://www.multitask.com.au/people/dion/
> 


-- 
http://www.multitask.com.au/people/dion/

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org