jakarta-taglibs-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dmitri Plotnikov <dplot...@yahoo.com>
Subject Re: [JSPTL] Left-side expressions
Date Tue, 20 Nov 2001 18:17:26 GMT
Shawn,

--- Shawn Bayern <bayern@essentially.net> wrote:
> Dmitri --
> 
> Thanks for the note.  The idea of supporting lvalues
> in an expression has
> come up in the past, but I think it's accurate to
> say we're still
> undecided on its general applicability.  Two related
> thoughts:
> 
> * A final expression language might be able to
> implement an assignment
>   itself through an expression, thus potentially
> obviating the need
>   for explicit lvalue retrieval via a public method.
>  (E.g., an
>   "expression" could be "a = b".)
This is fine as long as it is standardized across all
expression languages (or if there is just one language
allowed).  I would want to construct an expression
like "a = b" dynamically.

> * Assignment can potentially be handled in a manner
> similar to what's
>   supported by <jsp:setProperty>:  that is, an
> object could be retrieved
>   and a property assigned based on JavaBean-style
> setXXX() methods.
>   This would support only a particular kind of
> assignment (namely, to
>   JavaBean-style properties).
This is what most people are doing right now, but for
my purposes I would like to be able to interpret
expressions as paths pointing to some modifiable
locations. The lack of such paths can be illustrated
by the following example.  Let's imagine a programming
language (C--) which is like C, except you cannot use
left-side expressions. The following would then be
somewhat analogous to using setProperty:

char[] from;
char[] to;
char* pointer;

for (i = 0; i < 100; i++){

   // I want to write: to[i] = from[i],
   // but since there are no lValues,

   pointer = to + i;
   *pointer = from[i];
}

It works, but is offensive esthetically.

> 
> I'm curious if either of these options would be
> convenient in the
> application you're working on.  I think it's
> definitely still a
> possibility that we'd simply expose an assignment
> mechanism, as you
> suggest.  Keep in mind that for the moment, I
> believe the plan, either
> way, is to make this functionality available only
> through the RI -- the
> JSTL spec will not contain public hooks to the
> expression language.

Pity. Those who, like myself, want to use expressions
in their own custom tags will then bypass the standard
APIs in favor of richer RI APIs, which is not a
desirable design.

On the other hand, I understand the desire to keep the
JSPTL spec as small as possible.  So maybe there is a
need for yet another spec that would deal directly
with expression languages.

> 
> Shawn
Thank you,

- Dmitri


> 
> On Fri, 16 Nov 2001, Dmitri Plotnikov wrote:
> 
> > As I was working on a simple library that
> generates
> > HTML Form tags in a JSPTL-compatible fashion, I
> ran
> > into an interesting problem.
> > 
> > I am using expressions to populate form elements
> like
> > text, checkbox etc.  For example, the text tag
> looks
> > like this:
> > 
> > <mytl:text name="street" value="address/street"/>
> > 
> > This generates an HTML "input" tag.
> > 
> > When the POST containing user input for "street"
> comes
> > back to the server, I map it back to the
> expression
> > that was used to populate it - "address/street" -
> and
> > want to update the value, this time interpreting
> the
> > expression as a left-side expression.
> > 
> > That's where I run into this problem:
> > ExpressionEvaluator only understands the
> right-side
> > expressions. It can retrieve values, but it cannot
> > store them.  It does not have any API for
> left-side
> > expressions.  For example, a method like 
> > 
> >    assign(String lExpression, Object value)
> > 
> > would be very helpful.  If this method were
> available,
> > I would be able to use Expression Evaluators to
> both
> > read and write data.
> > 
> > At least one of the expression language
> interpreters
> > bundled with JSPTL (JXPath) already supports this
> > notion.  So, as a workaround, I temporarily hacked
> a
> > way around ExpressionEvaluator to talk directly to
> > JXPath.  This, of course, is a very disappointing
> > architectural solution, because it constrains the
> > users of my tag library to a single expression
> > language (XPath), which may not be the one the
> JSR-52
> > group chooses as the default one. In fact, I don't
> > think it should be the default one: XPath is only
> a
> > natural choice if you are working with XML or a
> mix of
> > XML and Java objects. 
> > 
> > BTW, I am very excited about this integration I am
> > working on - the flexibility of JSPTL logic tags
> > combined with a simple Form builder and
> POST-processor
> > almost makes a complete solution for simple
> > transaction-oriented applications.
> >  
> > Thanks,
> > 
> > Dmitri Plotnikov
> > dmitri@plotnix.com
> > 
> > __________________________________________________
> > Do You Yahoo!?
> > Find the one for you at Yahoo! Personals
> > http://personals.yahoo.com
> > 
> > --
> > To unsubscribe, e-mail:  
> <mailto:taglibs-dev-unsubscribe@jakarta.apache.org>
> > For additional commands, e-mail:
> <mailto:taglibs-dev-help@jakarta.apache.org>
> > 
> 


__________________________________________________
Do You Yahoo!?
Yahoo! GeoCities - quick and easy web site hosting, just $8.95/month.
http://geocities.yahoo.com/ps/info1

--
To unsubscribe, e-mail:   <mailto:taglibs-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:taglibs-dev-help@jakarta.apache.org>


Mime
View raw message