On Tue, 7 Sep 2004 09:29:29 -0700 (PDT), S Schrem <[EMAIL PROTECTED]> 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/
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
