Extending EL Syntax
I've dabbled a bit with EL in the past for both Glassfish and Tomcat. Performance wise, no one's said the 'larger' feature set has caused performance problems (ELResolvers, ELContext, VariableMapper, etc). What I have seen, is people complaining about performance with OGNL. So what I want to see happen is for an EL implementation to fill in the necessary pieces to migrate OGNL users over to the EL API.
First, we of course need to support method invocation. This is pretty straight forward and will be considered a Value clause, just as a.b == a.getB().
Secondly, we would want to support projections/transformations/predicates within the language. I'm thinking that introducing '@' into the syntax would be the most readable solution as opposed to using dot notation with reserved literals. In addition, you don't always require a literal declaration of the projection and we could reduce expressions to something like:
If you wanted to specify the projection, then these two are equivalent:
Also, we could have some reserved projections for selection/sorting/etc:
sort by name
employee with the most salary
only employees with a 6 figure salary
highest salary only
the first employee found with the name of 'Bob'
Also, the EL-API has MethodExpressions where the expression represents a pointer to a method:
Invoke on each ActionListener
First, we of course need to support method invocation. This is pretty straight forward and will be considered a Value clause, just as a.b == a.getB().
Secondly, we would want to support projections/transformations/predicates within the language. I'm thinking that introducing '@' into the syntax would be the most readable solution as opposed to using dot notation with reserved literals. In addition, you don't always require a literal declaration of the projection and we could reduce expressions to something like:
#{company.employees@name}
a collection of Employee names#{company.employees@hashCode()}
a collection of Employee hashCodesIf you wanted to specify the projection, then these two are equivalent:
#{company.employees@salary}
#{company.employees@each{x|x.salary}}
Also, we could have some reserved projections for selection/sorting/etc:
sort by name
#{company.employees@asc{x|x.name}}
employee with the most salary
#{company.employees@max{x|x.salary}}
only employees with a 6 figure salary
#{company.employees@only{x|x.salary > 100000}}
highest salary only
#{company.employees@max{x|x.salary}.salary}
the first employee found with the name of 'Bob'
#{company.employees@first{x|x.name == 'Bob'}}
Also, the EL-API has MethodExpressions where the expression represents a pointer to a method:
#{employee.addAddress}
and you could invoke the MethodExpression with an Address object. If we used this in combination with projections, we could do some neat stuff like:Invoke on each ActionListener
#{bean.listeners@onAction}
4 Comments:
Why do we need new syntax for projections? An EL function would do us very well:
#{ui:project(company.employees, "name")}
OK, so this wouldn't handle things like functions - but it would handle quite a bit, without waiting for an EL rev. You could push it to support some of the additional options with something like:
#{ui:project(company.employees, "salary", "gt", 10000)}
Far from elegant, I know, but it gets the job done. I'm just not convinced that projections are *so* fundamental that they deserve intrinsic, specialized syntax - where do you draw the line?
A total side note: I reaaaally wish we'd added support for SE5 varargs in EE 5 EL functions.
In regards to performance of the EL - while I have no reason to suspect performance will be a problem, I would say that I wonder how many people have really run much deep profiling of EE5 apps yet...
Oh, and, yes we need method invocation. Which is new syntax, but what-the-hell. We could use EL functions today to get most of the functionality with inelegant syntax:
#{ui:invoke0(a, "getB")}
#{ui:invoke1(a, "addInt", 50)}
Blech. But usable for the time being.
By Adam Winer, at 12:39 PM
What's wrong with the way OGNL does projections? This is pretty simple:
employee.{name}
listeners.{? #this instanceof ActionListener}
By Anonymous, at 9:03 AM
with ognl, you are restricted to using #this, which may cause problems with nested projections. Also, it's fairly cryptic-- not to say that using @ is any better, but using @min, @each, @asc is more readable.
By Jacob Hookom, at 11:30 AM
情趣用品,情趣用品,情趣用品,情趣用品,情趣用品,情趣,情趣,情趣,情趣,情人歡愉用品,情趣用品,AIO交友愛情館,情人歡愉用品,美女視訊,情色交友,視訊交友,辣妹視訊,美女交友,嘟嘟成人網,按摩棒,震動按摩棒,微調按摩棒,情趣按摩棒,逼真按摩棒,G點,跳蛋,跳蛋,跳蛋,性感內衣,飛機杯,充氣娃娃,情趣娃娃,角色扮演,性感睡衣,SM,潤滑液,威而柔,香水,精油,芳香精油,自慰,自慰套,性感吊帶襪,情趣用品加盟,情人節禮物,情人節,吊帶襪,成人網站,AIO交友愛情館,情色,情色貼圖,情色文學,情色交友,色情聊天室,色情小說,七夕情人節,色情,A片,A片下載,免費A片,免費A片下載,情色電影,色情網站,辣妹視訊,視訊聊天室,情色視訊,免費視訊聊天,視訊聊天,美女視訊,視訊美女,美女交友,美女,情色交友,成人交友,自拍,本土自拍,情人視訊網,視訊交友90739,生日禮物,情色論壇,正妹牆,正妹,成人網站,A片,免費A片,A片下載,免費A片下載,AV女優,成人影片,色情A片,成人論壇,情趣,免費成人影片,成人電影,成人影城,愛情公寓,色情影片,保險套,舊情人,微風成人,成人,成人遊戲,成人光碟,色情遊戲,跳蛋,按摩棒,一夜情,男同志聊天室,肛交,口交,性交,援交,免費視訊交友,視訊交友,一葉情貼圖片區,性愛,視訊,嘟嘟成人網
愛情公寓,情色,舊情人,情色貼圖,情色文學,情色交友,色情聊天室,色情小說,一葉情貼圖片區,情色小說,色情,色情遊戲,情色視訊,情色電影,aio交友愛情館,色情a片,一夜情,辣妹視訊,視訊聊天室,免費視訊聊天,免費視訊,視訊,視訊美女,美女視訊,視訊交友,視訊聊天,免費視訊聊天室,情人視訊網,影音視訊聊天室,視訊交友90739,成人影片,成人交友,美女交友,微風成人,嘟嘟成人網,成人貼圖,成人電影,A片
By Anonymous, at 12:34 PM
Post a Comment
<< Home