--- [EMAIL PROTECTED] 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
