Don't dare me. I'm pretty ambitious. I wrote MVEL 1.0 in three days.
Don Brown-2 wrote: > > I'd like it to be possible for a Struts developer to swap in a new EL, > perhaps MVEL, if they didn't like OGNL for some reason. If you can > create a patch to make that happen, I would consider it my early > Christmas present :) > > Don > > Chris Brock wrote: >> Why do you think it would be so terribly difficult? What does MVEL not >> support that is currently supported by OGNL that would not be fixable by >> a >> few tweaks to MVEL's syntax? >> >> Generally, MVEL's API architecture follows the same pattern as OGNL, >> supports type coercion, conversion, projections, etc. >> >> Not to mention that MVEL is now an active project and OGNL is not, and of >> course the performance advantage in MVEL which is only getting better by >> the >> day. >> >> >> Don Brown-2 wrote: >> >>> If you can find a way to completely replace OGNL by MVEL, I'd be very >>> interested to see it. :) >>> >>> Don >>> >>> Chris Brock wrote: >>> >>>> I think the problem is that the Tapestry solution is simply a property >>>> accessor package, which doesn't really meet the needs of the >>>> established >>>> WebWork community which relies on "expressions" in addition to >>>> properties >>>> to >>>> accomplish tasks. >>>> >>>> That being said, my project (MVEL) stands willing to step in and >>>> assist. >>>> I >>>> think it's performance and flexibility speak for itself: >>>> http://wiki.mvflex.org/index.php?title=MVFLEX_Expression_Language >>>> >>>> >>>> Jessek wrote: >>>> >>>> >>>>> I'm still not getting all of the hand wringing that is going on in >>>>> this >>>>> thread about ognl. There is what I think a perfectly reasonable >>>>> solution >>>>> that will help finish up those last remaining bits that ognl needs to >>>>> really be production ready. >>>>> >>>>> Despite whatever we want to call it you could theoretically view it as >>>>> just another interpreter. I may be from an "enemy project" but I'm >>>>> still >>>>> willing/able to make the changes necessary for this to work. >>>>> >>>>> I've tried on a few occasions to engage whoever I can in the ognl >>>>> world >>>>> to >>>>> make this possible but haven't gotten any good responses yet. This >>>>> isn't >>>>> a >>>>> hard problem to solve, so it's frustrating watching everyone implement >>>>> new >>>>> property path interpreters /debate ognl when the answer is right >>>>> there... >>>>> ;/ >>>>> >>>>> >>>>> Don Brown wrote: >>>>> >>>>> >>>>>> I wrote a simple Struts 2 TemplateEngine that renders tags in pure >>>>>> Java, as opposed to the Freemarker that is used currently. I'm >>>>>> seeing >>>>>> performance improvements between 3 and 4 times faster than the old >>>>>> tags. This engine is based on the design I layed out previously [1]. >>>>>> It is better suited to simple tag rendering where the Freemarker >>>>>> version is better suited for HTML-heavy tag output and customization. >>>>>> >>>>>> The Java engine: >>>>>> - Allows the tag generator and "interceptors" to deal with tag >>>>>> objects, not pure text >>>>>> - Tag "interceptors" or handlers have full control over the output >>>>>> - Serialization of tag objects into text can be customized >>>>>> - Is fast - 3 to 4 times faster than the Freemarker engine >>>>>> >>>>>> Anyways, if nothing else, it shows there are things we can do to >>>>>> drastically speed up the tags w/o throwing out OGNL. If you only use >>>>>> the simple theme, this might be an attractive option that gives you >>>>>> more customization and speed. >>>>>> >>>>>> I'm kinda up in the air as to where to put this. I'm leaning toward >>>>>> committing it to the sandbox as then it would be clear it is >>>>>> experimental, especially since not all tags and themes are >>>>>> implemented. >>>>>> >>>>>> Don >>>>>> >>>>>> [1] - http://www.mail-archive.com/dev@struts.apache.org/msg25065.html >>>>>> >>>>>> On 12/13/06, Don Brown <[EMAIL PROTECTED]> wrote: >>>>>> >>>>>> >>>>>>> Very interesting... I wonder how much of the performance hit was due >>>>>>> to >>>>>>> Freemarker and how much OGNL. Could you package this application in >>>>>>> a >>>>>>> war and attach it to a JIRA ticket? I'd love to have it for future >>>>>>> comparisons. >>>>>>> >>>>>>> Don >>>>>>> >>>>>>> dice wrote: >>>>>>> >>>>>>> >>>>>>>> They are my stats Ted. The stats are posted below along with my >>>>>>>> sample >>>>>>>> >>>>>>>> >>>>>>> JSP >>>>>>> >>>>>>> >>>>>>>> code. I only tried the textfield tag but looking at the ftl and vm >>>>>>>> >>>>>>>> >>>>>>> files for >>>>>>> >>>>>>> >>>>>>>> the other tags I can't see how the results would be any different. >>>>>>>> >>>>>>>> Perhaps an interim solution could be to remove the use of OGNL from >>>>>>>> >>>>>>>> >>>>>>> core >>>>>>> >>>>>>> >>>>>>>> functionality that doesn't require it. eg. Is it really necessary >>>>>>>> to >>>>>>>> >>>>>>>> >>>>>>> access >>>>>>> >>>>>>> >>>>>>>> UIBean attributes from the theme templates using OGNL? >>>>>>>> >>>>>>>> PS: I emulated the Struts 2 themes in Struts 1 by wrapping Struts 1 >>>>>>>> >>>>>>>> >>>>>>> tags in >>>>>>> >>>>>>> >>>>>>>> JSP Tag files and performance was still impressive. >>>>>>>> >>>>>>>> >>>>>>>> ---------------------------------------------------------------- >>>>>>>> >>>>>>>> Technology - Hits per second with 1 user / 10 users: >>>>>>>> >>>>>>>> Struts 1 - 109 / 191 >>>>>>>> Stripes - 88 / 140 >>>>>>>> WW2/SAF2 with default FreeMarker templates - 12 / 7 >>>>>>>> WW2/SAF2 with Velocity templates - 22 / 15 >>>>>>>> JSF - 27 / 40 >>>>>>>> >>>>>>>> >>>>>>>> Sample JSP: >>>>>>>> >>>>>>>> <s:form action="/test.action" method="POST"> >>>>>>>> <s:textfield label="Label1" name="attribute1"/> >>>>>>>> <s:textfield label="Label2" name="attribute2"/> >>>>>>>> <s:textfield label="Label3" name="attribute3"/> >>>>>>>> <s:textfield label="Label4" name="attribute4"/> >>>>>>>> <s:textfield label="Label5" name="attribute5"/> >>>>>>>> <s:textfield label="Label6" name="attribute6"/> >>>>>>>> <s:textfield label="Label7" name="attribute7"/> >>>>>>>> <s:textfield label="Label8" name="attribute8"/> >>>>>>>> <s:textfield label="Label9" name="attribute9"/> >>>>>>>> <s:textfield label="Nested Label1" >>>>>>>> >>>>>>>> >>>>>>> name="nestedBean.attribute1"/> >>>>>>> >>>>>>> >>>>>>>> <s:textfield label="Nested Label2" >>>>>>>> >>>>>>>> >>>>>>> name="nestedBean.attribute2"/> >>>>>>> >>>>>>> >>>>>>>> <s:textfield label="Nested Label3" >>>>>>>> >>>>>>>> >>>>>>> name="nestedBean.attribute3"/> >>>>>>> >>>>>>> >>>>>>>> <s:textfield label="Nested Label4" >>>>>>>> >>>>>>>> >>>>>>> name="nestedBean.attribute4"/> >>>>>>> >>>>>>> >>>>>>>> <s:textfield label="Nested Label5" >>>>>>>> >>>>>>>> >>>>>>> name="nestedBean.attribute5"/> >>>>>>> >>>>>>> >>>>>>>> <s:textfield label="Nested Label6" >>>>>>>> >>>>>>>> >>>>>>> name="nestedBean.attribute6"/> >>>>>>> >>>>>>> >>>>>>>> <s:textfield label="Nested Label7" >>>>>>>> >>>>>>>> >>>>>>> name="nestedBean.attribute7"/> >>>>>>> >>>>>>> >>>>>>>> <s:textfield label="Nested Label8" >>>>>>>> >>>>>>>> >>>>>>> name="nestedBean.attribute8"/> >>>>>>> >>>>>>> >>>>>>>> <s:textfield label="Nested Label9" >>>>>>>> >>>>>>>> >>>>>>> name="nestedBean.attribute9"/> >>>>>>> >>>>>>> >>>>>>>> <s:submit/> >>>>>>>> </s:form> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Ted Husted-3 wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> On 12/13/06, Ian Roughley <[EMAIL PROTECTED]> wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> Do you have the performance numbers that you can share? I'd >>>>>>>>>> really >>>>>>>>>> >>>>>>>>>> >>>>>>> be >>>>>>> >>>>>>> >>>>>>>>>> interested in them. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> There are some interesting numbers here >>>>>>>>> >>>>>>>>> * >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>> http://javajmc.blogspot.com/2006/10/webwork-and-stripes-simple-performance.html >>>>>>> >>>>>>> >>>>>>>>> (be sure to read to the *end* of the commnets). >>>>>>>>> >>>>>>>>> We might want to come up with a set of test pages that thorougly >>>>>>>>> exercise the core tags, so that we can run our own direct >>>>>>>>> comparisons >>>>>>>>> of S1, S2, et al. >>>>>>>>> >>>>>>>>> Of course, the peformance is the still same as WebWork 2, which is >>>>>>>>> driving some serious applications. We also know exactly where lies >>>>>>>>> >>>>>>>>> >>>>>>> the >>>>>>> >>>>>>> >>>>>>>>> bottleneck. We need to fix or replace OGNL. >>>>>>>>> >>>>>>>>> -Ted. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> --------------------------------------------------------------------- >>>>>>> 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] >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>> >>>> >>> --------------------------------------------------------------------- >>> 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] > > > -- View this message in context: http://www.nabble.com/OGNL-performance-detrimental-to-Struts-2-tf2804655.html#a7940543 Sent from the Struts - Dev mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
