Values exposed to OGNL Implicit vs. Explicit

[st...@gmail.com]

Can someone point to a nice explanation (preferably a graphic) that explains
how values are exposed to the OGNL by the S2 framework *and* the preferred
technique to access them?  S2 or JSTL tag?  What is the appropriate access
syntax?  I realize OGNL is a stand-alone facility, but it appears to be
tightly interlaced with S2.  Does OGNL overlap the familiar Servlet objects?
  I read the new tutorial Struts 2 + Spring 2 + JPA +
AJAX<http://struts.apache.org/2.x/docs/struts-2-spring-2-jpa-ajax.html>and
"Look mom my action is a simple POJO!  However, if you choose to go
the
vanilla interface route you give up many things inherited from
ActionSupport.  I started off using POJO Actions and quickly found myself
painted in a corner.  Beyond the trivial case, you discover this won't work!


Also, I am reading many threads where folks are confused by not having the
typical S1 objects (req, resp, form,session) available in their Action
classes and how they need to use the S2 "aware" interfaces.  But wait, next
I read how the interfaces are not *really* needed because you can always
grab these objects from the big fat ActionContext.

Let's face it... this is confusing!  I understand the interplay with
dependency injection and how the Action interfaces fills this contract.  Not
real sure about ModelDriven however (or is it ScopedModelDriven).  I also
realize the infamous OGNL has values pushed/popped on a stack and there are
a variety of ways to access them in other places.  What we need is a clear
example that is more involved than Person.java to realize how all the parts
interrelate.  If you look at the Struts 2 + Spring 2 + JPA + AJAX
<http://struts.apache.org/2.x/docs/struts-2-spring-2-jpa-ajax.html>you will
discover even this *fresh* example does not illustrate the S2 way of
minimizing configuration via Struts-style wildcards.  It's just bits and
parts -- and what the heck was the TopLink stuff?

Developers are pulling ideas from this half-documented site and pushing code
into their SCM.  I honestly think for S2 to be successful, we need a better
staring point as an example.  Many of the online samples return 404 when
clicked.  What we currently have is not representative of an enterprise
web-site.  Too trivial or too complex is too bad.  I would happily publish
my S2 web app as a demonstration once I am certain it utilizes the *correct*
S2 techniques and not just something I was able to get working.

Another thing is the subject line for these messages!  The answer to your
problem might be in this message or that, but you'll skip it because the
subject does not sound correlated to your issue.  I can hear it now –
"everyone save the messages and search your archives."

I want S2 to succeed as badly as those of you on this message group,
however, the hit-and-miss approach of coding, reading about a better
technique, refactoring, then coding it again is numbing.  We need a concise
and unified blueprint "that remains in lock-step with the prevailing S2
version" before building the web app!  If this is expected to compete with
the challengers, this needs to be completed soon.  I have a buddy doing RoR.
If what he is telling me about the ease of development is even 10% fact, it
won't be long before S2 is SYesterday.  10% is a wonderful Rate-of-Return

Wow, and I was simply looking to clarify OGNL.


-- 
Scott
stanlick@gmail.com

Re: Values exposed to OGNL Implicit vs. Explicit

[Ted Husted <hu...@apache.org>]

On 4/10/07, stanlick@gmail.com <st...@gmail.com> wrote:
> Let's face it... this is confusing!  I understand the interplay with
> dependency injection and how the Action interfaces fills this contract.  Not
> real sure about ModelDriven however (or is it ScopedModelDriven).  I also
> realize the infamous OGNL has values pushed/popped on a stack and there are
> a variety of ways to access them in other places.  What we need is a clear
> example that is more involved than Person.java to realize how all the parts
> interrelate.

Towards the end of creating a bigger example, I setup a Petstore site
on Google Code, with the hope of extending the Spring MVC/Struts 1
example with a S2 example too.

* http://code.google.com/p/sq1-petstore/

Though, I'll probably do a YUI example first. If someone wants to work
on an a S2 Petstore, that would be great.


>  If you look at the Struts 2 + Spring 2 + JPA + AJAX
> <http://struts.apache.org/2.x/docs/struts-2-spring-2-jpa-ajax.html>you will
> discover even this *fresh* example does not illustrate the S2 way of
> minimizing configuration via Struts-style wildcards.  It's just bits and
> parts -- and what the heck was the TopLink stuff?
>
> Developers are pulling ideas from this half-documented site and pushing code
> into their SCM.  I honestly think for S2 to be successful, we need a better
> staring point as an example.  Many of the online samples return 404 when
> clicked.  What we currently have is not representative of an enterprise
> web-site.  Too trivial or too complex is too bad.  I would happily publish
> my S2 web app as a demonstration once I am certain it utilizes the *correct*
> S2 techniques and not just something I was able to get working.

You'd probably have to do it the other way around. Set it up on Google
Code or someplace first, and then ask for feedback.


> Another thing is the subject line for these messages!  The answer to your
> problem might be in this message or that, but you'll skip it because the
> subject does not sound correlated to your issue.  I can hear it now –
> "everyone save the messages and search your archives."
>
> I want S2 to succeed as badly as those of you on this message group,
> however, the hit-and-miss approach of coding, reading about a better
> technique, refactoring, then coding it again is numbing.  We need a concise
> and unified blueprint "that remains in lock-step with the prevailing S2
> version" before building the web app!

Thanks for volunteering!


> If this is expected to compete with
> the challengers, this needs to be completed soon.  I have a buddy doing RoR.
> If what he is telling me about the ease of development is even 10% fact, it
> won't be long before S2 is SYesterday.  10% is a wonderful Rate-of-Return

I don't think anyone here is jealous of RoR. If my team wanted to use
it, I wouldn't hesitate. I expect most of the other Struts committers
feel the same way. I know other committers use RoR from time to time
too. It's not an election of remedies. I don't think any of us will
ever see the day when there is one web application framework, or, for
that matter, one web platform.

-Ted.

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org

Re: Values exposed to OGNL Implicit vs. Explicit

[Dave Newton <ne...@yahoo.com>]

--- stanlick@gmail.com wrote:
> [...] the preferred technique to access them?  
> S2 or JSTL tag?

"Preferred" is a matter of taste; I don't have any
issues accessing the attributes or OGNL stack via JSP
2.0 EL syntax (instead of <s:property.../>, just
because ${} is so much more concise), but there was
already one thread where someone disagreed with me and
said they preferred to use the S2 tags so metaphors
weren't being mixed, which is a valid concern.

I suppose there's a minor penalty performace for
accessing OGNL via JSTL since there's one level of
indirection (StrutsRequestWrapper (?)).

>  What is the appropriate access syntax?
> Does OGNL overlap the familiar Servlet objects?

I'm not sure what you're asking; OGNL puts the maps
for the "normal" servlet spec attributes and
parameters on the stack. I don't know if I'd call that
"overlap" or not.

What is lacking from the following links? Someone will
be happy to update and/or enhance them (as has been
happening as the result of recent threads).

http://struts.apache.org/2.x/docs/ognl.html
http://struts.apache.org/2.x/docs/ognl-basics.html

> "Look mom my action is a simple POJO!  However, if
> you choose to go the vanilla interface route you
give 
> up many things inherited from ActionSupport.  I
started 
> off using POJO Actions and quickly found myself
> painted in a corner.  Beyond the trivial case, you
> discover this won't work!

We might just be discussing definitions here, but...
ActionSupport is basically a collection of the most
useful S2 interface implementations. It's still a
POJO. I agree, not using ActionSupport creates a lot
of work. That's why it's there; I generally extend it
by default, since I'm using validation and I18N.

The point of saying "It's a POJO" isn't that there's
no functionality, it's that it's almost completely
decoupled from anything other than simple Java types.
Compare to S1 Action, which is tied to servlet and S1.
(The Locale stuff that takes ValueStacks being the
notable exceptions. Not sure what to think about that;
still pondering.)

> Also, I am reading many threads where folks are
> confused by not having the typical S1 objects 
> (req, resp, form,session) available in their Action
> classes and how they need to use the S2 "aware"
> interfaces.  But wait, next I read how the
interfaces 
> are not *really* needed because you can always
> grab these objects from the big fat ActionContext.

To me this isn't really a question: implementing an
interface is almost *always* a better choice than
tying implementation to a specific class
(ActionContext). But this doesn't (seem) to apply to
Actions--ActionContext is (primarily, at least?) for
Interceptors.

> Not real sure about ModelDriven however (or is it
> ScopedModelDriven).

There's both.

> discover even this *fresh* example does not
> illustrate the S2 way of minimizing configuration 
> via Struts-style wildcards.

I'm not entirely I'd call wildcarding the "S2 Way";
it's certainly *a* way, and maybe even a good way.

> [...] and what the heck was the TopLink stuff?

TopLink is TopLink; not everybody uses Hibernate. It's
the least-important part of that page.

> Developers are pulling ideas from this
> half-documented site and pushing code
> into their SCM.  I honestly think for S2 to be
> successful, we need a better
> staring point as an example.  Many of the online
> samples return 404 when
> clicked.  What we currently have is not
> representative of an enterprise
> web-site.  Too trivial or too complex is too bad.  I
> would happily publish
> my S2 web app as a demonstration once I am certain
> it utilizes the *correct*
> S2 techniques and not just something I was able to
> get working.
> 
> Another thing is the subject line for these
> messages!  The answer to your
> problem might be in this message or that, but you'll
> skip it because the
> subject does not sound correlated to your issue.  I
> can hear it now –
> "everyone save the messages and search your
> archives."
> 
> I want S2 to succeed as badly as those of you on
> this message group, however, the hit-and-miss
approach 
> of coding, reading about a better technique,
refactoring,
> then coding it again is numbing.  

What do you normally do?!

> We need a concise

I wouldn't know how to create "concise" documentation
for
writing a Java-based, full-stack web-app. It's
complicated.

> I have a buddy doing RoR. If what he is telling me
about 
> the ease of development is even 10% fact, it won't
be 
> long before S2 is SYesterday.  10% is a wonderful 
> Rate-of-Return

There are a lot of application spaces where RoR falls
completely flat. As long as what you are doing is
supported by default Rails, you're fine. As soon as
you fall out of lock-step, it's a nightmare. I do
quite like fronting EE apps w/ it, though. Not
approriate for a lot of environments, though.

I've been developing w/ RoR for... two years now (and
Ruby for 4-ish)? I'm still using both JEE and RoR and
don't see *any* possible way that will change in the
immediate (2-5 yrs) future, although I'm quickly
moving away from Java as an implementation language.
(No, not to JRuby, but we'll see... Scala is my first
choice, followed by Groovy. I could see JRuby
replacing Groovy for me, I suppose.)

Have you filed a CLA and requested Wiki access?

d.



 
____________________________________________________________________________________
Expecting? Get great news right away with email Auto-Check. 
Try the Yahoo! Mail Beta.
http://advision.webevents.yahoo.com/mailbeta/newmail_tools.html 

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org