Chat transcript, 04:22 PM CST

chatbot> New thread by David Andersen: Handling legacy errors (on plain JSP pages) (http://forums.opensymphony.com/thread.jspa?threadID=53263)
chatbot> New reply by Mike Brock: OGNL (or the quest for performance) (http://forums.opensymphony.com/thread.jspa?messageID=107110)
chatbot> New thread by Jason Jones: JSR168PorletDispatcher Not Executing Action on Form Submission (http://forums.opensymphony.com/thread.jspa?threadID=53269)
chatbot> New thread by taomingzhe: how to pass the value to the next page ??? (http://forums.opensymphony.com/thread.jspa?threadID=53297)
chatbot> New thread by Martin Gilday: Token Session Interceptor problems (http://forums.opensymphony.com/thread.jspa?threadID=53319)
chatbot> New reply by Martin Gilday: OGNL (or the quest for performance) (http://forums.opensymphony.com/thread.jspa?messageID=107230)
chatbot> New reply by nuel: JavaPolis Dinner 2006 (http://forums.opensymphony.com/thread.jspa?messageID=107236)
chatbot> New thread by walidito: Struts 2 or Webwork (http://forums.opensymphony.com/thread.jspa?threadID=53340)
chatbot> New reply by Martin Gilday: Struts 2 or Webwork (http://forums.opensymphony.com/thread.jspa?messageID=107267)
chatbot> New thread by mike haberman: Can someone explain how the Velocity To Freemarker tag rendering works? (http://forums.opensymphony.com/thread.jspa?threadID=53371)
chatbot> New reply by Pavan: datepicker and cssStyle issue. (http://forums.opensymphony.com/thread.jspa?messageID=107355)
chatbot> New reply by Pavan: Ajax for populating drop downs list box (http://forums.opensymphony.com/thread.jspa?messageID=107356)
mbrock> re
[email protected]> howdy
mbrock> how's it going?
[email protected]> pretty good
[email protected]> how's life?
mbrock> alright.
mbrock> you're don brown, right?
[email protected]> that's me
mbrock> I sent you an e-mail yesterday afternoon at the request of Phil Luppens.
mbrock> In regards to MVEL.
[email protected]> ah, right
[email protected]> nice to meet you
mbrock> likewise.
mbrock> so you're actively thinking of dumping OGNL?
[email protected]> yep
[email protected]> I'm pretty sold on it for struts 2.1 or 3
mbrock> Well, MVEL is a good alternate :)
[email protected]> but, to be honest, I want to move to the standard jsp el
[email protected]> mainly for the tool support
[email protected]> and so that jsp developers don't need to learn yet another el
mbrock> Well, that's certainly a good choice.   We couldn't do that for MVFLEX because of needed functionality that was not in JSP EL
mbrock> MVEL is really designed as a general purpose language, as opposed to being catered specifically to JSP
mbrock> And as such, it's used inside config file parsers, annotation parsers, and presentation-tier technologies
mbrock> to improve integration
[email protected]> well, unfortunately, jsp el doesn't have everything we need either
[email protected]> so we'll probably have to extend it
mbrock> MVEL however, is source compatable with JSP EL for the most part.
mbrock> there are also issues with JSP EL integration, and extending it
mbrock> ...
mbrock> we had issues with JSP EL, and it was in fact our first choice before going to the re-invent-the-wheel approach
[email protected]> why couldn't you just extend it?
mbrock> the problem with JSP EL, in the spec, is that JSP-EL is parsed prior to calling the taglib
mbrock> which makes accessing framework objects (like ActionRequest) difficult
[email protected]> why?
mbrock> in our case, is did
mbrock> it did
mbrock> well, because, you basically have to set things up as beans in your JSP
mbrock> in order to make them accessible to the JSP EL
[email protected]> like what?
mbrock> without modifying the JSP implementation in the appserver itself, adding automatic variables and contexts to the EL doesn't really have an elegant solution
[email protected]> we do it now by wrapping the request
[email protected]> so it searches our framework objects before the rest
mbrock> yeah, but your taglibs are pulling the data and pushing it into the OgnlValueStack method, aren't they?
mbrock> it
[email protected]> very rarely
[email protected]> but yeah, they do in a couple of cases
mbrock> so the expression: #{foo} is parsed prior to binding it to a TagLib property?
[email protected]> well, ${foo} 
[email protected]> if you are using jsp el
mbrock> how are you going to access your valuestack with jsp el?
[email protected]> you have the option of doing either
mbrock> what will the expression look like?
[email protected]> ${foo}
[email protected]> the wrapped request looks for the "foo" property on the value stack before deferring to the usual behavior
mbrock> isn't it more expensive to do that?
[email protected]> how so?
mbrock> how does the request wrapper find these properties?
[email protected]> it has access to the value stack
mbrock> tag lib parameters is as direct binding calls in the JSP java source
mbrock> ie.. parameter="blah" --> taglib.setParameter("blah"); taglib.doAfterBody() .. etc
[email protected]> yep
mbrock> how do you wrap that functionality?
[email protected]> oh, I mean we override request.getAttribute
[email protected]> to have it search the value stack before looking at the request attributes
mbrock> yeah, but how do you handle expressions being passed to taglib properties?
mbrock> with jsp el... you won't have an opportunity to reference your valuestack in those scenarios
[email protected]> well, if you use the %{foo} syntax, then they are parsed later
[email protected]> I'm still not seeing why this is a problem
[email protected]> if the el is evaluated before my tag gets a hold of it, it is ok
mbrock> just seems strange to have two different sets of rules as to how expressions are parsed.
[email protected]> since the wrapped request can access the value stack
mbrock> one for general expressions, and one for TL parms
[email protected]> I agree, which is why I want to ditch ognl and the %{foo} synt
mbrock> okay.
mbrock> hmm
mbrock> can JSP EL even have root contexts?
[email protected]> like what?
mbrock> like, OGNL and MVEL allow rooting of a context
mbrock> say... an instance of the class User is a context
mbrock> which means.. the expression "userName" is evaluated AGAINST the root context 
mbrock> so.. User.getUserName()
mbrock> as opposed "user.userName"
[email protected]> so the expression would be "userName" right?
mbrock> yes
[email protected]> yeah, that's how it works now with the value stack
mbrock> but i don't think JSP EL can do that
[email protected]> http://svn.apache.org/repos/asf/struts/struts2/trunk/core/src/main/java/org/apache/struts2/dispatcher/StrutsRequestWrapper.java
[email protected]> that's how we do it
mbrock> i understand that part...
mbrock> but i don't see how that covers dealing with taglib attributes.
mbrock> since those are not processed through a wrapper
[email protected]> why wouldn't they be?
[email protected]> can't you use ${foo} in a taglib attribute?
mbrock> well, in our framwork, the Action class is always the root
mbrock> and request attributes are not directly accessible as root variables in our view
mbrock> as in our design, we consider that an anti-pattern
[email protected]> why?
mbrock> i am not completely up to snuff on webwork's design
mbrock> well, that's a whole other discussion :)
mbrock> i'm not trying to sell my web framework
mbrock> Phil has just asked me to open up a dialog with you about MVEL because he felt you'd be interested.
[email protected]> sure, the more eyes looking at this the better
[email protected]> and don't think you'll offend me or anything commenting on struts 2/ww design :)
mbrock> we also use MVEL for validations in our framework
mbrock> ie.
mbrock> <mv:input name="someOption"> <mv:validation constraint="this.value != empty"/> </mv:input>
mbrock> in our JSP markup
mbrock> ... or.. <mv:validation contraint="this.value != empty && this.value.length() > 10" message="Option must not be empty, and must be longer than 10 characters" />
[email protected]> nice
mbrock> which is the other advantage of MVEL, in that it doesn't need to be inside a @{} construct
mbrock> it can be directly integrated
mbrock> like <mv:if ex="collection != empty">
mbrock> as opposed to <mv:if ex="@{collection != empty">
mbrock> the empty literal checks for nullness, blankness, empty arrays, empty collections, empty maps, etc.
[email protected]> interesting
mbrock> http://wiki.mvflex.org/index.php?title=MVEL_Language_Reference#Empty_comparison_literal

---------------------------------------------------------------------
Posted via Jive Forums
http://forums.opensymphony.com/thread.jspa?threadID=53400&messageID=107395#107395

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]