Hi,
The patch I propose is:
ASTSetDirective.render() - to fix a bug I have reported:
+ Assigning a NULL value to the context will remove the entry
(since Hashmap does not allow it).
+ make it pass even null values to the LHS ASTReference.setValue()
ASTReference.setValue() to differentiate between maps and
methods (using the introspection engine)
+ Assigning a NULL value to a map will remove the map entry
+ possibly uppercasing the first character to allow something like
"#set $object.size = 10" access setSize().
+ possibly adding the notion of getting/setting fields (if voted for)
+ possibly: if the rootString is not in the context check with
the classloader if the dotted path (ASTIdentifiers) point
to a static method of a class... similar to the xsl:java
taglib. (if voted for)
ASTIdentifier.execute() get rid of the Executor classes, make
the doIntrospection do the inverse that ASTReference.setValue()
does. Resulting in "Given $object.size we could search for
$object.getSize(), $object.size(), $object.get("size")" and
possibly $object.size (public field).
This way setting is concentrated within ASTSetDirective (context.put)
or ASTReference.setValue() (introspection) and getting is all done
within ASTReference (context.get) or the following ASTIdentifiers
(introspection). This will allow consistent handling.
More embedded.
[EMAIL PROTECTED] wrote:
>
> On Thu, 7 Dec 2000, Christoph Reck wrote:
>
> > Currently the ASTReference and ASTIdentifier (also ASTSetDirective)
> > handle set and get method hardwired and differently.
>
> They are different for reason. When setting the value of
> reference strict bean behaviour is used, there has to
> be a setXXX(). For properties, handled by ASTIdentifier
> we again use bean behaviour with the extension for Maps.
OK, if the contract for #set is to stick to the bean definition,
we'll live with it... more below...
But it seems strange that $hashtable.XXX works but
#set $hashtable.XXX = "anything" does not!
>
> > ASTIdentifier knows the Map collection class get() method,
> > whereas ASTSetDirective via ASTReference.setValue(...) does not
> > know how to handle the set method of the Map interface.
>
> There is no set method in the Map interface.
I meant "put", dummy me!
>
> > An access to $list.size without () throws a ClassCastException
> > whereas "#set $list.Size = 10" works (because there is a
> > setSize method).
>
> Right, we are trying to follow standard bean properties.
> A List is not a bean, and List.size() is not a property.
> But we could certainly extend the search for your example
> above. Given $object.size we could search for $object.getSize(),
> $object.size(), $object.get("size")
>
> Is that what you're talking about?
exactly!
>
> > Proposal:
> > Allign the handling of references and indentifiers to accept
> > getting and setting of:
> > * Patch on ASTReference.setValue(...) to allow a set for
> > objects implementing the Map interface.
>
> So you want
>
> #set $map.key = $value
>
> instead of
>
> $map.put("key", $value)
>
> If that's the case then it's it looks pretty limiting: the
> only thing you can use for the key are strings. I'm not
> sure there's much benefit in changing the behaviour when
> $map.put($this,$that) is available. But it is not hard
> to implement, and if designers are using them then
> consistent use of #set might be desirable.
>
The limiting is not an impact, since we are talking of
indentifiers. Something like #set $map.$objectKey... is out
of scope and should not be supported.
> > * Patch for ASTReference to use the introspection engine
> > to allow setValue to a method with a superclass/primitive
> > signature, e.g.: #set $list.Size = 10
>
> I agree that primitive properties should be supported,
> but I don't agree with an object with a size(int i)
> method being supported by #set. The #set is for setting
> values of references (a property is a reference) not
> executing arbitrary methods. Why not simply use
> $list.size(1) instead of #set $list.size = 1 ?
OK, I could agree here. We can restrict set and identifiers to
the bean pattern AND maps. Methods should do the rest...
>
> > * Patch ASTIdentifier to allow accessing method names not
> > following bean conventions (e.g. methods not prefixed with
> > get). This is already possible by just adding empty ()
> > after the identifier (this makes the node into a ASTMethod!)
> > - but this is not orthogonal usage: no brakets required
> > for getXXX methods, but yes for XXX() methods.
>
> getXXX() are properties and XXX() are not. This was the
> original reason, to follow bean behaviour. Many people
> seem to want this so it could be added.
I guess people are spoiled by the WM form (and are having a hard
time porting from it - as myself). Vel does allow the abbreviated
form of $ref.Xxx to mean $ref.getXxx() and this misleads to
believe more power behind the introspection...
If you +1 this, I'll provide the patch for the "Given $object.size
we could search for $object.getSize(), $object.size(),
$object.get("size")" form.
>
> > * Alternatively fix ASTIdentifier/MapExecutor not to throw
> > a ClassCastException.
> > * Set and get object public fields.
>
> > * Add a feature to ASTReference to access methods/fields of
> > static classes.
>
> Static methods work. I use them in Texen/Torque all
> the time. I don't really like being able to access
> public fields.
I meant something like #set $foo = $java.util.Arrays.sort($list)
I can agree to drop the need of accessing public fields in the
Vel environment... If it where to access things like
javax.swing.SwingConstants.CENTER it would be very desireable...
>
> jvz.
I'll start as soon as at least you give me a +1 and I have JTest
running again.
:) Christoph
