Pfffiou... that's not a small buglist.

Dear S. Schrem,

I think releasing a beta would actually have prevented most of these bugs you encounter to have occurred as you would have taken the beta. I think we should consider your report as a +1!

Anyways... My [+1] btw.

Many of the bugs you seem to be reporting have been (maybe partially) tackled and it would be great to get working together...
Using a big of scripting wizardy (or maybe only a drop or rsync), it sounds easy to to update your source-tree, sadly most probably with conflicts, so that you could submit patches...


Btw, BeanUtils has had a refactoring started since jelly-beta-3 release (by Robert Burrell Donkin) and I know we could take advantage of it into Jelly...

paul


Le 7 sept. 04, � 19:10, Dion Gillard a �crit :

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]



---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Reply via email to