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]

Reply via email to