Re: [jelly] tag for accessing static fields

["Daniel F. Savarese" <df...@savarese.org>]

In message <01...@activemath.org>, Paul Libbrech
t writes:
>I keep believing, however, that such a thing should be done by Jexl or 
>something else... it makes no sense to need this getStatic, at least 
>compared to Java.

I agree.  After I shot off my email I was going to reply to it and add
"maybe the right thing to do is enhance Jexl?".  When trying to access
static constants, the first thing I did was try to use the Jexl expression
language, figuring it must support such a thing.  After the error messages,
finding the Jelly invokeStatic tag, and digging through what documentation
I could find, it became clear I couldn't do it with Jexl.  I suppose since
Jelly supports multiple expression languages, it may be possible to swap in
another language to do that sort of thing.

I'm new to Jelly and don't know what the preferred approach is to do certain
things in a manner consistent with its design.  My gut feeling is that the
expression language should support features like invokeStatic or my proposed
getStatic, but when I see all of the Jelly flow control tags I figure I do not
yet understand the intended relationship between Jelly and Jexl or Jelly and
another expression language.  When does some feature belong in Jelly (or
user-implemented Jelly tag), when does it belong in the expression language,
when does it belong in a user-implemented JavaBean?  As best I can tell,
the expression language isn't supposed to do flow control, just evaluate
embedded expressions.  Based on that Jexl seems like the right place to
add static field access.  Yet expression manipulation is limited to JavaBean
properties (otherwise there would be no need for the invoke tag), which makes
it seem like Jexl isn't the right place.  If static field access were to
be added, why not arbitrary method invocation?  Anyway, that's a long-winded
way of explaining why I do not yet understand the design guidelines that help
dictate what should go where.

>Yet an alternative way for this was partially done in 
>GridBagConstraintBean: namely it has been tried to have custom 
>converters that would decode such (expected) constants into an integer.

The downside to doing that would seem to be that you may have to write a
converter for every bean?  Or is there a way to do it once for all of
them, where by default Jelly would try to match unknown properties against
constants?  I suppose that's where your mention of BeanUtils comes in.  But
with a converter, am I correct in assuming you couldn't throw in a constant
defined in a different class?

>Feel free to go ahead but let's start this discussion on the usages of 
>converters in jelly-attributes since it seems BeanUtils folks are 
>"eagerly expecting users" ;-->

I think I'll hold off on doing anything until the discussion runs its
course.  So far, it seems there's agreement that it's useful to be able to
access static class fields, but there's more than one way to do it.
Before shoehorning getStatic into jelly core, it may be best to explore
the alternatives.  Another possibility is to overload invokeStatic
so as to avoid adding another tag and have it behave like getStatic
if a "field" attribute is defined and like invokeStatic when a
"method" attribute is defined and throw an exception when both are
defined.  But that's probably overcomplicating things and not in
the spirit of how things are done in Jelly.  Otherwise, there would
have been no invokeStatic tag and the invoke tag could have been made
to behave like invokeStatic if a static="true" attribute were present,
expecting the "on" attribute to define a class name in that case.

BTW, I'm so glad you mentioned BeanUtils and converters.  I have a need
right now to take a bunch of beans (remote MBeans actually) and dynamically
create Swing components that let you change bean properties and invoke
methods.  I was fearing (because of the time involved) having to write a
bunch of code to convert strings into method parameters.  BeanUtils is
exactly what I need and it may have taken me a while to figure that out
on my own.  So count me in as an eagerly expected user.

daniel



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

Re: [jelly] tag for accessing static fields

[Paul Libbrecht <pa...@activemath.org>]

On 17-May-04, at 21:44 Uhr, Daniel F. Savarese wrote:
> [...] add static field access.  Yet expression manipulation is limited  
> to JavaBean
> properties (otherwise there would be no need for the invoke tag),  
> which makes
> it seem like Jexl isn't the right place.  If static field access were  
> to
> be added, why not arbitrary method invocation?  Anyway, that's a  
> long-winded
> way of explaining why I do not yet understand the design guidelines  
> that help
> dictate what should go where.

Well, you would be even more lost that there's an amount of redundancy.
For example, jexl will let you invoke a method... it's ugly but works.
I presume that jelly's "design-guideline" are:
- in James Strachan's head... and who knows when this might come out  
(maybe this might even be dangerous)
- and a "digested" version in each and other's Jelly users' head. This  
may be very different for each
I think it makes a whole load of sense to discuss what one understands!
(there's this jelly IRC channel which should be good used some day...  
it has lost its archive)

My general rule is:
- Jexl for "function evaluation" (and variable evaluation
- Jelly tags for most, and especially for XML-structures
- My beans to quickly build a remote object
- My tags to make it more expressive...

> The downside to doing that would seem to be that you may have to write  
> a
> converter for every bean?  Or is there a way to do it once for all of
> them, where by default Jelly would try to match unknown properties  
> against
> constants?  I suppose that's where your mention of BeanUtils comes in.  
>  But
> with a converter, am I correct in assuming you couldn't throw in a  
> constant
> defined in a different class?

I would have thought "dedicated" converters.
But BeanUtils should allow this in three lines... I would expect  
something like the following invented code:
c = converterContext.makeCaseBasedConverter("defaultCloseOperation");
c.addIntConstants(JFrame.class,JFrame.EXIT_ON_CLOSE,JFrame.DISPOSE_ON_CL 
OSE,..);

The interesting in such a "declarative" converters registration is that  
jelly-tag-documentation should then be able to use this!

>> Feel free to go ahead but let's start this discussion on the usages of
>> converters in jelly-attributes since it seems BeanUtils folks are
>> "eagerly expecting users" ;-->
>
> I think I'll hold off on doing anything until the discussion runs its
> course.  So far, it seems there's agreement that it's useful to be  
> able to
> access static class fields, but there's more than one way to do it.

That's the amazing thing (and mess?) in Jelly, freedom and  
mix-and-match...
That's what ant really didn't allow and what programming languages tend  
to bann.

paul


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