You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by Rick Mann <rm...@latencyzero.com> on 2006/01/07 02:05:05 UTC
Advice for Struts expert wanting to try Shale?
Hi. I've done a couple of industrial-strength websites using Struts,
Tiles & JSTL. I decided to start on a little personal project, mostly
as a way to get on board with some technologies, some of which I've
used before (maven 1/2, torque), some which I want to learn (JSF,
Shale).
I looked around the Shale pages a bit last night, and found myself
unable to grasp what it offered. I also looked at some of the JSF
introductory articles, and was concerned that they referenced pre-
release versions of JSF, and didn't reference Shale.
I'm happy to abandon Struts if it makes sense, and certainly I'd like
to replace Struts components when functionality is provided by Shale/
JSF.
Can someone point me to (or give me) an appropriate overview? Thank
you very much!
--
Rick
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Advice for Struts expert wanting to try Shale?
Posted by Laurie Harper <la...@holoweb.net>.
Rick Mann wrote:
> Okay, I'll try to find a "hello world" JSF example. That might be enough
> for me to build on.
One series of articles from IBM that I found very helpful when I first
started looking at JSF (thanks Wendy for linking them!) can be found
here, if you're still looking for a good intro:
http://www-128.ibm.com/developerworks/views/java/libraryview.jsp?search_by=nonbelievers:
L.
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Advice for Struts expert wanting to try Shale?
Posted by Werner Punz <we...@gmx.at>.
Dakota Jack wrote:
> The view "controller" is not a controller in the Web-MVC sense and is
> completely misleading, in my opinion, Mark. So part of this just may be
> who's dog is in the hunt?
>
> The point of the tool-based and VB analogy is that JSF tries to hide from
> you, to do it for you, what other frameworks, like Struts, demand you know.
> This allows quick turnaround and allows the construction of tools. This was
> the charter for JSF. It is not a bug, it is deliberate. So, if this
> confuses a new person, at least it has the value of being accurate as hell.
Well in my opinion JSF is much closer to the traditional way of doing
user interfaces than Struts, most people who have a clear experience in
user interfaces probably grasp the page centric approach of JSF easier
than the enforced action centric approach of Struts.
The terms, component, Page, Backend Controller are visible in one way or
the other in most rich client uis, also the validation on component
levels, the events etc...
In one way the comparison to Visual Basic is valid, because it brings a
rich client approach to the page->action->page mix of html and struts.
But from a functionality point of view JSF is sort of Struts 2.0 because
the more you dive into the framework them more you see that basically
everything (sans client side validation) of Struts still is there, but
so much more and everything especially configurationwise a tad more
cleaned up and with less xml.
> So, if you want to use programmers with little experience and train them to
> use the inevitable tools, just like with the community college VB junkies,
> JSF is a good alternative. If you think a smaller cadre of thinking and
> knowing engineers is the way to go, like cs graduates who know Java or C++,
> then Struts is the way to go.
>
I do not think so, JSF is definitely not graspable by the first
community, because once you get out of the we have a set of component
level, things become more complicated than the usual visual tool user
can handle.
Struts never even tries to reach the visual level.
But does not cover all areas jsf covers. If you dive deeper into JSF
you can find that JSF partially was derived from Struts, but adds lots
of stuff to the mix.
But one thing for me in JSF is heavens sent, that you finally have a
huge number of components and a clear and good event system, the rest is
up to the taste, after all you cannot really change within the
boundaries of HTML how html behaves.
If you go the enforced model controller route or the non enforce model
view controller or model view route is up to personal taste.
> JSF is not more page centric than Struts. JSF is page centric. Struts is
> not page centric.
>
> Something has to take JSF from page to page, and this is called a "view
> controller" due to an unfortunate naming of a pattern having to do with
> views, pages. This, again, is NOT a controller as you find in Struts.
>
Actually it is the nav handler :-), it just happens that you have the
controller logic in the backend beans and thus you get an "action
controller" that way.
What you probably mean is the view handler, but that is something
entirely different, and nav and view handlers are replaceable parts.
> I personally would find my VB and C++ the most helpful. I always find
> heuristics the most helpful, unless you want to get bogged down in
> irrelevant detail, like "view controller". This is essentially the sort of
> choice you are making. VB is a tool based, dumbed down, "language". JSF is
> a tool based, dumbed down "framework". C++ is a full blown language.
> Struts is a full blown framework.
I assume you never had a serious look at jsf, judging a framework by its
tools and never look beyound is always bad ;-)
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Advice for Struts expert wanting to try Shale?
Posted by Dakota Jack <da...@gmail.com>.
The view "controller" is not a controller in the Web-MVC sense and is
completely misleading, in my opinion, Mark. So part of this just may be
who's dog is in the hunt?
The point of the tool-based and VB analogy is that JSF tries to hide from
you, to do it for you, what other frameworks, like Struts, demand you know.
This allows quick turnaround and allows the construction of tools. This was
the charter for JSF. It is not a bug, it is deliberate. So, if this
confuses a new person, at least it has the value of being accurate as hell.
So, if you want to use programmers with little experience and train them to
use the inevitable tools, just like with the community college VB junkies,
JSF is a good alternative. If you think a smaller cadre of thinking and
knowing engineers is the way to go, like cs graduates who know Java or C++,
then Struts is the way to go.
JSF is not more page centric than Struts. JSF is page centric. Struts is
not page centric.
Something has to take JSF from page to page, and this is called a "view
controller" due to an unfortunate naming of a pattern having to do with
views, pages. This, again, is NOT a controller as you find in Struts.
I personally would find my VB and C++ the most helpful. I always find
heuristics the most helpful, unless you want to get bogged down in
irrelevant detail, like "view controller". This is essentially the sort of
choice you are making. VB is a tool based, dumbed down, "language". JSF is
a tool based, dumbed down "framework". C++ is a full blown language.
Struts is a full blown framework.
On 1/7/06, Mark Lowe <me...@gmail.com> wrote:
>
> On 1/7/06, Dakota Jack <da...@gmail.com> wrote:
> > JSF is page centric rather than Action centric. There is no controller
> as
> > you understand that in Struts with JSF. JSF is for a tool based, dumbed
> > down, approach: JSF is to Struts as Visual Basic is to C++.
>
> JSF is more page centric than struts, but they aren't chalk and
> cheese. The view controller is still in the backing bean and then
> mapping of outcome to jsp is done via xml configuration. How page or
> controller centric you want jsf to be is upto you, this is where the
> diffence between JSF being a spec and struts a framework start being
> more visible.
>
> If I was asking how to get started with jsf and shale I'd find your VB
> vs C++ statement confusing and not very helpful at all.
>
> Mark
>
> >
> > On 1/6/06, Rick Mann <rm...@latencyzero.com> wrote:
> > >
> > > Thanks for the response, Craig. It's nice to get an answer from THE
> > > authority :-). Questions below...
> > >
> > > On Jan 6, 2006, at 5:16 PM, Craig McClanahan wrote:
> > >
> > > > I'd definitely ignore anything about prereleases of JSF 1.0 ...
> > > > that has
> > > > been out for nearly two years now. A good starting place for
> > > > general JSF
> > > > knowledge and information is <http://jsfcentral.com>. Kito does a
> > > > good job
> > > > of staying on top of the most recent articles and items of
> > > > interest. This,
> > > > by the way, is *exactly* the place to start before looking much at
> > > > Shale
> > > > itself -- Shale *srongly* presumes that you are familiar with JSF,
> > > > and what
> > > > it brings to the table all by itself, because it focuses on adding
> > > > value
> > > > around the edges. Without understanding those edges a little, it's
> > > > harder
> > > > to appreciate the benefits :-).
> > >
> > > Okay, I'll try to find a "hello world" JSF example. That might be
> > > enough for me to build on.
> > >
> > > A question comes up: what has happened to Tiles? Is it no longer a
> > > part of Struts? I'm still terribly unfamiliar with the new Struts
> > > website.
> > >
> > > Do I bother creating a nice Tiles hierarchy of layouts and tiles? Or
> > > is there some other way to get site L&F re-use?
> > >
> > > > Beyond the Shale web site[1], there's not a heck of a lot of stuff
> > > > yet. One
> > > > high level overview is the session I did at ApacheCon (reprised
> > > > from one
> > > > that David Geary and I did at JavaOne)[2] ... but the slides lose a
> > > > little
> > > > in the translation without the corresponding demo program, which is
> > > > not in a
> > > > shape that I'm quite ready to check in yet :-).
> > >
> > > Okay, I'll hold off worrying about Shale for now. Sounds like I can
> > > work it in easily enough when the time comes.
> > >
> > >
> > > Here's my big question: do I still think in terms of Struts Actions
> > > handling the business logic of my application (which they rarely do;
> > > they usually glue to the "real" biz code)? Or do I look to putting
> > > all that glue within JSF controllers?
> > >
> > > Thanks!
> > >
> > > --
> > > Rick
> > >
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> > > For additional commands, e-mail: user-help@struts.apache.org
> > >
> > >
> >
> >
> > --
> > "You can lead a horse to water but you cannot make it float on its
> back."
> > ~Dakota Jack~
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
--
"You can lead a horse to water but you cannot make it float on its back."
~Dakota Jack~
Re: Advice for Struts expert wanting to try Shale?
Posted by Craig McClanahan <cr...@apache.org>.
On 1/7/06, Craig McClanahan <cr...@apache.org> wrote:
> In a JSF application, there's actually two ways to implement classic Front
> Controller type functionality, such as "send the user to the logon page if
> they are not currently logged on":
>
Concrete examples will help make this clearer, so here are the pure-servlet
and pure-JSF ways to accomplish this:
* With a servlet Filter that gets invoked in front of the JSF controller
> (Shale has support for this). When
> Struts 1.0 was created, there was no such thing, so we had to provide
> this capability inside ActionServlet.
> Now, the container has a much more flexible mechanism that can work on
> either JSF requests or
> non-JSF requests.
>
import com.mycompany.mypackage.User;
import java.io.IOException;
import javax.servlet.Filter;
import javax.servlet.FilterChain;
import javax.servlet.FilterConfig;
import javax.servlet.RequestDispatcher;
import javax.servlet.ServletException;
import javax.servlet.ServletRequest;
import javax.servlet.ServletResponse;
public class LogonCheckFilter implements Filter {
// No initialization required
public void init(FiterConfig config) {}
// No finalization required
public void destroy() {}
// Process each incoming request this filter is mapped to
public void doFilter(ServletRequest request, ServletResponse response,
FilterChain chain) throws IOException, ServletException {
// Check for a user object in session scope
User user = (User)
((HttpServletRequest) request).getSession().getAttribute("user");
// NOTE - we do not need it for this use case, but we also have
access
// to the current request's parameters, headers, cookies, and so on
// If the user is not logged on, redirect to the logon page
if (user == null) {
// Do a RequestDispatch.forward() to display the logon page
instead of the requested page
RequestDispatcher rd = ((HttpServletRequest)
request).getRequestDispatcher("/logon.jsp");
rd.forward(request, response);
return;
}
// Otherwise, do the standard processing for this request
chain.doFilter(request, response);
}
}
* By using a JSF PhaseListener to interact with the JSF Lifecycle (which has
> Controller capabilities as well)
> This is the way most AJAX enabled JSF components interact with the
> server side of their asynchronous
> requests ... they submit a request to a URL mapped to FacesServlet, and
> a component-provided
> PhaseListener intercepts control after the Restore View phase has
> completed. But the point is clear ...
> the Lifecycle implementation plays a controller role as well, and you
> can customize its behavior with
> phase listeners quite easily.
>
>
import com.mycompany.mypackage.User;
import javax.faces.context.FacesContext;
import javax.faces.event.PhaseEvent;
import javax.faces.event.PhaseId;
import javax.faces.event.PhaseListener;
public class LogonCheckListener implements PhaseListener {
// Tell JSF which lifecycle phase(s) we are interested in
public PhaseId getPhaseId() {
return PhaseId.RESTORE_VIEW;
}
// No "before phase" processing required
public void beforePhase(PhaseEvent event) {}
// Perform the logon check after restore view has been completed
public void afterPhase(PhaseEvent event) {
// Check for a user object in session scope
FacesContext context = event.getFacesContext();
User user = (User)
context.getExternalContext().getSessionMap().get("user");
// NOTE - we do not need it for this use case, but we also have
access
// to the current request's parameters, headers, cookies, and so on,
// as well as the restored state of the component tree for the page
that
// is submitting this request, as of the last time it was rendered
// If the user is not logged on, redirect to the logon page
if (user == null) {
// Create the view for the logon page and render it
context.getApplication().getViewHandle().createView
(context, "/logon.jsp");
context.renderResponse();
return;
}
// Otherwise, do the standard processing for this request
; // No extra processing required
}
}
Both approaches are functionally equivalent, in that (when the user is not
logged on) they bypass the normal form submit processing and cause the logon
page to be rendered instead. If the user *is* already logged on, the
standard processing proceeds.
Craig
Re: [OT] Re: Advice for Struts expert wanting to try Shale?
Posted by Alexandre Poitras <al...@gmail.com>.
LOL ok last post in this thread, but this is pathetic. He hijacks the
majority of threads about Shale to say how JSF sucks compare to Struts. He
even says JSF is visual basic and Struts is C++, wich I can't believe he's
doesn't see as a provocative post. He's not polite and he's unrespectful to
a lot of people and yet he complains when people are tired of his attitude
and call him a Troll. I can't understand he didn't see that coming from
miles. Sorry, Dakota, I think your attitude is really offending and pitiful.
You brought this upon yourself. Email my boss if you want or sue me if you
want (I hope your lawyers knows the french civil code). Well, I apologize
for this post to the other people on this mailing list, I don't like to
critizice a person attitude publicly but I think he's going way too far now.
On 1/11/06, DGraham@evergreeninvestments.com <
DGraham@evergreeninvestments.com> wrote:
>
> Let me get this right, he _told on you_ ... as in tattletale??? That's
> just repugnant and pitiful.
> Did we not learn anything last year when Mark lost his job?
>
> -Dennis
>
>
>
>
> Dave Newton <ne...@pingsite.com>
> 01/11/2006 11:27 AM
> Please respond to
> "Struts Users Mailing List" <us...@struts.apache.org>
>
>
> To
> Struts Users Mailing List <us...@struts.apache.org>, Rob Freda
> <fr...@pingsite.com>
> cc
>
> Subject
> Re: [OT] Re: Advice for Struts expert wanting to try Shale?
>
>
>
>
>
>
> I'm thinking you _still_ don't know what "libel" is, but feel free to
> sue me.
>
> Leave my employer out of it. As we're fond of saying, "no jumping in."
> If you'd rather I posted only from one of my non-work email accounts I'm
> happy to do that as well if it makes you feel better.
>
> If you'd like to meet in person to discuss this issue I'm happy to oblige.
>
> And yes, I posted this to the group rather than you personally, because:
>
> a) you won't talk to me directly
> b) you felt so wronged that you emailed my boss rather than me
> b) I just like people to know what's going on behind the scenes
>
> Dave
>
> Dave Newton wrote:
>
> > Dakota Jack wrote:
> >
> >> Just so you know, Alexandre Poitras, and others with similar
> tendencies,
> >> calling someone a "troll" in a professional setting having to do with
> >> their
> >> occupation almost certainly is an actionable per se libel with presumed
> >> damages and linking the person doing the libel to any and all
> >> jurisdictions
> >> covered by this list.
> >
> > Okay, I'll bite: troll. Troll troll troll. Troll. Mind you, I'm not
> > calling you the mythological (perhaps quasi-mythological) creature from
> > fables, I'm calling you an internet troll as defined here:
> > http://en.wikipedia.org/wiki/Internet_troll.
> >
> > From time to time you post genuinely useful stuff; the rest of the time
> > you take four sentences to tell somebody how little they know and
> > attempt to pass it off as somehow being helpful, enlightening, or
> > educational... but it's not: it's mean-spirited and demeaning. You can
> > tell somebody you think they're wrong in much better ways. I have
> > personally developed a slew of ways of calling people stupid that allow
> > them the honor of thanking me for doing it afterwards. It's actually a
> > LOT more fun that way.
> >
> > I don't mentor people by telling them how little they know about a
> > technology or the relative merits of one versus another; that isn't
> > functional. I don't teach my students by pointing out how little they
> > know and making constant, somewhat passive-aggressive comments regarding
> > their lack of knowledge. I am supportive and encouraging: _that's_ what
> > makes an educator great, and I'm not even all that good.
> >
> > Of course, much of the negative commentary you write to and about people
> > that disagree with you, whether or not they're correct (I, at least,
> > believe you make perfectly valid points at times) might _also_ be
> > construed as libel, as defined by the _American and English Encylopedia
> > of Law_ as: "a malicious defamation expressed either by writing or
> > printing or by signs, pictures, effigies or the like; tending to blacken
> > the memory of one who is dead, or to impeach the honesty, integrity,
> > virtue or reputation, or to publish the natural or alleged defects of
> > one who is alive, thereby exposing him to public hatred, contempt,
> > ridicule or obloquy; or to cause him to be avoided or shunned or to
> > injure him in his office, business or occupation."
> >
> > There are several interesting bits contained within this definition that
> > warrant closer examination.
> >
> > 1) Malicious. I don't even consider _your_ negative posts malicious, I
> > just consider them rude and demeaning. I don't think I've ever seen a
> > truly malicious post, even including some of the more unsavory ones from
> > ex-listers gone awry ;)
> > 2) "[...] impeach the honesty, integrity [...]" If anyone should tread
> > lightly in this area it would have to be those that question the motives
> > of certain developers regarding certain technologies that some of us may
> > or may not like or approve of.
> > 3) If a post here ever caused anybody to be exposed to "public hatred,
> > contempt, ridicule or obloquy" I'd be impressed, as I really didn't
> > think our readership was that high.
> > 4) "[...] cause him to be avoided or shunned or to injure him [...]"
> > Have you noticed that the only posts of yours that people reply to are
> > the ones that either contain useful information, questions, etc. or are
> > dealing with somebody that hasn't learned to your mean, trolling ones?
> > The one that has been most exposed to public contempt, at least, appears
> > to be you, and the one most shunned in this (according to you)
> > "professional setting" is _you_.
> >
> > I believe you're smart and capable yet I see your posts in my inbox like
> > an accident on the side of the road: I don't want to look, because so
> > often there's blood and mayhem, but I feel compelled to. Occasionally I
> > am pleasantly surprised with an actual discussion. I'll admit a certain
> > amount of disappointment sometimes that there isn't another wonderful
> > flame-fest brewing, but I generally get over that fairly quickly.
> >
> >> This is not a chat room where idiocies and loose talk
> >> are the common fare. This is a professional setting.
> >
> > This is a mailing list, not an office. This is, at best, a
> > "professional-as-possible" setting. Would you use the language you use
> > against those who disgree with you in a "professional setting"? _I_ sure
> > wouldn't, and I wouldn't tolerate it from anybody that worked with me or
> > for me, either.
> >
> > Quite frankly, idiocies _do_ seem to be rather common fare, but that's
> > because people seem incapable of looking at documentation.
> >
> >> Sorry to have to discuss something other than the issues.
> >>
> >>
> > Why apologize THIS time?!
> >
> > Dave
> >
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> > For additional commands, e-mail: user-help@struts.apache.org
> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
>
>
--
Alexandre Poitras
Québec, Canada
RE: [OT] Re: Advice for Struts expert wanting to try Shale?
Posted by "David G. Friedman" <hu...@ix.netcom.com>.
>Let me get this right, he _told on you_ ... as in tattletale???
Opinion... If I were his employer, I would like to know what how he was behaving if:
1) He was doing/posting things from a corporate email address that might reflect badly on my company.
2) Spreading inflammatory comments while under my employ BUT using his own email address IF a search engine brought up
both sets of information simultaneously, thus reflecting badly on my company by bringing both of his references (us and
his) together in one unflattering light. It's called bad PR and it costs employers money.
Regards,
David
P.S. Still waiting for him to sue me... but I stopped holding my breath months ago because I was
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: [OT] Re: Advice for Struts expert wanting to try Shale?
Posted by Dave Newton <ne...@pingsite.com>.
DGraham@EvergreenInvestments.com wrote:
>Let me get this right, he _told on you_ ... as in tattletale???
>
Yeah :D
Dave
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: [OT] Re: Advice for Struts expert wanting to try Shale?
Posted by DG...@EvergreenInvestments.com.
Let me get this right, he _told on you_ ... as in tattletale??? That's
just repugnant and pitiful.
Did we not learn anything last year when Mark lost his job?
-Dennis
Dave Newton <ne...@pingsite.com>
01/11/2006 11:27 AM
Please respond to
"Struts Users Mailing List" <us...@struts.apache.org>
To
Struts Users Mailing List <us...@struts.apache.org>, Rob Freda
<fr...@pingsite.com>
cc
Subject
Re: [OT] Re: Advice for Struts expert wanting to try Shale?
I'm thinking you _still_ don't know what "libel" is, but feel free to
sue me.
Leave my employer out of it. As we're fond of saying, "no jumping in."
If you'd rather I posted only from one of my non-work email accounts I'm
happy to do that as well if it makes you feel better.
If you'd like to meet in person to discuss this issue I'm happy to oblige.
And yes, I posted this to the group rather than you personally, because:
a) you won't talk to me directly
b) you felt so wronged that you emailed my boss rather than me
b) I just like people to know what's going on behind the scenes
Dave
Dave Newton wrote:
> Dakota Jack wrote:
>
>> Just so you know, Alexandre Poitras, and others with similar
tendencies,
>> calling someone a "troll" in a professional setting having to do with
>> their
>> occupation almost certainly is an actionable per se libel with presumed
>> damages and linking the person doing the libel to any and all
>> jurisdictions
>> covered by this list.
>
> Okay, I'll bite: troll. Troll troll troll. Troll. Mind you, I'm not
> calling you the mythological (perhaps quasi-mythological) creature from
> fables, I'm calling you an internet troll as defined here:
> http://en.wikipedia.org/wiki/Internet_troll.
>
> From time to time you post genuinely useful stuff; the rest of the time
> you take four sentences to tell somebody how little they know and
> attempt to pass it off as somehow being helpful, enlightening, or
> educational... but it's not: it's mean-spirited and demeaning. You can
> tell somebody you think they're wrong in much better ways. I have
> personally developed a slew of ways of calling people stupid that allow
> them the honor of thanking me for doing it afterwards. It's actually a
> LOT more fun that way.
>
> I don't mentor people by telling them how little they know about a
> technology or the relative merits of one versus another; that isn't
> functional. I don't teach my students by pointing out how little they
> know and making constant, somewhat passive-aggressive comments regarding
> their lack of knowledge. I am supportive and encouraging: _that's_ what
> makes an educator great, and I'm not even all that good.
>
> Of course, much of the negative commentary you write to and about people
> that disagree with you, whether or not they're correct (I, at least,
> believe you make perfectly valid points at times) might _also_ be
> construed as libel, as defined by the _American and English Encylopedia
> of Law_ as: "a malicious defamation expressed either by writing or
> printing or by signs, pictures, effigies or the like; tending to blacken
> the memory of one who is dead, or to impeach the honesty, integrity,
> virtue or reputation, or to publish the natural or alleged defects of
> one who is alive, thereby exposing him to public hatred, contempt,
> ridicule or obloquy; or to cause him to be avoided or shunned or to
> injure him in his office, business or occupation."
>
> There are several interesting bits contained within this definition that
> warrant closer examination.
>
> 1) Malicious. I don't even consider _your_ negative posts malicious, I
> just consider them rude and demeaning. I don't think I've ever seen a
> truly malicious post, even including some of the more unsavory ones from
> ex-listers gone awry ;)
> 2) "[...] impeach the honesty, integrity [...]" If anyone should tread
> lightly in this area it would have to be those that question the motives
> of certain developers regarding certain technologies that some of us may
> or may not like or approve of.
> 3) If a post here ever caused anybody to be exposed to "public hatred,
> contempt, ridicule or obloquy" I'd be impressed, as I really didn't
> think our readership was that high.
> 4) "[...] cause him to be avoided or shunned or to injure him [...]"
> Have you noticed that the only posts of yours that people reply to are
> the ones that either contain useful information, questions, etc. or are
> dealing with somebody that hasn't learned to your mean, trolling ones?
> The one that has been most exposed to public contempt, at least, appears
> to be you, and the one most shunned in this (according to you)
> "professional setting" is _you_.
>
> I believe you're smart and capable yet I see your posts in my inbox like
> an accident on the side of the road: I don't want to look, because so
> often there's blood and mayhem, but I feel compelled to. Occasionally I
> am pleasantly surprised with an actual discussion. I'll admit a certain
> amount of disappointment sometimes that there isn't another wonderful
> flame-fest brewing, but I generally get over that fairly quickly.
>
>> This is not a chat room where idiocies and loose talk
>> are the common fare. This is a professional setting.
>
> This is a mailing list, not an office. This is, at best, a
> "professional-as-possible" setting. Would you use the language you use
> against those who disgree with you in a "professional setting"? _I_ sure
> wouldn't, and I wouldn't tolerate it from anybody that worked with me or
> for me, either.
>
> Quite frankly, idiocies _do_ seem to be rather common fare, but that's
> because people seem incapable of looking at documentation.
>
>> Sorry to have to discuss something other than the issues.
>>
>>
> Why apologize THIS time?!
>
> Dave
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: [OT] Re: Advice for Struts expert wanting to try Shale?
Posted by Dave Newton <ne...@pingsite.com>.
I'm thinking you _still_ don't know what "libel" is, but feel free to
sue me.
Leave my employer out of it. As we're fond of saying, "no jumping in."
If you'd rather I posted only from one of my non-work email accounts I'm
happy to do that as well if it makes you feel better.
If you'd like to meet in person to discuss this issue I'm happy to oblige.
And yes, I posted this to the group rather than you personally, because:
a) you won't talk to me directly
b) you felt so wronged that you emailed my boss rather than me
b) I just like people to know what's going on behind the scenes
Dave
Dave Newton wrote:
> Dakota Jack wrote:
>
>> Just so you know, Alexandre Poitras, and others with similar tendencies,
>> calling someone a "troll" in a professional setting having to do with
>> their
>> occupation almost certainly is an actionable per se libel with presumed
>> damages and linking the person doing the libel to any and all
>> jurisdictions
>> covered by this list.
>
> Okay, I'll bite: troll. Troll troll troll. Troll. Mind you, I'm not
> calling you the mythological (perhaps quasi-mythological) creature from
> fables, I'm calling you an internet troll as defined here:
> http://en.wikipedia.org/wiki/Internet_troll.
>
> From time to time you post genuinely useful stuff; the rest of the time
> you take four sentences to tell somebody how little they know and
> attempt to pass it off as somehow being helpful, enlightening, or
> educational... but it's not: it's mean-spirited and demeaning. You can
> tell somebody you think they're wrong in much better ways. I have
> personally developed a slew of ways of calling people stupid that allow
> them the honor of thanking me for doing it afterwards. It's actually a
> LOT more fun that way.
>
> I don't mentor people by telling them how little they know about a
> technology or the relative merits of one versus another; that isn't
> functional. I don't teach my students by pointing out how little they
> know and making constant, somewhat passive-aggressive comments regarding
> their lack of knowledge. I am supportive and encouraging: _that's_ what
> makes an educator great, and I'm not even all that good.
>
> Of course, much of the negative commentary you write to and about people
> that disagree with you, whether or not they're correct (I, at least,
> believe you make perfectly valid points at times) might _also_ be
> construed as libel, as defined by the _American and English Encylopedia
> of Law_ as: "a malicious defamation expressed either by writing or
> printing or by signs, pictures, effigies or the like; tending to blacken
> the memory of one who is dead, or to impeach the honesty, integrity,
> virtue or reputation, or to publish the natural or alleged defects of
> one who is alive, thereby exposing him to public hatred, contempt,
> ridicule or obloquy; or to cause him to be avoided or shunned or to
> injure him in his office, business or occupation."
>
> There are several interesting bits contained within this definition that
> warrant closer examination.
>
> 1) Malicious. I don't even consider _your_ negative posts malicious, I
> just consider them rude and demeaning. I don't think I've ever seen a
> truly malicious post, even including some of the more unsavory ones from
> ex-listers gone awry ;)
> 2) "[...] impeach the honesty, integrity [...]" If anyone should tread
> lightly in this area it would have to be those that question the motives
> of certain developers regarding certain technologies that some of us may
> or may not like or approve of.
> 3) If a post here ever caused anybody to be exposed to "public hatred,
> contempt, ridicule or obloquy" I'd be impressed, as I really didn't
> think our readership was that high.
> 4) "[...] cause him to be avoided or shunned or to injure him [...]"
> Have you noticed that the only posts of yours that people reply to are
> the ones that either contain useful information, questions, etc. or are
> dealing with somebody that hasn't learned to your mean, trolling ones?
> The one that has been most exposed to public contempt, at least, appears
> to be you, and the one most shunned in this (according to you)
> "professional setting" is _you_.
>
> I believe you're smart and capable yet I see your posts in my inbox like
> an accident on the side of the road: I don't want to look, because so
> often there's blood and mayhem, but I feel compelled to. Occasionally I
> am pleasantly surprised with an actual discussion. I'll admit a certain
> amount of disappointment sometimes that there isn't another wonderful
> flame-fest brewing, but I generally get over that fairly quickly.
>
>> This is not a chat room where idiocies and loose talk
>> are the common fare. This is a professional setting.
>
> This is a mailing list, not an office. This is, at best, a
> "professional-as-possible" setting. Would you use the language you use
> against those who disgree with you in a "professional setting"? _I_ sure
> wouldn't, and I wouldn't tolerate it from anybody that worked with me or
> for me, either.
>
> Quite frankly, idiocies _do_ seem to be rather common fare, but that's
> because people seem incapable of looking at documentation.
>
>> Sorry to have to discuss something other than the issues.
>>
>>
> Why apologize THIS time?!
>
> Dave
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
[OT] Re: Advice for Struts expert wanting to try Shale?
Posted by Dave Newton <ne...@pingsite.com>.
Dakota Jack wrote:
>Just so you know, Alexandre Poitras, and others with similar tendencies,
>calling someone a "troll" in a professional setting having to do with their
>occupation almost certainly is an actionable per se libel with presumed
>damages and linking the person doing the libel to any and all jurisdictions
>covered by this list.
>
Okay, I'll bite: troll. Troll troll troll. Troll. Mind you, I'm not
calling you the mythological (perhaps quasi-mythological) creature from
fables, I'm calling you an internet troll as defined here:
http://en.wikipedia.org/wiki/Internet_troll.
From time to time you post genuinely useful stuff; the rest of the time
you take four sentences to tell somebody how little they know and
attempt to pass it off as somehow being helpful, enlightening, or
educational... but it's not: it's mean-spirited and demeaning. You can
tell somebody you think they're wrong in much better ways. I have
personally developed a slew of ways of calling people stupid that allow
them the honor of thanking me for doing it afterwards. It's actually a
LOT more fun that way.
I don't mentor people by telling them how little they know about a
technology or the relative merits of one versus another; that isn't
functional. I don't teach my students by pointing out how little they
know and making constant, somewhat passive-aggressive comments regarding
their lack of knowledge. I am supportive and encouraging: _that's_ what
makes an educator great, and I'm not even all that good.
Of course, much of the negative commentary you write to and about people
that disagree with you, whether or not they're correct (I, at least,
believe you make perfectly valid points at times) might _also_ be
construed as libel, as defined by the _American and English Encylopedia
of Law_ as: "a malicious defamation expressed either by writing or
printing or by signs, pictures, effigies or the like; tending to blacken
the memory of one who is dead, or to impeach the honesty, integrity,
virtue or reputation, or to publish the natural or alleged defects of
one who is alive, thereby exposing him to public hatred, contempt,
ridicule or obloquy; or to cause him to be avoided or shunned or to
injure him in his office, business or occupation."
There are several interesting bits contained within this definition that
warrant closer examination.
1) Malicious. I don't even consider _your_ negative posts malicious, I
just consider them rude and demeaning. I don't think I've ever seen a
truly malicious post, even including some of the more unsavory ones from
ex-listers gone awry ;)
2) "[...] impeach the honesty, integrity [...]" If anyone should tread
lightly in this area it would have to be those that question the motives
of certain developers regarding certain technologies that some of us may
or may not like or approve of.
3) If a post here ever caused anybody to be exposed to "public hatred,
contempt, ridicule or obloquy" I'd be impressed, as I really didn't
think our readership was that high.
4) "[...] cause him to be avoided or shunned or to injure him [...]"
Have you noticed that the only posts of yours that people reply to are
the ones that either contain useful information, questions, etc. or are
dealing with somebody that hasn't learned to your mean, trolling ones?
The one that has been most exposed to public contempt, at least, appears
to be you, and the one most shunned in this (according to you)
"professional setting" is _you_.
I believe you're smart and capable yet I see your posts in my inbox like
an accident on the side of the road: I don't want to look, because so
often there's blood and mayhem, but I feel compelled to. Occasionally I
am pleasantly surprised with an actual discussion. I'll admit a certain
amount of disappointment sometimes that there isn't another wonderful
flame-fest brewing, but I generally get over that fairly quickly.
>This is not a chat room where idiocies and loose talk
>are the common fare. This is a professional setting.
>
This is a mailing list, not an office. This is, at best, a
"professional-as-possible" setting. Would you use the language you use
against those who disgree with you in a "professional setting"? _I_ sure
wouldn't, and I wouldn't tolerate it from anybody that worked with me or
for me, either.
Quite frankly, idiocies _do_ seem to be rather common fare, but that's
because people seem incapable of looking at documentation.
>Sorry to have to discuss something other than the issues.
>
>
Why apologize THIS time?!
Dave
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Advice for Struts expert wanting to try Shale?
Posted by Dakota Jack <da...@gmail.com>.
Just so you know, Alexandre Poitras, and others with similar tendencies,
calling someone a "troll" in a professional setting having to do with their
occupation almost certainly is an actionable per se libel with presumed
damages and linking the person doing the libel to any and all jurisdictions
covered by this list. This is not a chat room where idiocies and loose talk
are the common fare. This is a professional setting. I would keep that in
mind if I were you. This is not some free-fire zone where you can treat
people outside the law. If you have your opinions, that is well and good.
Don't negate mine with statements like this unless you want to have to prove
the matter in a court of law. This is made public rather than to you
personally to give other similarly lacking in enlightenment fair warning.
Sorry to have to discuss something other than the issues.
On 1/7/06, Alexandre Poitras <al...@gmail.com> wrote:
>
> Ok can we all ignore the troll and go back to the original subject...
>
> Like Craig pointed out Rick, I think you should play around with JSF
> first and then Shale.
> The IBM serie "Cleared FUD about JSF" is a good introduction to. I
> think one of the previous poster posted the link.
>
> Shale is decomposed in modules so it not so hard to get a grab on the
> functionalities, one type at a time. Actually, it's not very complex
> except maybe the Clay plugin wich does require some time to understand
> but using it or Facelets instead of JSP is worth the troubles in my
> opinion.
>
> Anyway, I have been playing with JSF for sometimes now and here's the
> various differences against Struts I've found :
>
> - ActionForm and Action (more Dispatch Action in fact) are replaced by
> backing beans.
> No more copy between ActionForm and Domain objets or data transfer
> objects are necessary.
>
> -The event model is fine-grained instead of coarse-grained. In struts,
> you don't have a true event model and the only event is receive a
> request and the *listeners* Action, are application wide.
>
> In JSF, the basic event listener are registered on a single component
> instead of the complete application. You have two basic different
> events (ActionEvent and ValueChangeEvent) and the event listeners all
> receive an event object representing the event context. Plus, in JSF
> you can register more then one listeners on a component so no need for
> Action chaining and the troubles coming along with it. Note that the
> action events listeners are not responsible to choose the next view
> like the actions are in Struts. It's quite a change but you get used
> to it very fast in the end and this way your backing beans (most of
> the time, they are the action listeners) are easier to reuse. Overall,
> you can understand this quite fast if you are use to program Swing
> applications.
>
> - The binding mechanism is way more powerful then Struts one and I
> think this is where JSF really shine. In struts, you could only match
> form beans properties to forms html tags and it was complex to bind
> complex forms. In JSF, you can use EL value bindings or method
> bindings expressions. It is really great in my mind and very simple at
> the same time, thank to IoC and managed beans.
>
> - Finally, JSF has a component model and so reusing is very easy. The
> components hide most of the complexity to the developper (ugly
> javascript for exemple). Learning to developp components is what take
> time to learn, but you can get started quite fast if you just want to
> use it first. At least, there are a lot of exemples available.
>
> - One last thing, since the data and method bindings are specified in
> the "jsp/html/whatever technologie you use for view" page and the
> navigation is specified globally in the configuration file (not per
> action like in Struts), it is quite easy to follow the application
> flow. It was something that was annoying me sometimes with Struts, lot
> of places to look to find where the executed code is located.
>
> I hope it's help and since I am far from considering me a JSF expert,
> anyone can feel free to correct me. And please be tolerant about my
> english since I am not a native speaker and it's quite a long post :)
>
> On a side note for people having experience developping custom
> components, what annoys me so far in JSF is the model package, in fact
> the SelectItem class. There are no model objets for action components
> (like you need for a menu or navigation panel) and no universal
> components (UISelectItem and UISelectItems) for specifying the model.
> You need one for each component and it is quite a pain in the a.. to
> code those again and again. Anyway, it always possible to develop your
> own model hierarchy and use an adaptor to make SelectItem compatible
> with it. As anyone had the same problem so far? If it is the case,
> maybe a solution could be part of the future commons-jsf package that
> have been discussed in the past. I am working on something around this
> problem so I could probably submit it once I'm done.
>
> On 1/7/06, Dakota Jack <da...@gmail.com> wrote:
> > LOL I gave him the very same answer that you did, including the same
> > citations. The difference is that I did not gloss over the confusion
> you
> > have systematically engendered by not just owning up to the differences
> from
> > day one. You don't have to love something to explain it. Otherwise,
> who
> > would have known about the ugly duckling?
> >
> > On 1/7/06, Craig McClanahan <cr...@apache.org> wrote:
> > >
> > >
> > >
> > > If you are familiar with Core J2EE Patterns terminology, you'll find
> it
> > > easiest to understand JSF and Shale in terms of the View Helper[1]
> > > pattern,
> > > where the helper items are the JSF component tags and your backing
> beans,
> > > and the Dispatcher View[2] pattern, which combines the Front
> Controller[3]
> > > and View Helper[1] patterns together. In the Dispatcher View sequence
> > > diagram (Figure 7.25) the roles and responsibilities match up like
> this:
> > > Don't expect much help from someone who doesn't seem to care much for
> > > either
> > > JSF or Shale :-).
> > >
> > > Mark
> > >
> > >
> > > Craig
> > >
> > > [1]
> > >
> http://java.sun.com/blueprints/corej2eepatterns/Patterns/ViewHelper.html
> > > [2]
> > >
> > >
> http://java.sun.com/blueprints/corej2eepatterns/Patterns/DispatcherView.html
> > > [3]
> > >
> > >
> http://java.sun.com/blueprints/corej2eepatterns/Patterns/FrontController.html
> > >
> > >
> >
> >
> > --
> > "You can lead a horse to water but you cannot make it float on its
> back."
> > ~Dakota Jack~
> >
> >
>
>
> --
> Alexandre Poitras
> Québec, Canada
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
--
"You can lead a horse to water but you cannot make it float on its back."
~Dakota Jack~
Re: Advice for Struts expert wanting to try Shale?
Posted by Alexandre Poitras <al...@gmail.com>.
Sorry to repost this, but I wanted to know if I was the only one facing this
difficulty and if it's the case how to avoid it. Any thougts?
On 1/8/06, Alexandre Poitras <al...@gmail.com> wrote:
>
> Just a small correction below :
>
> On 1/8/06, Alexandre Poitras <al...@gmail.com> wrote:
> > I am developping a navigation panel like the panel2 from tomahawk (I
> > had to offer some more features) and I like the way you can embedd
> > some navigation items tags (NavigationItem, NavigationItems) inside
> > the navigation tag to specify the different elements of the panel.
> > Since the navigation model elements need some more attributes then
> > SelectItem like an action attribute (supporting MethodBinding of
> > course), you end up developping some custom models elements just
> > adding some more attributes. I think this part is alright, I don't
> > want to use something generic like DynaFormBean in Struts but I think
> > some base model elements could be standardized like a base class Item
> > and some subclasses like SelectItem and ActionItem (I read somewhere
> > there something similar in Oracle ADF components, maybe I should take
> > a look).
> >
> > The problem I see here is you have to implement for each kind of
> > model, two custom UIxxxItem and UIxxxItems components so you can end
> > up with a lot of redundant UI components. This problem is quite
> > familiar in the OO world and it is usually solved elegantly by the
> > Bridge pattern, where here model elements are the abstraction
> > hierarchy and the UIxxxItem and UIxxxItems are the
> > implementations specific.
>
> I mean the inverse, he UIxxxItem and UIxxxItems are the
> abstraction hierarchy and the model elements the implementation hierarchy.
>
> >So what I would like is to be able to always use the same UI
> > components to specify the model of a parent UI component. What I am
> > doing right now, is whenever a component have a model defined by child
> > elements, it implements a custom interface having a method returning
> > the model class it supports and making sure all model elements have a
> > constructor taking a properties map as an input (in case the element
> > must be built from the UIxxxItem properties). Then I have developped a
> > custom iterator capable of going throught any UI component model
> > implemented by those standard model UI components. Maybe someone have
> > a better design to propose me but it seems to do the trick for the
> > moment. What do you think?
> >
> > Of course with JSP you need to developp a lot of custom tags but I
> > guess not with Clay or facelets :))
> >
> > Here's the link to the Tomahawk panel I was refering to :
> > http://www.irian.at/myfaces/panelnavigation_2.jsp.source
> >
> > On 1/8/06, Craig McClanahan <cr...@apache.org> wrote:
> > > Just a couple of comments intermixed below.
> > >
> > > On 1/7/06, Alexandre Poitras < alexandre.poitras@gmail.com> wrote:
> > > >
> > > > Ok can we all ignore the troll and go back to the original
> subject...
> > > >
> > > > Like Craig pointed out Rick, I think you should play around with JSF
>
> > > > first and then Shale.
> > > > The IBM serie "Cleared FUD about JSF" is a good introduction to. I
> > > > think one of the previous poster posted the link.
> > > >
> > > > Shale is decomposed in modules so it not so hard to get a grab on
> the
> > > > functionalities, one type at a time. Actually, it's not very complex
> > > > except maybe the Clay plugin wich does require some time to
> understand
> > > > but using it or Facelets instead of JSP is worth the troubles in my
> > > > opinion.
> > > >
> > > > Anyway, I have been playing with JSF for sometimes now and here's
> the
> > > > various differences against Struts I've found :
> > > >
> > > > - ActionForm and Action (more Dispatch Action in fact) are replaced
> by
> > > > backing beans.
> > > > No more copy between ActionForm and Domain objets or data transfer
> > > > objects are necessary.
> > > >
> > > > -The event model is fine-grained instead of coarse-grained. In
> struts,
> > > > you don't have a true event model and the only event is receive a
> > > > request and the *listeners* Action, are application wide.
> > > >
> > > > In JSF, the basic event listener are registered on a single
> component
> > > > instead of the complete application. You have two basic different
> > > > events (ActionEvent and ValueChangeEvent) and the event listeners
> all
> > > > receive an event object representing the event context.
> > >
> > >
> > > While these are the only two events defined in the standard, it is
> perfectly
> > > feasible for JSF components to define their own events, and their own
> event
> > > handlers, using the same basic infrastructure.
> > >
> > > Plus, in JSF
> > > > you can register more then one listeners on a component so no need
> for
> > > > Action chaining and the troubles coming along with it. Note that the
> > > > action events listeners are not responsible to choose the next view
> > > > like the actions are in Struts. It's quite a change but you get used
>
> > > > to it very fast in the end and this way your backing beans (most of
> > > > the time, they are the action listeners) are easier to reuse.
> Overall,
> > > > you can understand this quite fast if you are use to program Swing
> > > > applications.
> > >
> > >
> > > I actually wish there wasn't be so much difference here :-(. In the
> > > original vision of Struts, the idea of an ActionForward was very much
> to
> > > describe an *outcome* ("this is what happened"), not a *destination*
> ("this
> > > is where to go next"). Unfortunately, most Struts developers don't
> use
> > > forwards that way -- and you can make exactly the same "mistake" :-)
> when
> > > using logical outcomes in JSF.
> > >
> > > - The binding mechanism is way more powerful then Struts one and I
> > > > think this is where JSF really shine. In struts, you could only
> match
> > > > form beans properties to forms html tags and it was complex to bind
> > > > complex forms. In JSF, you can use EL value bindings or method
> > > > bindings expressions. It is really great in my mind and very simple
> at
> > > > the same time, thank to IoC and managed beans.
> > >
> > >
> > > The synergy of the managed beans facility is pretty nice ...
> especially when
> > > you realize you can use bindings on *any* property of *any* component,
> not
> > > just on the "value" property of an input component.
> > >
> > > - Finally, JSF has a component model and so reusing is very easy. The
> > > > components hide most of the complexity to the developper (ugly
> > > > javascript for exemple). Learning to developp components is what
> take
> > > > time to learn, but you can get started quite fast if you just want
> to
> > > > use it first. At least, there are a lot of exemples available.
> > > >
> > > > - One last thing, since the data and method bindings are specified
> in
> > > > the "jsp/html/whatever technologie you use for view" page and the
> > > > navigation is specified globally in the configuration file (not per
> > > > action like in Struts), it is quite easy to follow the application
> > > > flow. It was something that was annoying me sometimes with Struts,
> lot
> > > > of places to look to find where the executed code is located.
> > >
> > >
> > > In both environments, the navigation rules are defined globally. The
> > > difference in granularity is how a navigation rule is selected:
> > >
> > > * In Struts, it's based solely on the outcome returned by a particular
>
> > > action
> > > (which can be defined either globally or locally).
> > >
> > > * In JSF, it's based (at least for the standard navigation handler;
> you can
> > > replace
> > > this if you want something different) on three criteria:
> > > - What page am I currently on?
> > > - Which action method was executed?
> > > - What logical outcome was returned by the executed method?
> > >
> > > In the JSF case, there are wildcarding capabilities for navigation
> that also
> > > let you be pretty concise in what you actually have to specify for
> common
> > > cases.
> > >
> > > I hope it's help and since I am far from considering me a JSF expert,
> > > > anyone can feel free to correct me. And please be tolerant about my
> > > > english since I am not a native speaker and it's quite a long post
> :)
> > >
> > >
> > > You're doing great ... once you get me past a restaurant menu, my
> grasp of
> > > French is *really* limited :-).
> > >
> > > On a side note for people having experience developping custom
> > > > components, what annoys me so far in JSF is the model package, in
> fact
> > > > the SelectItem class. There are no model objets for action
> components
> > > > (like you need for a menu or navigation panel) and no universal
> > > > components (UISelectItem and UISelectItems) for specifying the
> model.
> > > > You need one for each component and it is quite a pain in the a.. to
>
> > > > code those again and again. Anyway, it always possible to develop
> your
> > > > own model hierarchy and use an adaptor to make SelectItem compatible
> > > > with it. As anyone had the same problem so far? If it is the case,
> > > > maybe a solution could be part of the future commons-jsf package
> that
> > > > have been discussed in the past. I am working on something around
> this
> > > > problem so I could probably submit it once I'm done.
> > >
> > >
> > > Could you describe a little more what you think a model object for
> action
> > > components should do? One of the things I like best about method
> bindings
> > > is that you do *not* have to conform to a particular interface -- you
> can
> > > point a submit button (or the node of a tree control, for example) at
> any
> > > method on any bean class that has the right method sigature. I've
> seen some
> > > pretty sophisticated menu and tree components that leverage this,
> without
> > > seeming to feel any pain, so I'd be interested in where you see the
> > > limitations.
> > >
> > > Craig
> > >
> > >
> >
> >
> > --
> > Alexandre Poitras
> > Qu�bec, Canada
> >
>
>
> --
> Alexandre Poitras
> Qu�bec, Canada
>
--
Alexandre Poitras
Québec, Canada
Re: Advice for Struts expert wanting to try Shale?
Posted by Alexandre Poitras <al...@gmail.com>.
Just a small correction below :
On 1/8/06, Alexandre Poitras <al...@gmail.com> wrote:
> I am developping a navigation panel like the panel2 from tomahawk (I
> had to offer some more features) and I like the way you can embedd
> some navigation items tags (NavigationItem, NavigationItems) inside
> the navigation tag to specify the different elements of the panel.
> Since the navigation model elements need some more attributes then
> SelectItem like an action attribute (supporting MethodBinding of
> course), you end up developping some custom models elements just
> adding some more attributes. I think this part is alright, I don't
> want to use something generic like DynaFormBean in Struts but I think
> some base model elements could be standardized like a base class Item
> and some subclasses like SelectItem and ActionItem (I read somewhere
> there something similar in Oracle ADF components, maybe I should take
> a look).
>
> The problem I see here is you have to implement for each kind of
> model, two custom UIxxxItem and UIxxxItems components so you can end
> up with a lot of redundant UI components. This problem is quite
> familiar in the OO world and it is usually solved elegantly by the
> Bridge pattern, where here model elements are the abstraction
> hierarchy and the UIxxxItem and UIxxxItems are the
> implementations specific.
I mean the inverse, he UIxxxItem and UIxxxItems are the
abstraction hierarchy and the model elements the implementation hierarchy.
>So what I would like is to be able to always use the same UI
> components to specify the model of a parent UI component. What I am
> doing right now, is whenever a component have a model defined by child
> elements, it implements a custom interface having a method returning
> the model class it supports and making sure all model elements have a
> constructor taking a properties map as an input (in case the element
> must be built from the UIxxxItem properties). Then I have developped a
> custom iterator capable of going throught any UI component model
> implemented by those standard model UI components. Maybe someone have
> a better design to propose me but it seems to do the trick for the
> moment. What do you think?
>
> Of course with JSP you need to developp a lot of custom tags but I
> guess not with Clay or facelets :))
>
> Here's the link to the Tomahawk panel I was refering to :
> http://www.irian.at/myfaces/panelnavigation_2.jsp.source
>
> On 1/8/06, Craig McClanahan <cr...@apache.org> wrote:
> > Just a couple of comments intermixed below.
> >
> > On 1/7/06, Alexandre Poitras <al...@gmail.com> wrote:
> > >
> > > Ok can we all ignore the troll and go back to the original subject...
> > >
> > > Like Craig pointed out Rick, I think you should play around with JSF
> > > first and then Shale.
> > > The IBM serie "Cleared FUD about JSF" is a good introduction to. I
> > > think one of the previous poster posted the link.
> > >
> > > Shale is decomposed in modules so it not so hard to get a grab on the
> > > functionalities, one type at a time. Actually, it's not very complex
> > > except maybe the Clay plugin wich does require some time to understand
> > > but using it or Facelets instead of JSP is worth the troubles in my
> > > opinion.
> > >
> > > Anyway, I have been playing with JSF for sometimes now and here's the
> > > various differences against Struts I've found :
> > >
> > > - ActionForm and Action (more Dispatch Action in fact) are replaced by
> > > backing beans.
> > > No more copy between ActionForm and Domain objets or data transfer
> > > objects are necessary.
> > >
> > > -The event model is fine-grained instead of coarse-grained. In struts,
> > > you don't have a true event model and the only event is receive a
> > > request and the *listeners* Action, are application wide.
> > >
> > > In JSF, the basic event listener are registered on a single component
> > > instead of the complete application. You have two basic different
> > > events (ActionEvent and ValueChangeEvent) and the event listeners all
> > > receive an event object representing the event context.
> >
> >
> > While these are the only two events defined in the standard, it is
perfectly
> > feasible for JSF components to define their own events, and their own
event
> > handlers, using the same basic infrastructure.
> >
> > Plus, in JSF
> > > you can register more then one listeners on a component so no need for
> > > Action chaining and the troubles coming along with it. Note that the
> > > action events listeners are not responsible to choose the next view
> > > like the actions are in Struts. It's quite a change but you get used
> > > to it very fast in the end and this way your backing beans (most of
> > > the time, they are the action listeners) are easier to reuse. Overall,
> > > you can understand this quite fast if you are use to program Swing
> > > applications.
> >
> >
> > I actually wish there wasn't be so much difference here :-(. In the
> > original vision of Struts, the idea of an ActionForward was very much to
> > describe an *outcome* ("this is what happened"), not a *destination*
("this
> > is where to go next"). Unfortunately, most Struts developers don't use
> > forwards that way -- and you can make exactly the same "mistake" :-)
when
> > using logical outcomes in JSF.
> >
> > - The binding mechanism is way more powerful then Struts one and I
> > > think this is where JSF really shine. In struts, you could only match
> > > form beans properties to forms html tags and it was complex to bind
> > > complex forms. In JSF, you can use EL value bindings or method
> > > bindings expressions. It is really great in my mind and very simple at
> > > the same time, thank to IoC and managed beans.
> >
> >
> > The synergy of the managed beans facility is pretty nice ... especially
when
> > you realize you can use bindings on *any* property of *any* component,
not
> > just on the "value" property of an input component.
> >
> > - Finally, JSF has a component model and so reusing is very easy. The
> > > components hide most of the complexity to the developper (ugly
> > > javascript for exemple). Learning to developp components is what take
> > > time to learn, but you can get started quite fast if you just want to
> > > use it first. At least, there are a lot of exemples available.
> > >
> > > - One last thing, since the data and method bindings are specified in
> > > the "jsp/html/whatever technologie you use for view" page and the
> > > navigation is specified globally in the configuration file (not per
> > > action like in Struts), it is quite easy to follow the application
> > > flow. It was something that was annoying me sometimes with Struts, lot
> > > of places to look to find where the executed code is located.
> >
> >
> > In both environments, the navigation rules are defined globally. The
> > difference in granularity is how a navigation rule is selected:
> >
> > * In Struts, it's based solely on the outcome returned by a particular
> > action
> > (which can be defined either globally or locally).
> >
> > * In JSF, it's based (at least for the standard navigation handler; you
can
> > replace
> > this if you want something different) on three criteria:
> > - What page am I currently on?
> > - Which action method was executed?
> > - What logical outcome was returned by the executed method?
> >
> > In the JSF case, there are wildcarding capabilities for navigation that
also
> > let you be pretty concise in what you actually have to specify for
common
> > cases.
> >
> > I hope it's help and since I am far from considering me a JSF expert,
> > > anyone can feel free to correct me. And please be tolerant about my
> > > english since I am not a native speaker and it's quite a long post :)
> >
> >
> > You're doing great ... once you get me past a restaurant menu, my grasp
of
> > French is *really* limited :-).
> >
> > On a side note for people having experience developping custom
> > > components, what annoys me so far in JSF is the model package, in fact
> > > the SelectItem class. There are no model objets for action components
> > > (like you need for a menu or navigation panel) and no universal
> > > components (UISelectItem and UISelectItems) for specifying the model.
> > > You need one for each component and it is quite a pain in the a.. to
> > > code those again and again. Anyway, it always possible to develop your
> > > own model hierarchy and use an adaptor to make SelectItem compatible
> > > with it. As anyone had the same problem so far? If it is the case,
> > > maybe a solution could be part of the future commons-jsf package that
> > > have been discussed in the past. I am working on something around this
> > > problem so I could probably submit it once I'm done.
> >
> >
> > Could you describe a little more what you think a model object for
action
> > components should do? One of the things I like best about method
bindings
> > is that you do *not* have to conform to a particular interface -- you
can
> > point a submit button (or the node of a tree control, for example) at
any
> > method on any bean class that has the right method sigature. I've seen
some
> > pretty sophisticated menu and tree components that leverage this,
without
> > seeming to feel any pain, so I'd be interested in where you see the
> > limitations.
> >
> > Craig
> >
> >
>
>
> --
> Alexandre Poitras
> Québec, Canada
>
--
Alexandre Poitras
Québec, Canada
Re: Advice for Struts expert wanting to try Shale?
Posted by Alexandre Poitras <al...@gmail.com>.
I am developping a navigation panel like the panel2 from tomahawk (I
had to offer some more features) and I like the way you can embedd
some navigation items tags (NavigationItem, NavigationItems) inside
the navigation tag to specify the different elements of the panel.
Since the navigation model elements need some more attributes then
SelectItem like an action attribute (supporting MethodBinding of
course), you end up developping some custom models elements just
adding some more attributes. I think this part is alright, I don't
want to use something generic like DynaFormBean in Struts but I think
some base model elements could be standardized like a base class Item
and some subclasses like SelectItem and ActionItem (I read somewhere
there something similar in Oracle ADF components, maybe I should take
a look).
The problem I see here is you have to implement for each kind of
model, two custom UIxxxItem and UIxxxItems components so you can end
up with a lot of redundant UI components. This problem is quite
familiar in the OO world and it is usually solved elegantly by the
Bridge pattern, where here model elements are the abstraction
hierarchy and the UIxxxItem and UIxxxItems are the implementations
specific. So what I would like is to be able to always use the same UI
components to specify the model of a parent UI component. What I am
doing right now, is whenever a component have a model defined by child
elements, it implements a custom interface having a method returning
the model class it supports and making sure all model elements have a
constructor taking a properties map as an input (in case the element
must be built from the UIxxxItem properties). Then I have developped a
custom iterator capable of going throught any UI component model
implemented by those standard model UI components. Maybe someone have
a better design to propose me but it seems to do the trick for the
moment. What do you think?
Of course with JSP you need to developp a lot of custom tags but I
guess not with Clay or facelets :))
Here's the link to the Tomahawk panel I was refering to :
http://www.irian.at/myfaces/panelnavigation_2.jsp.source
On 1/8/06, Craig McClanahan <cr...@apache.org> wrote:
> Just a couple of comments intermixed below.
>
> On 1/7/06, Alexandre Poitras <al...@gmail.com> wrote:
> >
> > Ok can we all ignore the troll and go back to the original subject...
> >
> > Like Craig pointed out Rick, I think you should play around with JSF
> > first and then Shale.
> > The IBM serie "Cleared FUD about JSF" is a good introduction to. I
> > think one of the previous poster posted the link.
> >
> > Shale is decomposed in modules so it not so hard to get a grab on the
> > functionalities, one type at a time. Actually, it's not very complex
> > except maybe the Clay plugin wich does require some time to understand
> > but using it or Facelets instead of JSP is worth the troubles in my
> > opinion.
> >
> > Anyway, I have been playing with JSF for sometimes now and here's the
> > various differences against Struts I've found :
> >
> > - ActionForm and Action (more Dispatch Action in fact) are replaced by
> > backing beans.
> > No more copy between ActionForm and Domain objets or data transfer
> > objects are necessary.
> >
> > -The event model is fine-grained instead of coarse-grained. In struts,
> > you don't have a true event model and the only event is receive a
> > request and the *listeners* Action, are application wide.
> >
> > In JSF, the basic event listener are registered on a single component
> > instead of the complete application. You have two basic different
> > events (ActionEvent and ValueChangeEvent) and the event listeners all
> > receive an event object representing the event context.
>
>
> While these are the only two events defined in the standard, it is perfectly
> feasible for JSF components to define their own events, and their own event
> handlers, using the same basic infrastructure.
>
> Plus, in JSF
> > you can register more then one listeners on a component so no need for
> > Action chaining and the troubles coming along with it. Note that the
> > action events listeners are not responsible to choose the next view
> > like the actions are in Struts. It's quite a change but you get used
> > to it very fast in the end and this way your backing beans (most of
> > the time, they are the action listeners) are easier to reuse. Overall,
> > you can understand this quite fast if you are use to program Swing
> > applications.
>
>
> I actually wish there wasn't be so much difference here :-(. In the
> original vision of Struts, the idea of an ActionForward was very much to
> describe an *outcome* ("this is what happened"), not a *destination* ("this
> is where to go next"). Unfortunately, most Struts developers don't use
> forwards that way -- and you can make exactly the same "mistake" :-) when
> using logical outcomes in JSF.
>
> - The binding mechanism is way more powerful then Struts one and I
> > think this is where JSF really shine. In struts, you could only match
> > form beans properties to forms html tags and it was complex to bind
> > complex forms. In JSF, you can use EL value bindings or method
> > bindings expressions. It is really great in my mind and very simple at
> > the same time, thank to IoC and managed beans.
>
>
> The synergy of the managed beans facility is pretty nice ... especially when
> you realize you can use bindings on *any* property of *any* component, not
> just on the "value" property of an input component.
>
> - Finally, JSF has a component model and so reusing is very easy. The
> > components hide most of the complexity to the developper (ugly
> > javascript for exemple). Learning to developp components is what take
> > time to learn, but you can get started quite fast if you just want to
> > use it first. At least, there are a lot of exemples available.
> >
> > - One last thing, since the data and method bindings are specified in
> > the "jsp/html/whatever technologie you use for view" page and the
> > navigation is specified globally in the configuration file (not per
> > action like in Struts), it is quite easy to follow the application
> > flow. It was something that was annoying me sometimes with Struts, lot
> > of places to look to find where the executed code is located.
>
>
> In both environments, the navigation rules are defined globally. The
> difference in granularity is how a navigation rule is selected:
>
> * In Struts, it's based solely on the outcome returned by a particular
> action
> (which can be defined either globally or locally).
>
> * In JSF, it's based (at least for the standard navigation handler; you can
> replace
> this if you want something different) on three criteria:
> - What page am I currently on?
> - Which action method was executed?
> - What logical outcome was returned by the executed method?
>
> In the JSF case, there are wildcarding capabilities for navigation that also
> let you be pretty concise in what you actually have to specify for common
> cases.
>
> I hope it's help and since I am far from considering me a JSF expert,
> > anyone can feel free to correct me. And please be tolerant about my
> > english since I am not a native speaker and it's quite a long post :)
>
>
> You're doing great ... once you get me past a restaurant menu, my grasp of
> French is *really* limited :-).
>
> On a side note for people having experience developping custom
> > components, what annoys me so far in JSF is the model package, in fact
> > the SelectItem class. There are no model objets for action components
> > (like you need for a menu or navigation panel) and no universal
> > components (UISelectItem and UISelectItems) for specifying the model.
> > You need one for each component and it is quite a pain in the a.. to
> > code those again and again. Anyway, it always possible to develop your
> > own model hierarchy and use an adaptor to make SelectItem compatible
> > with it. As anyone had the same problem so far? If it is the case,
> > maybe a solution could be part of the future commons-jsf package that
> > have been discussed in the past. I am working on something around this
> > problem so I could probably submit it once I'm done.
>
>
> Could you describe a little more what you think a model object for action
> components should do? One of the things I like best about method bindings
> is that you do *not* have to conform to a particular interface -- you can
> point a submit button (or the node of a tree control, for example) at any
> method on any bean class that has the right method sigature. I've seen some
> pretty sophisticated menu and tree components that leverage this, without
> seeming to feel any pain, so I'd be interested in where you see the
> limitations.
>
> Craig
>
>
--
Alexandre Poitras
Québec, Canada
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Advice for Struts expert wanting to try Shale?
Posted by Craig McClanahan <cr...@apache.org>.
Just a couple of comments intermixed below.
On 1/7/06, Alexandre Poitras <al...@gmail.com> wrote:
>
> Ok can we all ignore the troll and go back to the original subject...
>
> Like Craig pointed out Rick, I think you should play around with JSF
> first and then Shale.
> The IBM serie "Cleared FUD about JSF" is a good introduction to. I
> think one of the previous poster posted the link.
>
> Shale is decomposed in modules so it not so hard to get a grab on the
> functionalities, one type at a time. Actually, it's not very complex
> except maybe the Clay plugin wich does require some time to understand
> but using it or Facelets instead of JSP is worth the troubles in my
> opinion.
>
> Anyway, I have been playing with JSF for sometimes now and here's the
> various differences against Struts I've found :
>
> - ActionForm and Action (more Dispatch Action in fact) are replaced by
> backing beans.
> No more copy between ActionForm and Domain objets or data transfer
> objects are necessary.
>
> -The event model is fine-grained instead of coarse-grained. In struts,
> you don't have a true event model and the only event is receive a
> request and the *listeners* Action, are application wide.
>
> In JSF, the basic event listener are registered on a single component
> instead of the complete application. You have two basic different
> events (ActionEvent and ValueChangeEvent) and the event listeners all
> receive an event object representing the event context.
While these are the only two events defined in the standard, it is perfectly
feasible for JSF components to define their own events, and their own event
handlers, using the same basic infrastructure.
Plus, in JSF
> you can register more then one listeners on a component so no need for
> Action chaining and the troubles coming along with it. Note that the
> action events listeners are not responsible to choose the next view
> like the actions are in Struts. It's quite a change but you get used
> to it very fast in the end and this way your backing beans (most of
> the time, they are the action listeners) are easier to reuse. Overall,
> you can understand this quite fast if you are use to program Swing
> applications.
I actually wish there wasn't be so much difference here :-(. In the
original vision of Struts, the idea of an ActionForward was very much to
describe an *outcome* ("this is what happened"), not a *destination* ("this
is where to go next"). Unfortunately, most Struts developers don't use
forwards that way -- and you can make exactly the same "mistake" :-) when
using logical outcomes in JSF.
- The binding mechanism is way more powerful then Struts one and I
> think this is where JSF really shine. In struts, you could only match
> form beans properties to forms html tags and it was complex to bind
> complex forms. In JSF, you can use EL value bindings or method
> bindings expressions. It is really great in my mind and very simple at
> the same time, thank to IoC and managed beans.
The synergy of the managed beans facility is pretty nice ... especially when
you realize you can use bindings on *any* property of *any* component, not
just on the "value" property of an input component.
- Finally, JSF has a component model and so reusing is very easy. The
> components hide most of the complexity to the developper (ugly
> javascript for exemple). Learning to developp components is what take
> time to learn, but you can get started quite fast if you just want to
> use it first. At least, there are a lot of exemples available.
>
> - One last thing, since the data and method bindings are specified in
> the "jsp/html/whatever technologie you use for view" page and the
> navigation is specified globally in the configuration file (not per
> action like in Struts), it is quite easy to follow the application
> flow. It was something that was annoying me sometimes with Struts, lot
> of places to look to find where the executed code is located.
In both environments, the navigation rules are defined globally. The
difference in granularity is how a navigation rule is selected:
* In Struts, it's based solely on the outcome returned by a particular
action
(which can be defined either globally or locally).
* In JSF, it's based (at least for the standard navigation handler; you can
replace
this if you want something different) on three criteria:
- What page am I currently on?
- Which action method was executed?
- What logical outcome was returned by the executed method?
In the JSF case, there are wildcarding capabilities for navigation that also
let you be pretty concise in what you actually have to specify for common
cases.
I hope it's help and since I am far from considering me a JSF expert,
> anyone can feel free to correct me. And please be tolerant about my
> english since I am not a native speaker and it's quite a long post :)
You're doing great ... once you get me past a restaurant menu, my grasp of
French is *really* limited :-).
On a side note for people having experience developping custom
> components, what annoys me so far in JSF is the model package, in fact
> the SelectItem class. There are no model objets for action components
> (like you need for a menu or navigation panel) and no universal
> components (UISelectItem and UISelectItems) for specifying the model.
> You need one for each component and it is quite a pain in the a.. to
> code those again and again. Anyway, it always possible to develop your
> own model hierarchy and use an adaptor to make SelectItem compatible
> with it. As anyone had the same problem so far? If it is the case,
> maybe a solution could be part of the future commons-jsf package that
> have been discussed in the past. I am working on something around this
> problem so I could probably submit it once I'm done.
Could you describe a little more what you think a model object for action
components should do? One of the things I like best about method bindings
is that you do *not* have to conform to a particular interface -- you can
point a submit button (or the node of a tree control, for example) at any
method on any bean class that has the right method sigature. I've seen some
pretty sophisticated menu and tree components that leverage this, without
seeming to feel any pain, so I'd be interested in where you see the
limitations.
Craig
Re: Advice for Struts expert wanting to try Shale?
Posted by Alexandre Poitras <al...@gmail.com>.
Ok can we all ignore the troll and go back to the original subject...
Like Craig pointed out Rick, I think you should play around with JSF
first and then Shale.
The IBM serie "Cleared FUD about JSF" is a good introduction to. I
think one of the previous poster posted the link.
Shale is decomposed in modules so it not so hard to get a grab on the
functionalities, one type at a time. Actually, it's not very complex
except maybe the Clay plugin wich does require some time to understand
but using it or Facelets instead of JSP is worth the troubles in my
opinion.
Anyway, I have been playing with JSF for sometimes now and here's the
various differences against Struts I've found :
- ActionForm and Action (more Dispatch Action in fact) are replaced by
backing beans.
No more copy between ActionForm and Domain objets or data transfer
objects are necessary.
-The event model is fine-grained instead of coarse-grained. In struts,
you don't have a true event model and the only event is receive a
request and the *listeners* Action, are application wide.
In JSF, the basic event listener are registered on a single component
instead of the complete application. You have two basic different
events (ActionEvent and ValueChangeEvent) and the event listeners all
receive an event object representing the event context. Plus, in JSF
you can register more then one listeners on a component so no need for
Action chaining and the troubles coming along with it. Note that the
action events listeners are not responsible to choose the next view
like the actions are in Struts. It's quite a change but you get used
to it very fast in the end and this way your backing beans (most of
the time, they are the action listeners) are easier to reuse. Overall,
you can understand this quite fast if you are use to program Swing
applications.
- The binding mechanism is way more powerful then Struts one and I
think this is where JSF really shine. In struts, you could only match
form beans properties to forms html tags and it was complex to bind
complex forms. In JSF, you can use EL value bindings or method
bindings expressions. It is really great in my mind and very simple at
the same time, thank to IoC and managed beans.
- Finally, JSF has a component model and so reusing is very easy. The
components hide most of the complexity to the developper (ugly
javascript for exemple). Learning to developp components is what take
time to learn, but you can get started quite fast if you just want to
use it first. At least, there are a lot of exemples available.
- One last thing, since the data and method bindings are specified in
the "jsp/html/whatever technologie you use for view" page and the
navigation is specified globally in the configuration file (not per
action like in Struts), it is quite easy to follow the application
flow. It was something that was annoying me sometimes with Struts, lot
of places to look to find where the executed code is located.
I hope it's help and since I am far from considering me a JSF expert,
anyone can feel free to correct me. And please be tolerant about my
english since I am not a native speaker and it's quite a long post :)
On a side note for people having experience developping custom
components, what annoys me so far in JSF is the model package, in fact
the SelectItem class. There are no model objets for action components
(like you need for a menu or navigation panel) and no universal
components (UISelectItem and UISelectItems) for specifying the model.
You need one for each component and it is quite a pain in the a.. to
code those again and again. Anyway, it always possible to develop your
own model hierarchy and use an adaptor to make SelectItem compatible
with it. As anyone had the same problem so far? If it is the case,
maybe a solution could be part of the future commons-jsf package that
have been discussed in the past. I am working on something around this
problem so I could probably submit it once I'm done.
On 1/7/06, Dakota Jack <da...@gmail.com> wrote:
> LOL I gave him the very same answer that you did, including the same
> citations. The difference is that I did not gloss over the confusion you
> have systematically engendered by not just owning up to the differences from
> day one. You don't have to love something to explain it. Otherwise, who
> would have known about the ugly duckling?
>
> On 1/7/06, Craig McClanahan <cr...@apache.org> wrote:
> >
> >
> >
> > If you are familiar with Core J2EE Patterns terminology, you'll find it
> > easiest to understand JSF and Shale in terms of the View Helper[1]
> > pattern,
> > where the helper items are the JSF component tags and your backing beans,
> > and the Dispatcher View[2] pattern, which combines the Front Controller[3]
> > and View Helper[1] patterns together. In the Dispatcher View sequence
> > diagram (Figure 7.25) the roles and responsibilities match up like this:
> > Don't expect much help from someone who doesn't seem to care much for
> > either
> > JSF or Shale :-).
> >
> > Mark
> >
> >
> > Craig
> >
> > [1]
> > http://java.sun.com/blueprints/corej2eepatterns/Patterns/ViewHelper.html
> > [2]
> >
> > http://java.sun.com/blueprints/corej2eepatterns/Patterns/DispatcherView.html
> > [3]
> >
> > http://java.sun.com/blueprints/corej2eepatterns/Patterns/FrontController.html
> >
> >
>
>
> --
> "You can lead a horse to water but you cannot make it float on its back."
> ~Dakota Jack~
>
>
--
Alexandre Poitras
Québec, Canada
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Advice for Struts expert wanting to try Shale?
Posted by Dakota Jack <da...@gmail.com>.
LOL I gave him the very same answer that you did, including the same
citations. The difference is that I did not gloss over the confusion you
have systematically engendered by not just owning up to the differences from
day one. You don't have to love something to explain it. Otherwise, who
would have known about the ugly duckling?
On 1/7/06, Craig McClanahan <cr...@apache.org> wrote:
>
>
>
> If you are familiar with Core J2EE Patterns terminology, you'll find it
> easiest to understand JSF and Shale in terms of the View Helper[1]
> pattern,
> where the helper items are the JSF component tags and your backing beans,
> and the Dispatcher View[2] pattern, which combines the Front Controller[3]
> and View Helper[1] patterns together. In the Dispatcher View sequence
> diagram (Figure 7.25) the roles and responsibilities match up like this:
> Don't expect much help from someone who doesn't seem to care much for
> either
> JSF or Shale :-).
>
> Mark
>
>
> Craig
>
> [1]
> http://java.sun.com/blueprints/corej2eepatterns/Patterns/ViewHelper.html
> [2]
>
> http://java.sun.com/blueprints/corej2eepatterns/Patterns/DispatcherView.html
> [3]
>
> http://java.sun.com/blueprints/corej2eepatterns/Patterns/FrontController.html
>
>
--
"You can lead a horse to water but you cannot make it float on its back."
~Dakota Jack~
Re: Advice for Struts expert wanting to try Shale?
Posted by Craig McClanahan <cr...@apache.org>.
On 1/7/06, Mark Lowe <me...@gmail.com> wrote:
>
> On 1/7/06, Dakota Jack <da...@gmail.com> wrote:
> > JSF is page centric rather than Action centric. There is no controller
> as
> > you understand that in Struts with JSF. JSF is for a tool based, dumbed
> > down, approach: JSF is to Struts as Visual Basic is to C++.
>
> JSF is more page centric than struts, but they aren't chalk and
> cheese. The view controller is still in the backing bean and then
> mapping of outcome to jsp is done via xml configuration. How page or
> controller centric you want jsf to be is upto you, this is where the
> diffence between JSF being a spec and struts a framework start being
> more visible.
If you are familiar with Core J2EE Patterns terminology, you'll find it
easiest to understand JSF and Shale in terms of the View Helper[1] pattern,
where the helper items are the JSF component tags and your backing beans,
and the Dispatcher View[2] pattern, which combines the Front Controller[3]
and View Helper[1] patterns together. In the Dispatcher View sequence
diagram (Figure 7.25) the roles and responsibilities match up like this:
* Contrroller == FacesServlet
* Dispatcher == the JSF Lifecycle object that manages the request processing
lifecycle
* View == The JSF view (often a JSP page, but not required with things like
Clay or Facelets)
* Helper == The backing bean assocated with the view (in Shale, the
VIewController is a View Helper
that does more than what you get in pure JSF applications)
In a JSF application, there's actually two ways to implement classic Front
Controller type functionality, such as "send the user to the logon page if
they are not currently logged on":
* With a servlet Filter that gets invoked in front of the JSF controller
(Shale has support for this). When
Struts 1.0 was created, there was no such thing, so we had to provide this
capability inside ActionServlet.
Now, the container has a much more flexible mechanism that can work on
either JSF requests or
non-JSF requests.
* By using a JSF PhaseListener to interact with the JSF Lifecycle (which has
Controller capabilities as well)
This is the way most AJAX enabled JSF components interact with the server
side of their asynchronous
requests ... they submit a request to a URL mapped to FacesServlet, and a
component-provided
PhaseListener intercepts control after the Restore View phase has
completed. But the point is clear ...
the Lifecycle implementation plays a controller role as well, and you can
customize its behavior with
phase listeners quite easily.
If I was asking how to get started with jsf and shale I'd find your VB
> vs C++ statement confusing and not very helpful at all.
Don't expect much help from someone who doesn't seem to care much for either
JSF or Shale :-).
Mark
Craig
[1] http://java.sun.com/blueprints/corej2eepatterns/Patterns/ViewHelper.html
[2]
http://java.sun.com/blueprints/corej2eepatterns/Patterns/DispatcherView.html
[3]
http://java.sun.com/blueprints/corej2eepatterns/Patterns/FrontController.html
Re: Advice for Struts expert wanting to try Shale?
Posted by Ted Husted <te...@gmail.com>.
On 1/7/06, Frank W. Zammetti <fz...@omnytex.com> wrote:
> Ted Husted wrote:
> > An expert uses the best tool for the job. A journeyman wants one size
> > to fit all.
>
> Blessed are those who get to make such decisions. There are
> unfortunately many shops that decide what the proper technologies are
> *before* any project kicks off, all in the name of "standardization".
And some shops even standardize on details like which IDE everyone
*must* use. :)
Happily, before long, an enterprise will be able to standardize on
Apache Struts, and some lucky developers will be able to at least
choose the best Struts tool for the job. Perhaps one day we won't have
to type cast every problem as a nail.
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Advice for Struts expert wanting to try Shale?
Posted by "Frank W. Zammetti" <fz...@omnytex.com>.
Ted Husted wrote:
> An expert uses the best tool for the job. A journeyman wants one size
> to fit all.
Blessed are those who get to make such decisions. There are
unfortunately many shops that decide what the proper technologies are
*before* any project kicks off, all in the name of "standardization".
Frank
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Advice for Struts expert wanting to try Shale?
Posted by Ted Husted <te...@gmail.com>.
On 1/7/06, Alexandre Poitras <al...@gmail.com> wrote:
> If you don't believe me, you can look in the famous pattern books out
> there (Fowler, J2EE core patterns).
Some of which used Struts as one of the use cases to prove a pattern exists. :)
But, in the end, it is what it is. What we call a mechanism is not as
important as whether the mechanism suits a developer's needs.
Sometimes JSF will work well for an application. Sometimes it won't.
An expert uses the best tool for the job. A journeyman wants one size
to fit all.
Another example is SQL data mappers verus object relational mappers.
Sometimes, iBATIS is the best tool for the job. Sometimes Cayene or
Hibernate work even better.
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Advice for Struts expert wanting to try Shale?
Posted by Alexandre Poitras <al...@gmail.com>.
By the way the so called application controller (RequestProcessor)
pattern has NOTHING to do with the controller (action, backing bean),
also called input controller, found in the so often misunderstood MVC
pattern. The only similarity is the sharing of the term controller.
If you don't believe me, you can look in the famous pattern books out
there (Fowler, J2EE core patterns). So Dakota your argument doesn't
make any senses to me unless you clarify wich controller you talk
about...
On 1/7/06, Mark Lowe <me...@gmail.com> wrote:
> Both struts and jsf provide a means of handling form submissons, that
> seems pretty view controller to me. I dont get how everything's so
> black and white and/or chalk and cheese. Sure you define views in jsf,
> and you can mess with more than just the forms, but are the
> differences really as profound or their similarities really comparable
> to VB and C++? Sorry I dont get it. When coding jsf and struts struff
> I get the feeling that I'm being abstracted from the servlet spec.
>
> What IDE vendors do is their affair, they've been trying to make
> coding brain dead for years and I doubt thats going to stop (note: I'm
> not saying that if someone uses an ide s/he is brain dead). But thats
> how JSF and struts are supported by IDE vendors not what they are in
> themselves, is a motorway made with tarmac or cars?
>
> Like i said before, C++ and VB like struts and jsf, sorry I'm trying
> to get it but I'm not there yet.. While I know there are differences
> between jsf and struts, I dont think they are as profound as you've
> stated.
>
> > Amen, brother. I wish Mark would see this.
>
> So do I, I guess I'll have to keep at it, and maybe one day I can
> become just like you :o) More seriously I'd really like what I'm
> missing clarifed as there's obviously something I haven't understood.
>
> Mark
>
> On 1/7/06, Dakota Jack <da...@gmail.com> wrote:
> > Amen, brother. I wish Mark would see this.
> >
> >
> > On 1/7/06, Martin Gainty <mg...@hotmail.com> wrote:
> > > let me assure you VB isnt the only course designed for tech support people
> > > wedged between auto-shop and recess
> > > yesterday I was prevented from implementing a script because the
> > individual
> > > didnt want to grant me permissions to the ** directory
> > > i.e. The LAST thing I want to do is to make this person PRODUCTIVE
> > >
> > > Yes I have learned that obfuscation and confusion are more than acceptable
> > > substitutes for generating working code
> > >
> > >
> > >
> > > ----- Original Message -----
> > > From: "Mark Lowe" <me...@gmail.com>
> > > To: "Struts Users Mailing List" <us...@struts.apache.org>
> > > Sent: Saturday, January 07, 2006 6:44 AM
> > > Subject: Re: Advice for Struts expert wanting to try Shale?
> > >
> > >
> > > On 1/7/06, Dakota Jack <da...@gmail.com> wrote:
> > > > JSF is page centric rather than Action centric. There is no controller
> > as
> > > > you understand that in Struts with JSF. JSF is for a tool based, dumbed
> > > > down, approach: JSF is to Struts as Visual Basic is to C++.
> > >
> > > JSF is more page centric than struts, but they aren't chalk and
> > > cheese. The view controller is still in the backing bean and then
> > > mapping of outcome to jsp is done via xml configuration. How page or
> > > controller centric you want jsf to be is upto you, this is where the
> > > diffence between JSF being a spec and struts a framework start being
> > > more visible.
> > >
> > > If I was asking how to get started with jsf and shale I'd find your VB
> > > vs C++ statement confusing and not very helpful at all.
> > >
> > > Mark
> > >
> > > >
> > > > On 1/6/06, Rick Mann < rmann@latencyzero.com> wrote:
> > > > >
> > > > > Thanks for the response, Craig. It's nice to get an answer from THE
> > > > > authority :-). Questions below...
> > > > >
> > > > > On Jan 6, 2006, at 5:16 PM, Craig McClanahan wrote:
> > > > >
> > > > > > I'd definitely ignore anything about prereleases of JSF 1.0 ...
> > > > > > that has
> > > > > > been out for nearly two years now. A good starting place for
> > > > > > general JSF
> > > > > > knowledge and information is <http://jsfcentral.com>. Kito does a
> > > > > > good job
> > > > > > of staying on top of the most recent articles and items of
> > > > > > interest. This,
> > > > > > by the way, is *exactly* the place to start before looking much at
> > > > > > Shale
> > > > > > itself -- Shale *srongly* presumes that you are familiar with JSF,
> > > > > > and what
> > > > > > it brings to the table all by itself, because it focuses on adding
> > > > > > value
> > > > > > around the edges. Without understanding those edges a little, it's
> > > > > > harder
> > > > > > to appreciate the benefits :-).
> > > > >
> > > > > Okay, I'll try to find a "hello world" JSF example. That might be
> > > > > enough for me to build on.
> > > > >
> > > > > A question comes up: what has happened to Tiles? Is it no longer a
> > > > > part of Struts? I'm still terribly unfamiliar with the new Struts
> > > > > website.
> > > > >
> > > > > Do I bother creating a nice Tiles hierarchy of layouts and tiles? Or
> > > > > is there some other way to get site L&F re-use?
> > > > >
> > > > > > Beyond the Shale web site[1], there's not a heck of a lot of stuff
> > > > > > yet. One
> > > > > > high level overview is the session I did at ApacheCon (reprised
> > > > > > from one
> > > > > > that David Geary and I did at JavaOne)[2] ... but the slides lose a
> > > > > > little
> > > > > > in the translation without the corresponding demo program, which is
> > > > > > not in a
> > > > > > shape that I'm quite ready to check in yet :-).
> > > > >
> > > > > Okay, I'll hold off worrying about Shale for now. Sounds like I can
> > > > > work it in easily enough when the time comes.
> > > > >
> > > > >
> > > > > Here's my big question: do I still think in terms of Struts Actions
> > > > > handling the business logic of my application (which they rarely do;
> > > > > they usually glue to the "real" biz code)? Or do I look to putting
> > > > > all that glue within JSF controllers?
> > > > >
> > > > > Thanks!
> > > > >
> > > > > --
> > > > > Rick
> > > > >
> > > > >
> > > > >
> > > > >
> > ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail:
> > user-unsubscribe@struts.apache.org
> > > > > For additional commands, e-mail: user-help@struts.apache.org
> > > > >
> > > > >
> > > >
> > > >
> > > > --
> > > > "You can lead a horse to water but you cannot make it float on its
> > back."
> > > > ~Dakota Jack~
> > > >
> > > >
> > >
> > >
> > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail:
> > user-unsubscribe@struts.apache.org
> > > For additional commands, e-mail: user-help@struts.apache.org
> > >
> > >
> >
> >
> >
> > --
> >
> > "You can lead a horse to water but you cannot make it float on its back."
> > ~Dakota Jack~
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
--
Alexandre Poitras
Québec, Canada
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Advice for Struts expert wanting to try Shale?
Posted by Dakota Jack <da...@gmail.com>.
<snip>
On 1/8/06, Mark Lowe <me...@gmail.com> wrote:
>
> Its not about the inner workings, its about what it does.
>
</snip>
If this were the case, Mark, then there would be virtually no difference
between any of the solutions. You could just do anything at all that got
the result and that would be fine. This negates the whole enterprise. If
this is so, just roll your own. It will do whatever Struts, Spring, etc.
do. I don't see how you can possibly say this. It's all about how well,
how efficiently, how easy to maintain, how reliable, how flexible, etc.,
down through all the ilities. What it does is easy to achieve. That has
nothing to do with anything much at all. But, since you think this, I
better understand what you are thinking.
> Mark
>
> On 1/8/06, Dakota Jack <da...@gmail.com> wrote:
> > See within:
> >
> > On 1/7/06, Mark Lowe <me...@gmail.com> wrote:
> > <snip>
> >
> > > Both struts and jsf provide a means of handling form submissons, that
> > > seems pretty view controller to me.
> > </snip>
> >
> > ANY framework has to provide a "means" of handling form
> submissions. That
> > has nothing whatsoever to do with controllers, view controllers, or
> > whatever. Check out
> > http://java.sun.com/blueprints/corej2eepatterns/Patterns/index.html.
> >
> >
> > <snip>
> > > I dont get how everything's so
> > > black and white and/or chalk and cheese.
> > </snip>
> >
> > I have no idea what this is talking about. I certainly don't think
> anyone
> > who sees what is going on thinks that the controller mechanism in Struts
> is
> > anything like that in JSF. That is a huge confusion that makes no
> sense. I
> > cannot even imagine how one would get to that wrong-headed position. I
> do
> > know that the page-centric boys early on in JSF decided to talk like a
> view
> > controller in their scheme of things was like a real controller, but
> that
> > was poopooed ad abnitia.
> > <snip>
> > > Sure you define views in jsf,
> > > and you can mess with more than just the forms, but are the
> > > differences really as profound or their similarities really comparable
> > > to VB and C++? Sorry I dont get it. When coding jsf and struts struff
> > > I get the feeling that I'm being abstracted from the servlet spec.
> >
> > </snip>
> >
> > Apparently you don't know how these things work. If you did, their
> huge
> > differences would be and have to be immediately apparent.
> > <snip>
> > > What IDE vendors do is their affair, they've been trying to make
> > > coding brain dead for years and I doubt thats going to stop (note: I'm
> > > not saying that if someone uses an ide s/he is brain dead). But thats
> > > how JSF and struts are supported by IDE vendors not what they are in
> > > themselves, is a motorway made with tarmac or cars?
> > </snip>
> >
> > You don't get it, Mark. VB was made for the IDE vendors and SO WAS
> JSF, in
> > order to try a sort of competition with the .NET vendor yearning. This
> is
> > not a case where the IDE people are off on the sidelines playing their
> own
> > game. WIthout the IDE stuff, JSF is pretty much junk. No one seriously
> > thinks it is better on the merits of how it works. At least I hope no
> one
> > is that deluded. It will be better, if at all, based on its ease of use
> for
> > people without many skills.
> > <snip>
> > > Like i said before, C++ and VB like struts and jsf, sorry I'm trying
> > > to get it but I'm not there yet.. While I know there are differences
> > > between jsf and struts, I dont think they are as profound as you've
> > > stated.
> > </snip>
> >
> > I think you have to go look at how they are built. Surely you don't
> know
> > or you could not say this, Mark. They are night and day. That is not
> even
> > a debate in my opinion. The hope early on was for JSF to obfuscate this
> > difference so it could purloin the Struts good name. That worked to a
> > certain extent.
> > <snip>
> > > > Amen, brother. I wish Mark would see this.
> > >
> > > So do I, I guess I'll have to keep at it, and maybe one day I can
> > > become just like you :o) More seriously I'd really like what I'm
> > > missing clarifed as there's obviously something I haven't understood.
> > >
> > > Mark
> > </snip>
> >
> > Again, apparently you just don't have a knowledge of the basic workings
> of
> > the two frameworks.
> >
> >
> > > On 1/7/06, Dakota Jack <dakota.jack@gmail.com > wrote:
> > > > Amen, brother. I wish Mark would see this.
> > > >
> > > >
> > > > On 1/7/06, Martin Gainty <mg...@hotmail.com> wrote:
> > > > > let me assure you VB isnt the only course designed for tech
> support
> > people
> > > > > wedged between auto-shop and recess
> > > > > yesterday I was prevented from implementing a script because the
> > > > individual
> > > > > didnt want to grant me permissions to the ** directory
> > > > > i.e. The LAST thing I want to do is to make this person PRODUCTIVE
> > > > >
> > > > > Yes I have learned that obfuscation and confusion are more than
> > acceptable
> > > > > substitutes for generating working code
> > > > >
> > > > >
> > > > >
> > > > > ----- Original Message -----
> > > > > From: "Mark Lowe" <me...@gmail.com>
> > > > > To: "Struts Users Mailing List" < user@struts.apache.org>
> > > > > Sent: Saturday, January 07, 2006 6:44 AM
> > > > > Subject: Re: Advice for Struts expert wanting to try Shale?
> > > > >
> > > > >
> > > > > On 1/7/06, Dakota Jack <da...@gmail.com> wrote:
> > > > > > JSF is page centric rather than Action centric. There is no
> > controller
> > > > as
> > > > > > you understand that in Struts with JSF. JSF is for a tool
> based,
> > dumbed
> > > > > > down, approach: JSF is to Struts as Visual Basic is to C++.
> > > > >
> > > > > JSF is more page centric than struts, but they aren't chalk and
> > > > > cheese. The view controller is still in the backing bean and then
> > > > > mapping of outcome to jsp is done via xml configuration. How page
> or
> > > > > controller centric you want jsf to be is upto you, this is where
> the
> > > > > diffence between JSF being a spec and struts a framework start
> being
> > > > > more visible.
> > > > >
> > > > > If I was asking how to get started with jsf and shale I'd find
> your VB
> > > > > vs C++ statement confusing and not very helpful at all.
> > > > >
> > > > > Mark
> > > > >
> > > > > >
> > > > > > On 1/6/06, Rick Mann < rmann@latencyzero.com> wrote:
> > > > > > >
> > > > > > > Thanks for the response, Craig. It's nice to get an answer
> from
> > THE
> > > > > > > authority :-). Questions below...
> > > > > > >
> > > > > > > On Jan 6, 2006, at 5:16 PM, Craig McClanahan wrote:
> > > > > > >
> > > > > > > > I'd definitely ignore anything about prereleases of JSF 1.0...
> > > > > > > > that has
> > > > > > > > been out for nearly two years now. A good starting place
> for
> > > > > > > > general JSF
> > > > > > > > knowledge and information is < http://jsfcentral.com>. Kito
> > does a
> > > > > > > > good job
> > > > > > > > of staying on top of the most recent articles and items of
> > > > > > > > interest. This,
> > > > > > > > by the way, is *exactly* the place to start before looking
> much
> > at
> > > > > > > > Shale
> > > > > > > > itself -- Shale *srongly* presumes that you are familiar
> with
> > JSF,
> > > > > > > > and what
> > > > > > > > it brings to the table all by itself, because it focuses on
> > adding
> > > > > > > > value
> > > > > > > > around the edges. Without understanding those edges a
> little,
> > it's
> > > > > > > > harder
> > > > > > > > to appreciate the benefits :-).
> > > > > > >
> > > > > > > Okay, I'll try to find a "hello world" JSF example. That might
> be
> > > > > > > enough for me to build on.
> > > > > > >
> > > > > > > A question comes up: what has happened to Tiles? Is it no
> longer a
> > > > > > > part of Struts? I'm still terribly unfamiliar with the new
> Struts
> > > > > > > website.
> > > > > > >
> > > > > > > Do I bother creating a nice Tiles hierarchy of layouts and
> tiles?
> > Or
> > > > > > > is there some other way to get site L&F re-use?
> > > > > > >
> > > > > > > > Beyond the Shale web site[1], there's not a heck of a lot of
> > stuff
> > > > > > > > yet. One
> > > > > > > > high level overview is the session I did at ApacheCon
> (reprised
> > > > > > > > from one
> > > > > > > > that David Geary and I did at JavaOne)[2] ... but the slides
> > lose a
> > > > > > > > little
> > > > > > > > in the translation without the corresponding demo program,
> which
> > is
> > > > > > > > not in a
> > > > > > > > shape that I'm quite ready to check in yet :-).
> > > > > > >
> > > > > > > Okay, I'll hold off worrying about Shale for now. Sounds like
> I
> > can
> > > > > > > work it in easily enough when the time comes.
> > > > > > >
> > > > > > >
> > > > > > > Here's my big question: do I still think in terms of Struts
> > Actions
> > > > > > > handling the business logic of my application (which they
> rarely
> > do;
> > > > > > > they usually glue to the "real" biz code)? Or do I look to
> putting
> > > > > > > all that glue within JSF controllers?
> > > > > > >
> > > > > > > Thanks!
> > > > > > >
> > > > > > > --
> > > > > > > Rick
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > >
> > ---------------------------------------------------------------------
> > > > > > > To unsubscribe, e-mail:
> > > > user-unsubscribe@struts.apache.org
> > > > > > > For additional commands, e-mail: user-help@struts.apache.org
> > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > "You can lead a horse to water but you cannot make it float on
> its
> > > > back."
> > > > > > ~Dakota Jack~
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > >
> > ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail:
> > > > user-unsubscribe@struts.apache.org
> > > > > For additional commands, e-mail: user-help@struts.apache.org
> > > > >
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > >
> > > > "You can lead a horse to water but you cannot make it float on its
> > back."
> > > > ~Dakota Jack~
> > > >
> > >
> >
> >
> >
> > --
> >
> > "You can lead a horse to water but you cannot make it float on its
> back."
> > ~Dakota Jack~
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
--
"You can lead a horse to water but you cannot make it float on its back."
~Dakota Jack~
Re: Advice for Struts expert wanting to try Shale?
Posted by Mark Lowe <me...@gmail.com>.
Its not about the inner workings, its about what it does.
Sure struts action and jsf do this differently. Having all the stuff
you need available in FacesContent.currentInstance() rather than
having form,mapping, request and response passed to actions, yes these
are differences. But are the differences so profound that you need to
tell folk that there are no similarities?
What they both have in common is that jsf and struts action provide a
means of validating input and then forwarding to the next view. If you
look at the patterns that your so keen on quoting (albeit not
explaining) then its not that hard to see that both are front
controllers.
In struts mapping are done via url patterns, in JSF expressions. Yes
this is a difference, but one analogous to VB and C++? I don't think
so or I dont get it. I use both struts action and JSF, and I don't get
what you're on about.
If the motivation behind JSF is about creating IDE friendly stuff then
so be it, but you cant have used JSF and claim its painful to develop
without one. I don't care what the motivations behind the spec are,
I'm more concerned with something that works for a given problem.
Again you're claiming that a road is made with cars rather than for
them.
Mark
On 1/8/06, Dakota Jack <da...@gmail.com> wrote:
> See within:
>
> On 1/7/06, Mark Lowe <me...@gmail.com> wrote:
> <snip>
>
> > Both struts and jsf provide a means of handling form submissons, that
> > seems pretty view controller to me.
> </snip>
>
> ANY framework has to provide a "means" of handling form submissions. That
> has nothing whatsoever to do with controllers, view controllers, or
> whatever. Check out
> http://java.sun.com/blueprints/corej2eepatterns/Patterns/index.html.
>
>
> <snip>
> > I dont get how everything's so
> > black and white and/or chalk and cheese.
> </snip>
>
> I have no idea what this is talking about. I certainly don't think anyone
> who sees what is going on thinks that the controller mechanism in Struts is
> anything like that in JSF. That is a huge confusion that makes no sense. I
> cannot even imagine how one would get to that wrong-headed position. I do
> know that the page-centric boys early on in JSF decided to talk like a view
> controller in their scheme of things was like a real controller, but that
> was poopooed ad abnitia.
> <snip>
> > Sure you define views in jsf,
> > and you can mess with more than just the forms, but are the
> > differences really as profound or their similarities really comparable
> > to VB and C++? Sorry I dont get it. When coding jsf and struts struff
> > I get the feeling that I'm being abstracted from the servlet spec.
>
> </snip>
>
> Apparently you don't know how these things work. If you did, their huge
> differences would be and have to be immediately apparent.
> <snip>
> > What IDE vendors do is their affair, they've been trying to make
> > coding brain dead for years and I doubt thats going to stop (note: I'm
> > not saying that if someone uses an ide s/he is brain dead). But thats
> > how JSF and struts are supported by IDE vendors not what they are in
> > themselves, is a motorway made with tarmac or cars?
> </snip>
>
> You don't get it, Mark. VB was made for the IDE vendors and SO WAS JSF, in
> order to try a sort of competition with the .NET vendor yearning. This is
> not a case where the IDE people are off on the sidelines playing their own
> game. WIthout the IDE stuff, JSF is pretty much junk. No one seriously
> thinks it is better on the merits of how it works. At least I hope no one
> is that deluded. It will be better, if at all, based on its ease of use for
> people without many skills.
> <snip>
> > Like i said before, C++ and VB like struts and jsf, sorry I'm trying
> > to get it but I'm not there yet.. While I know there are differences
> > between jsf and struts, I dont think they are as profound as you've
> > stated.
> </snip>
>
> I think you have to go look at how they are built. Surely you don't know
> or you could not say this, Mark. They are night and day. That is not even
> a debate in my opinion. The hope early on was for JSF to obfuscate this
> difference so it could purloin the Struts good name. That worked to a
> certain extent.
> <snip>
> > > Amen, brother. I wish Mark would see this.
> >
> > So do I, I guess I'll have to keep at it, and maybe one day I can
> > become just like you :o) More seriously I'd really like what I'm
> > missing clarifed as there's obviously something I haven't understood.
> >
> > Mark
> </snip>
>
> Again, apparently you just don't have a knowledge of the basic workings of
> the two frameworks.
>
>
> > On 1/7/06, Dakota Jack <dakota.jack@gmail.com > wrote:
> > > Amen, brother. I wish Mark would see this.
> > >
> > >
> > > On 1/7/06, Martin Gainty <mg...@hotmail.com> wrote:
> > > > let me assure you VB isnt the only course designed for tech support
> people
> > > > wedged between auto-shop and recess
> > > > yesterday I was prevented from implementing a script because the
> > > individual
> > > > didnt want to grant me permissions to the ** directory
> > > > i.e. The LAST thing I want to do is to make this person PRODUCTIVE
> > > >
> > > > Yes I have learned that obfuscation and confusion are more than
> acceptable
> > > > substitutes for generating working code
> > > >
> > > >
> > > >
> > > > ----- Original Message -----
> > > > From: "Mark Lowe" <me...@gmail.com>
> > > > To: "Struts Users Mailing List" < user@struts.apache.org>
> > > > Sent: Saturday, January 07, 2006 6:44 AM
> > > > Subject: Re: Advice for Struts expert wanting to try Shale?
> > > >
> > > >
> > > > On 1/7/06, Dakota Jack <da...@gmail.com> wrote:
> > > > > JSF is page centric rather than Action centric. There is no
> controller
> > > as
> > > > > you understand that in Struts with JSF. JSF is for a tool based,
> dumbed
> > > > > down, approach: JSF is to Struts as Visual Basic is to C++.
> > > >
> > > > JSF is more page centric than struts, but they aren't chalk and
> > > > cheese. The view controller is still in the backing bean and then
> > > > mapping of outcome to jsp is done via xml configuration. How page or
> > > > controller centric you want jsf to be is upto you, this is where the
> > > > diffence between JSF being a spec and struts a framework start being
> > > > more visible.
> > > >
> > > > If I was asking how to get started with jsf and shale I'd find your VB
> > > > vs C++ statement confusing and not very helpful at all.
> > > >
> > > > Mark
> > > >
> > > > >
> > > > > On 1/6/06, Rick Mann < rmann@latencyzero.com> wrote:
> > > > > >
> > > > > > Thanks for the response, Craig. It's nice to get an answer from
> THE
> > > > > > authority :-). Questions below...
> > > > > >
> > > > > > On Jan 6, 2006, at 5:16 PM, Craig McClanahan wrote:
> > > > > >
> > > > > > > I'd definitely ignore anything about prereleases of JSF 1.0 ...
> > > > > > > that has
> > > > > > > been out for nearly two years now. A good starting place for
> > > > > > > general JSF
> > > > > > > knowledge and information is < http://jsfcentral.com>. Kito
> does a
> > > > > > > good job
> > > > > > > of staying on top of the most recent articles and items of
> > > > > > > interest. This,
> > > > > > > by the way, is *exactly* the place to start before looking much
> at
> > > > > > > Shale
> > > > > > > itself -- Shale *srongly* presumes that you are familiar with
> JSF,
> > > > > > > and what
> > > > > > > it brings to the table all by itself, because it focuses on
> adding
> > > > > > > value
> > > > > > > around the edges. Without understanding those edges a little,
> it's
> > > > > > > harder
> > > > > > > to appreciate the benefits :-).
> > > > > >
> > > > > > Okay, I'll try to find a "hello world" JSF example. That might be
> > > > > > enough for me to build on.
> > > > > >
> > > > > > A question comes up: what has happened to Tiles? Is it no longer a
> > > > > > part of Struts? I'm still terribly unfamiliar with the new Struts
> > > > > > website.
> > > > > >
> > > > > > Do I bother creating a nice Tiles hierarchy of layouts and tiles?
> Or
> > > > > > is there some other way to get site L&F re-use?
> > > > > >
> > > > > > > Beyond the Shale web site[1], there's not a heck of a lot of
> stuff
> > > > > > > yet. One
> > > > > > > high level overview is the session I did at ApacheCon (reprised
> > > > > > > from one
> > > > > > > that David Geary and I did at JavaOne)[2] ... but the slides
> lose a
> > > > > > > little
> > > > > > > in the translation without the corresponding demo program, which
> is
> > > > > > > not in a
> > > > > > > shape that I'm quite ready to check in yet :-).
> > > > > >
> > > > > > Okay, I'll hold off worrying about Shale for now. Sounds like I
> can
> > > > > > work it in easily enough when the time comes.
> > > > > >
> > > > > >
> > > > > > Here's my big question: do I still think in terms of Struts
> Actions
> > > > > > handling the business logic of my application (which they rarely
> do;
> > > > > > they usually glue to the "real" biz code)? Or do I look to putting
> > > > > > all that glue within JSF controllers?
> > > > > >
> > > > > > Thanks!
> > > > > >
> > > > > > --
> > > > > > Rick
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > >
> ---------------------------------------------------------------------
> > > > > > To unsubscribe, e-mail:
> > > user-unsubscribe@struts.apache.org
> > > > > > For additional commands, e-mail: user-help@struts.apache.org
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > > > --
> > > > > "You can lead a horse to water but you cannot make it float on its
> > > back."
> > > > > ~Dakota Jack~
> > > > >
> > > > >
> > > >
> > > >
> > >
> ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail:
> > > user-unsubscribe@struts.apache.org
> > > > For additional commands, e-mail: user-help@struts.apache.org
> > > >
> > > >
> > >
> > >
> > >
> > > --
> > >
> > > "You can lead a horse to water but you cannot make it float on its
> back."
> > > ~Dakota Jack~
> > >
> >
>
>
>
> --
>
> "You can lead a horse to water but you cannot make it float on its back."
> ~Dakota Jack~
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Advice for Struts expert wanting to try Shale?
Posted by Dakota Jack <da...@gmail.com>.
See within:
On 1/7/06, Mark Lowe <me...@gmail.com> wrote:
<snip>
> Both struts and jsf provide a means of handling form submissons, that
> seems pretty view controller to me.
</snip>
ANY framework has to provide a "means" of handling form submissions. That
has nothing whatsoever to do with controllers, view controllers, or
whatever. Check out
http://java.sun.com/blueprints/corej2eepatterns/Patterns/index.html.
<snip>
> I dont get how everything's so
> black and white and/or chalk and cheese.
</snip>
I have no idea what this is talking about. I certainly don't think anyone
who sees what is going on thinks that the controller mechanism in Struts is
anything like that in JSF. That is a huge confusion that makes no sense. I
cannot even imagine how one would get to that wrong-headed position. I do
know that the page-centric boys early on in JSF decided to talk like a view
controller in their scheme of things was like a real controller, but that
was poopooed ad abnitia.
<snip>
> Sure you define views in jsf,
> and you can mess with more than just the forms, but are the
> differences really as profound or their similarities really comparable
> to VB and C++? Sorry I dont get it. When coding jsf and struts struff
> I get the feeling that I'm being abstracted from the servlet spec.
</snip>
Apparently you don't know how these things work. If you did, their huge
differences would be and have to be immediately apparent.
<snip>
> What IDE vendors do is their affair, they've been trying to make
> coding brain dead for years and I doubt thats going to stop (note: I'm
> not saying that if someone uses an ide s/he is brain dead). But thats
> how JSF and struts are supported by IDE vendors not what they are in
> themselves, is a motorway made with tarmac or cars?
</snip>
You don't get it, Mark. VB was made for the IDE vendors and SO WAS JSF, in
order to try a sort of competition with the .NET vendor yearning. This is
not a case where the IDE people are off on the sidelines playing their own
game. WIthout the IDE stuff, JSF is pretty much junk. No one seriously
thinks it is better on the merits of how it works. At least I hope no one
is that deluded. It will be better, if at all, based on its ease of use for
people without many skills.
<snip>
> Like i said before, C++ and VB like struts and jsf, sorry I'm trying
> to get it but I'm not there yet.. While I know there are differences
> between jsf and struts, I dont think they are as profound as you've
> stated.
</snip>
I think you have to go look at how they are built. Surely you don't know or
you could not say this, Mark. They are night and day. That is not even a
debate in my opinion. The hope early on was for JSF to obfuscate this
difference so it could purloin the Struts good name. That worked to a
certain extent.
<snip>
> > Amen, brother. I wish Mark would see this.
>
> So do I, I guess I'll have to keep at it, and maybe one day I can
> become just like you :o) More seriously I'd really like what I'm
> missing clarifed as there's obviously something I haven't understood.
>
> Mark
</snip>
Again, apparently you just don't have a knowledge of the basic workings of
the two frameworks.
On 1/7/06, Dakota Jack <da...@gmail.com> wrote:
> > Amen, brother. I wish Mark would see this.
> >
> >
> > On 1/7/06, Martin Gainty <mg...@hotmail.com> wrote:
> > > let me assure you VB isnt the only course designed for tech support
> people
> > > wedged between auto-shop and recess
> > > yesterday I was prevented from implementing a script because the
> > individual
> > > didnt want to grant me permissions to the ** directory
> > > i.e. The LAST thing I want to do is to make this person PRODUCTIVE
> > >
> > > Yes I have learned that obfuscation and confusion are more than
> acceptable
> > > substitutes for generating working code
> > >
> > >
> > >
> > > ----- Original Message -----
> > > From: "Mark Lowe" <me...@gmail.com>
> > > To: "Struts Users Mailing List" <us...@struts.apache.org>
> > > Sent: Saturday, January 07, 2006 6:44 AM
> > > Subject: Re: Advice for Struts expert wanting to try Shale?
> > >
> > >
> > > On 1/7/06, Dakota Jack <da...@gmail.com> wrote:
> > > > JSF is page centric rather than Action centric. There is no
> controller
> > as
> > > > you understand that in Struts with JSF. JSF is for a tool based,
> dumbed
> > > > down, approach: JSF is to Struts as Visual Basic is to C++.
> > >
> > > JSF is more page centric than struts, but they aren't chalk and
> > > cheese. The view controller is still in the backing bean and then
> > > mapping of outcome to jsp is done via xml configuration. How page or
> > > controller centric you want jsf to be is upto you, this is where the
> > > diffence between JSF being a spec and struts a framework start being
> > > more visible.
> > >
> > > If I was asking how to get started with jsf and shale I'd find your VB
> > > vs C++ statement confusing and not very helpful at all.
> > >
> > > Mark
> > >
> > > >
> > > > On 1/6/06, Rick Mann < rmann@latencyzero.com> wrote:
> > > > >
> > > > > Thanks for the response, Craig. It's nice to get an answer from
> THE
> > > > > authority :-). Questions below...
> > > > >
> > > > > On Jan 6, 2006, at 5:16 PM, Craig McClanahan wrote:
> > > > >
> > > > > > I'd definitely ignore anything about prereleases of JSF 1.0 ...
> > > > > > that has
> > > > > > been out for nearly two years now. A good starting place for
> > > > > > general JSF
> > > > > > knowledge and information is <http://jsfcentral.com>. Kito does
> a
> > > > > > good job
> > > > > > of staying on top of the most recent articles and items of
> > > > > > interest. This,
> > > > > > by the way, is *exactly* the place to start before looking much
> at
> > > > > > Shale
> > > > > > itself -- Shale *srongly* presumes that you are familiar with
> JSF,
> > > > > > and what
> > > > > > it brings to the table all by itself, because it focuses on
> adding
> > > > > > value
> > > > > > around the edges. Without understanding those edges a little,
> it's
> > > > > > harder
> > > > > > to appreciate the benefits :-).
> > > > >
> > > > > Okay, I'll try to find a "hello world" JSF example. That might be
> > > > > enough for me to build on.
> > > > >
> > > > > A question comes up: what has happened to Tiles? Is it no longer a
> > > > > part of Struts? I'm still terribly unfamiliar with the new Struts
> > > > > website.
> > > > >
> > > > > Do I bother creating a nice Tiles hierarchy of layouts and tiles?
> Or
> > > > > is there some other way to get site L&F re-use?
> > > > >
> > > > > > Beyond the Shale web site[1], there's not a heck of a lot of
> stuff
> > > > > > yet. One
> > > > > > high level overview is the session I did at ApacheCon (reprised
> > > > > > from one
> > > > > > that David Geary and I did at JavaOne)[2] ... but the slides
> lose a
> > > > > > little
> > > > > > in the translation without the corresponding demo program, which
> is
> > > > > > not in a
> > > > > > shape that I'm quite ready to check in yet :-).
> > > > >
> > > > > Okay, I'll hold off worrying about Shale for now. Sounds like I
> can
> > > > > work it in easily enough when the time comes.
> > > > >
> > > > >
> > > > > Here's my big question: do I still think in terms of Struts
> Actions
> > > > > handling the business logic of my application (which they rarely
> do;
> > > > > they usually glue to the "real" biz code)? Or do I look to putting
> > > > > all that glue within JSF controllers?
> > > > >
> > > > > Thanks!
> > > > >
> > > > > --
> > > > > Rick
> > > > >
> > > > >
> > > > >
> > > > >
> > ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail:
> > user-unsubscribe@struts.apache.org
> > > > > For additional commands, e-mail: user-help@struts.apache.org
> > > > >
> > > > >
> > > >
> > > >
> > > > --
> > > > "You can lead a horse to water but you cannot make it float on its
> > back."
> > > > ~Dakota Jack~
> > > >
> > > >
> > >
> > >
> > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail:
> > user-unsubscribe@struts.apache.org
> > > For additional commands, e-mail: user-help@struts.apache.org
> > >
> > >
> >
> >
> >
> > --
> >
> > "You can lead a horse to water but you cannot make it float on its
> back."
> > ~Dakota Jack~
> >
>
--
"You can lead a horse to water but you cannot make it float on its back."
~Dakota Jack~
Re: Advice for Struts expert wanting to try Shale?
Posted by Mark Lowe <me...@gmail.com>.
Both struts and jsf provide a means of handling form submissons, that
seems pretty view controller to me. I dont get how everything's so
black and white and/or chalk and cheese. Sure you define views in jsf,
and you can mess with more than just the forms, but are the
differences really as profound or their similarities really comparable
to VB and C++? Sorry I dont get it. When coding jsf and struts struff
I get the feeling that I'm being abstracted from the servlet spec.
What IDE vendors do is their affair, they've been trying to make
coding brain dead for years and I doubt thats going to stop (note: I'm
not saying that if someone uses an ide s/he is brain dead). But thats
how JSF and struts are supported by IDE vendors not what they are in
themselves, is a motorway made with tarmac or cars?
Like i said before, C++ and VB like struts and jsf, sorry I'm trying
to get it but I'm not there yet.. While I know there are differences
between jsf and struts, I dont think they are as profound as you've
stated.
> Amen, brother. I wish Mark would see this.
So do I, I guess I'll have to keep at it, and maybe one day I can
become just like you :o) More seriously I'd really like what I'm
missing clarifed as there's obviously something I haven't understood.
Mark
On 1/7/06, Dakota Jack <da...@gmail.com> wrote:
> Amen, brother. I wish Mark would see this.
>
>
> On 1/7/06, Martin Gainty <mg...@hotmail.com> wrote:
> > let me assure you VB isnt the only course designed for tech support people
> > wedged between auto-shop and recess
> > yesterday I was prevented from implementing a script because the
> individual
> > didnt want to grant me permissions to the ** directory
> > i.e. The LAST thing I want to do is to make this person PRODUCTIVE
> >
> > Yes I have learned that obfuscation and confusion are more than acceptable
> > substitutes for generating working code
> >
> >
> >
> > ----- Original Message -----
> > From: "Mark Lowe" <me...@gmail.com>
> > To: "Struts Users Mailing List" <us...@struts.apache.org>
> > Sent: Saturday, January 07, 2006 6:44 AM
> > Subject: Re: Advice for Struts expert wanting to try Shale?
> >
> >
> > On 1/7/06, Dakota Jack <da...@gmail.com> wrote:
> > > JSF is page centric rather than Action centric. There is no controller
> as
> > > you understand that in Struts with JSF. JSF is for a tool based, dumbed
> > > down, approach: JSF is to Struts as Visual Basic is to C++.
> >
> > JSF is more page centric than struts, but they aren't chalk and
> > cheese. The view controller is still in the backing bean and then
> > mapping of outcome to jsp is done via xml configuration. How page or
> > controller centric you want jsf to be is upto you, this is where the
> > diffence between JSF being a spec and struts a framework start being
> > more visible.
> >
> > If I was asking how to get started with jsf and shale I'd find your VB
> > vs C++ statement confusing and not very helpful at all.
> >
> > Mark
> >
> > >
> > > On 1/6/06, Rick Mann < rmann@latencyzero.com> wrote:
> > > >
> > > > Thanks for the response, Craig. It's nice to get an answer from THE
> > > > authority :-). Questions below...
> > > >
> > > > On Jan 6, 2006, at 5:16 PM, Craig McClanahan wrote:
> > > >
> > > > > I'd definitely ignore anything about prereleases of JSF 1.0 ...
> > > > > that has
> > > > > been out for nearly two years now. A good starting place for
> > > > > general JSF
> > > > > knowledge and information is <http://jsfcentral.com>. Kito does a
> > > > > good job
> > > > > of staying on top of the most recent articles and items of
> > > > > interest. This,
> > > > > by the way, is *exactly* the place to start before looking much at
> > > > > Shale
> > > > > itself -- Shale *srongly* presumes that you are familiar with JSF,
> > > > > and what
> > > > > it brings to the table all by itself, because it focuses on adding
> > > > > value
> > > > > around the edges. Without understanding those edges a little, it's
> > > > > harder
> > > > > to appreciate the benefits :-).
> > > >
> > > > Okay, I'll try to find a "hello world" JSF example. That might be
> > > > enough for me to build on.
> > > >
> > > > A question comes up: what has happened to Tiles? Is it no longer a
> > > > part of Struts? I'm still terribly unfamiliar with the new Struts
> > > > website.
> > > >
> > > > Do I bother creating a nice Tiles hierarchy of layouts and tiles? Or
> > > > is there some other way to get site L&F re-use?
> > > >
> > > > > Beyond the Shale web site[1], there's not a heck of a lot of stuff
> > > > > yet. One
> > > > > high level overview is the session I did at ApacheCon (reprised
> > > > > from one
> > > > > that David Geary and I did at JavaOne)[2] ... but the slides lose a
> > > > > little
> > > > > in the translation without the corresponding demo program, which is
> > > > > not in a
> > > > > shape that I'm quite ready to check in yet :-).
> > > >
> > > > Okay, I'll hold off worrying about Shale for now. Sounds like I can
> > > > work it in easily enough when the time comes.
> > > >
> > > >
> > > > Here's my big question: do I still think in terms of Struts Actions
> > > > handling the business logic of my application (which they rarely do;
> > > > they usually glue to the "real" biz code)? Or do I look to putting
> > > > all that glue within JSF controllers?
> > > >
> > > > Thanks!
> > > >
> > > > --
> > > > Rick
> > > >
> > > >
> > > >
> > > >
> ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail:
> user-unsubscribe@struts.apache.org
> > > > For additional commands, e-mail: user-help@struts.apache.org
> > > >
> > > >
> > >
> > >
> > > --
> > > "You can lead a horse to water but you cannot make it float on its
> back."
> > > ~Dakota Jack~
> > >
> > >
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail:
> user-unsubscribe@struts.apache.org
> > For additional commands, e-mail: user-help@struts.apache.org
> >
> >
>
>
>
> --
>
> "You can lead a horse to water but you cannot make it float on its back."
> ~Dakota Jack~
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Advice for Struts expert wanting to try Shale?
Posted by Mark Lowe <me...@gmail.com>.
On 1/7/06, Dakota Jack <da...@gmail.com> wrote:
> JSF is page centric rather than Action centric. There is no controller as
> you understand that in Struts with JSF. JSF is for a tool based, dumbed
> down, approach: JSF is to Struts as Visual Basic is to C++.
JSF is more page centric than struts, but they aren't chalk and
cheese. The view controller is still in the backing bean and then
mapping of outcome to jsp is done via xml configuration. How page or
controller centric you want jsf to be is upto you, this is where the
diffence between JSF being a spec and struts a framework start being
more visible.
If I was asking how to get started with jsf and shale I'd find your VB
vs C++ statement confusing and not very helpful at all.
Mark
>
> On 1/6/06, Rick Mann <rm...@latencyzero.com> wrote:
> >
> > Thanks for the response, Craig. It's nice to get an answer from THE
> > authority :-). Questions below...
> >
> > On Jan 6, 2006, at 5:16 PM, Craig McClanahan wrote:
> >
> > > I'd definitely ignore anything about prereleases of JSF 1.0 ...
> > > that has
> > > been out for nearly two years now. A good starting place for
> > > general JSF
> > > knowledge and information is <http://jsfcentral.com>. Kito does a
> > > good job
> > > of staying on top of the most recent articles and items of
> > > interest. This,
> > > by the way, is *exactly* the place to start before looking much at
> > > Shale
> > > itself -- Shale *srongly* presumes that you are familiar with JSF,
> > > and what
> > > it brings to the table all by itself, because it focuses on adding
> > > value
> > > around the edges. Without understanding those edges a little, it's
> > > harder
> > > to appreciate the benefits :-).
> >
> > Okay, I'll try to find a "hello world" JSF example. That might be
> > enough for me to build on.
> >
> > A question comes up: what has happened to Tiles? Is it no longer a
> > part of Struts? I'm still terribly unfamiliar with the new Struts
> > website.
> >
> > Do I bother creating a nice Tiles hierarchy of layouts and tiles? Or
> > is there some other way to get site L&F re-use?
> >
> > > Beyond the Shale web site[1], there's not a heck of a lot of stuff
> > > yet. One
> > > high level overview is the session I did at ApacheCon (reprised
> > > from one
> > > that David Geary and I did at JavaOne)[2] ... but the slides lose a
> > > little
> > > in the translation without the corresponding demo program, which is
> > > not in a
> > > shape that I'm quite ready to check in yet :-).
> >
> > Okay, I'll hold off worrying about Shale for now. Sounds like I can
> > work it in easily enough when the time comes.
> >
> >
> > Here's my big question: do I still think in terms of Struts Actions
> > handling the business logic of my application (which they rarely do;
> > they usually glue to the "real" biz code)? Or do I look to putting
> > all that glue within JSF controllers?
> >
> > Thanks!
> >
> > --
> > Rick
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> > For additional commands, e-mail: user-help@struts.apache.org
> >
> >
>
>
> --
> "You can lead a horse to water but you cannot make it float on its back."
> ~Dakota Jack~
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Advice for Struts expert wanting to try Shale?
Posted by Dakota Jack <da...@gmail.com>.
JSF is page centric rather than Action centric. There is no controller as
you understand that in Struts with JSF. JSF is for a tool based, dumbed
down, approach: JSF is to Struts as Visual Basic is to C++.
On 1/6/06, Rick Mann <rm...@latencyzero.com> wrote:
>
> Thanks for the response, Craig. It's nice to get an answer from THE
> authority :-). Questions below...
>
> On Jan 6, 2006, at 5:16 PM, Craig McClanahan wrote:
>
> > I'd definitely ignore anything about prereleases of JSF 1.0 ...
> > that has
> > been out for nearly two years now. A good starting place for
> > general JSF
> > knowledge and information is <http://jsfcentral.com>. Kito does a
> > good job
> > of staying on top of the most recent articles and items of
> > interest. This,
> > by the way, is *exactly* the place to start before looking much at
> > Shale
> > itself -- Shale *srongly* presumes that you are familiar with JSF,
> > and what
> > it brings to the table all by itself, because it focuses on adding
> > value
> > around the edges. Without understanding those edges a little, it's
> > harder
> > to appreciate the benefits :-).
>
> Okay, I'll try to find a "hello world" JSF example. That might be
> enough for me to build on.
>
> A question comes up: what has happened to Tiles? Is it no longer a
> part of Struts? I'm still terribly unfamiliar with the new Struts
> website.
>
> Do I bother creating a nice Tiles hierarchy of layouts and tiles? Or
> is there some other way to get site L&F re-use?
>
> > Beyond the Shale web site[1], there's not a heck of a lot of stuff
> > yet. One
> > high level overview is the session I did at ApacheCon (reprised
> > from one
> > that David Geary and I did at JavaOne)[2] ... but the slides lose a
> > little
> > in the translation without the corresponding demo program, which is
> > not in a
> > shape that I'm quite ready to check in yet :-).
>
> Okay, I'll hold off worrying about Shale for now. Sounds like I can
> work it in easily enough when the time comes.
>
>
> Here's my big question: do I still think in terms of Struts Actions
> handling the business logic of my application (which they rarely do;
> they usually glue to the "real" biz code)? Or do I look to putting
> all that glue within JSF controllers?
>
> Thanks!
>
> --
> Rick
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
--
"You can lead a horse to water but you cannot make it float on its back."
~Dakota Jack~
Re: validator problems
Posted by ch...@kattare.com.
Thanks for this you're quite right. That was exactly what I'd done!
chhum
Quoting Niall Pemberton <ni...@blueyonder.co.uk>:
> Looks like you have the wrong version of validator-rules.xml
> deployed. You
> don't say what version of struts you're using, but my guess is you're
> using
> Struts 1.2.7 or Struts 1.2.8 with a validator-rules.xml from an
> earlier
> version of Struts. Try deploying the validator-rules.xml that comes
> with the
> version of struts you're using.
>
> When you change versions of struts - its worth checking out the
> upgrade
> notes on the wiki:
>
> http://wiki.apache.org/struts/StrutsUpgradeNotes124to127
> http://wiki.apache.org/struts/StrutsUpgrade
>
> Niall
>
> ----- Original Message -----
> From: <ch...@kattare.com>
> Sent: Saturday, February 25, 2006 3:47 PM
>
>
> > Hi,
> > Sorry if you've seen this before - I sent it earlier but never saw
> it
> > come back.
> >
> > I'm try to use the validator to check some details on a form
> (field
> > lengths for example). When I run the form the validator doesn't
> seem to
> > run, though a call goes to it. I end up with a stack trace in the
> logs
> like
> > org.apache.struts.validator.DynaValidatorForm validate
> > SEVERE:
> >
> org.apache.struts.validator.FieldChecks.validateRequired(java.lang.Object,
> > org.apache.commons.validator.ValidatorAction,
> > org.apache.commons.validator.Field,
> > org.apache.struts.action.ActionMessages,
> > javax.servlet.http.HttpServletRequest)
> > org.apache.commons.validator.ValidatorException:
> >
> org.apache.struts.validator.FieldChecks.validateRequired(java.lang.Object,
> > org.apache.commons.validator.ValidatorAction,
> > org.apache.commons.validator.Field,
> > org.apache.struts.action.ActionMessages,
> > javax.servlet.http.HttpServletRequest)
> > at
> >
>
org.apache.commons.validator.ValidatorAction.loadValidationMethod(ValidatorA
> ction.java:627)
> >
> > What am I doing wrong?
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: validator problems
Posted by Niall Pemberton <ni...@blueyonder.co.uk>.
Looks like you have the wrong version of validator-rules.xml deployed. You
don't say what version of struts you're using, but my guess is you're using
Struts 1.2.7 or Struts 1.2.8 with a validator-rules.xml from an earlier
version of Struts. Try deploying the validator-rules.xml that comes with the
version of struts you're using.
When you change versions of struts - its worth checking out the upgrade
notes on the wiki:
http://wiki.apache.org/struts/StrutsUpgradeNotes124to127
http://wiki.apache.org/struts/StrutsUpgrade
Niall
----- Original Message -----
From: <ch...@kattare.com>
Sent: Saturday, February 25, 2006 3:47 PM
> Hi,
> Sorry if you've seen this before - I sent it earlier but never saw it
> come back.
>
> I'm try to use the validator to check some details on a form (field
> lengths for example). When I run the form the validator doesn't seem to
> run, though a call goes to it. I end up with a stack trace in the logs
like
> org.apache.struts.validator.DynaValidatorForm validate
> SEVERE:
> org.apache.struts.validator.FieldChecks.validateRequired(java.lang.Object,
> org.apache.commons.validator.ValidatorAction,
> org.apache.commons.validator.Field,
> org.apache.struts.action.ActionMessages,
> javax.servlet.http.HttpServletRequest)
> org.apache.commons.validator.ValidatorException:
> org.apache.struts.validator.FieldChecks.validateRequired(java.lang.Object,
> org.apache.commons.validator.ValidatorAction,
> org.apache.commons.validator.Field,
> org.apache.struts.action.ActionMessages,
> javax.servlet.http.HttpServletRequest)
> at
>
org.apache.commons.validator.ValidatorAction.loadValidationMethod(ValidatorA
ction.java:627)
>
> What am I doing wrong?
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
validator problems
Posted by ch...@kattare.com.
Hi,
Sorry if you've seen this before I sent it earlier but never saw it
come back.
I'm try to use the validator to check some details on a form (field
lengths for example). When I run the form the validator doesn't seem to
run, though a call goes to it. I end up with a stack trace in the logs like
org.apache.struts.validator.DynaValidatorForm validate
SEVERE:
org.apache.struts.validator.FieldChecks.validateRequired(java.lang.Object,
org.apache.commons.validator.ValidatorAction,
org.apache.commons.validator.Field,
org.apache.struts.action.ActionMessages,
javax.servlet.http.HttpServletRequest)
org.apache.commons.validator.ValidatorException:
org.apache.struts.validator.FieldChecks.validateRequired(java.lang.Object,
org.apache.commons.validator.ValidatorAction,
org.apache.commons.validator.Field,
org.apache.struts.action.ActionMessages,
javax.servlet.http.HttpServletRequest)
at
org.apache.commons.validator.ValidatorAction.loadValidationMethod(ValidatorAction.java:627)
What am I doing wrong?
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Advice for Struts expert wanting to try Shale?
Posted by Ted Husted <te...@gmail.com>.
On 1/6/06, Rick R <st...@reumann.net> wrote:
> Craig, do you have this posted anywhere other than here on this list?
> This is a great summary that I've actually been looking for, so I'm glad
> I peeked into this thread. Thanks.>
> You should add this to your blog somewhere or it should be on JSF
> Central. I'd like to bookmark it.
Or, someone could give Craig a hand and start adding posts like this
to the wiki. :)
* http://wiki.apache.org/struts/StrutsShale
No reason to let Craig have all the fun.
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Advice for Struts expert wanting to try Shale?
Posted by Rick R <st...@reumann.net>.
Craig, do you have this posted anywhere other than here on this list?
This is a great summary that I've actually been looking for, so I'm glad
I peeked into this thread. Thanks.
You should add this to your blog somewhere or it should be on JSF
Central. I'd like to bookmark it.
Craig McClanahan wrote:
> For someone familiar with Struts 1.x, I would draw the following analogies:
>
> * Where in Struts you have an Action and an ActionForm,
> with JSF you tend to combine them into a single request
> scope object.
>
> * Where an ActionForm tells you to use Strings for the properties,
> JSF components deal with conversion for you, so you can use
> native data types.
>
> * It's also possible to bind JSF components directly to POJO
> model objects if you want ... sorta like what WebWork does too.
>
> * Where Struts actions tend to have either a single execute()
> method for the entire page, or some sort of dispatch mechanism,
> you tend to bind each submit button in a JSF page to a separate
> action method in some backing bean (although you can share
> them if two different buttons should really do the same thing).
>
> * Just like an Action in Struts, the action method called by JSF
> should be considered an adapter to the "real" business logic
> (although, just like you can do with Struts, it's possible to embed
> business logic directly in the method :-).
>
> * Shale's ViewController adds the notion of application event calbacks
> to the strictly UI events that JSF supports. Of particular interest
> is the prerender() callback, which is invoked just before the next
> page actually renders ... the perfect place to do what you'd put in
> a "setup action" in a traditionally architected Struts application.
>
> As you become more familiar with JSF and Shale, you're likely to end up
> agreeing with my judgement on the best two features of the combination for
> an experienced Struts developer contemplating using JSF:
>
> * Managed beans extend the Struts concept of magically instantiating
> ActionForm beans, and makes it general purpose -- they can be
> created indirectly by virtue of being bound to a component property,
> or you can evaluate expressions programmatically (with the possible
> side effects of creating new objects on the fly). Plus, you get basic
> dependency injection for free ... if your DI needs are relatively simple,
> you don't need something like Spring -- although you can certainly use
> that as well if you need it.
>
> * Shale dialogs address one of the tougher architectural areas in
> Struts 1.x ... how to deal with setup actions versus process actions,
> and how to organize everything. Dialogs lets you divide up your
> application into states (action state = method execution, view state =
> page rendering + the following form submit, subdialog state lets you
> treat dialogs as black box subroutines). Every state returns a logical
> outcome string, which can be used to drive transitions to other states.
> And, you can have as many action states as you like between view
> states. It's pretty easy to architect the overall organization of the
> application in these terms, and to divide things up into logically
> separate
> units of work.
>
> Craig
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Advice for Struts expert wanting to try Shale?
Posted by Craig McClanahan <cr...@apache.org>.
On 1/6/06, Rick Mann <rm...@latencyzero.com> wrote:
>
> Thanks for the response, Craig. It's nice to get an answer from THE
> authority :-). Questions below...
>
> On Jan 6, 2006, at 5:16 PM, Craig McClanahan wrote:
>
> > I'd definitely ignore anything about prereleases of JSF 1.0 ...
> > that has
> > been out for nearly two years now. A good starting place for
> > general JSF
> > knowledge and information is <http://jsfcentral.com>. Kito does a
> > good job
> > of staying on top of the most recent articles and items of
> > interest. This,
> > by the way, is *exactly* the place to start before looking much at
> > Shale
> > itself -- Shale *srongly* presumes that you are familiar with JSF,
> > and what
> > it brings to the table all by itself, because it focuses on adding
> > value
> > around the edges. Without understanding those edges a little, it's
> > harder
> > to appreciate the benefits :-).
>
> Okay, I'll try to find a "hello world" JSF example. That might be
> enough for me to build on.
Good. The JSF RI comes with several samples, as does MyFaces.
A question comes up: what has happened to Tiles? Is it no longer a
> part of Struts? I'm still terribly unfamiliar with the new Struts
> website.
Tiles itself is definitely still part of the Struts project. Two things are
happening to it:
* Organizationally, it becomes a subproject of Struts (just like Shale), so
that
it could be released independently of the rest of the core framework.
* Technically, there is a sandbox version of Tiles that has its
Struts-Action-Framework
dependencies removed, so that it could be used with any MVC framework (and
Shale
is currently using a snapshot version of this code).
Do I bother creating a nice Tiles hierarchy of layouts and tiles? Or
> is there some other way to get site L&F re-use?
Tiles is still one option for this (indeed, besides the Shale integration,
MyFaces's JSF implementation comes with their own integration of the
original Struts tiles code.) Another approach is to look for component
solutions that do layout management for you -- plus things like the "Clay"
plugin to Shale, which lets you accomplish lots of the same sorts of reuse
issues, but at a finer grained level than just a page or a tile. The Shale
use cases example app has several ways in which Clay can be used like this.
If that's not enough technologies to look at :-), there's another
interesting approach to reusing layouts called Facelets[1]. Like Clay,
Facelets leverages a JSF extensibility point called a "ViewHandler" that
lets you be pretty innovative at substituting in alternatives to JSP as the
mechanism for authoring the view pages of your application.
> Beyond the Shale web site[1], there's not a heck of a lot of stuff
> > yet. One
> > high level overview is the session I did at ApacheCon (reprised
> > from one
> > that David Geary and I did at JavaOne)[2] ... but the slides lose a
> > little
> > in the translation without the corresponding demo program, which is
> > not in a
> > shape that I'm quite ready to check in yet :-).
>
> Okay, I'll hold off worrying about Shale for now. Sounds like I can
> work it in easily enough when the time comes.
We'l be here :-).
Here's my big question: do I still think in terms of Struts Actions
> handling the business logic of my application (which they rarely do;
> they usually glue to the "real" biz code)? Or do I look to putting
> all that glue within JSF controllers?
For someone familiar with Struts 1.x, I would draw the following analogies:
* Where in Struts you have an Action and an ActionForm,
with JSF you tend to combine them into a single request
scope object.
* Where an ActionForm tells you to use Strings for the properties,
JSF components deal with conversion for you, so you can use
native data types.
* It's also possible to bind JSF components directly to POJO
model objects if you want ... sorta like what WebWork does too.
* Where Struts actions tend to have either a single execute()
method for the entire page, or some sort of dispatch mechanism,
you tend to bind each submit button in a JSF page to a separate
action method in some backing bean (although you can share
them if two different buttons should really do the same thing).
* Just like an Action in Struts, the action method called by JSF
should be considered an adapter to the "real" business logic
(although, just like you can do with Struts, it's possible to embed
business logic directly in the method :-).
* Shale's ViewController adds the notion of application event calbacks
to the strictly UI events that JSF supports. Of particular interest
is the prerender() callback, which is invoked just before the next
page actually renders ... the perfect place to do what you'd put in
a "setup action" in a traditionally architected Struts application.
As you become more familiar with JSF and Shale, you're likely to end up
agreeing with my judgement on the best two features of the combination for
an experienced Struts developer contemplating using JSF:
* Managed beans extend the Struts concept of magically instantiating
ActionForm beans, and makes it general purpose -- they can be
created indirectly by virtue of being bound to a component property,
or you can evaluate expressions programmatically (with the possible
side effects of creating new objects on the fly). Plus, you get basic
dependency injection for free ... if your DI needs are relatively simple,
you don't need something like Spring -- although you can certainly use
that as well if you need it.
* Shale dialogs address one of the tougher architectural areas in
Struts 1.x ... how to deal with setup actions versus process actions,
and how to organize everything. Dialogs lets you divide up your
application into states (action state = method execution, view state =
page rendering + the following form submit, subdialog state lets you
treat dialogs as black box subroutines). Every state returns a logical
outcome string, which can be used to drive transitions to other states.
And, you can have as many action states as you like between view
states. It's pretty easy to architect the overall organization of the
application in these terms, and to divide things up into logically
separate
units of work.
Craig
Thanks!
>
> --
> Rick
Craig
[1] http://facelets.dev.java.net
---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
Re: Advice for Struts expert wanting to try Shale?
Posted by Rick Mann <rm...@latencyzero.com>.
Thanks for the response, Craig. It's nice to get an answer from THE
authority :-). Questions below...
On Jan 6, 2006, at 5:16 PM, Craig McClanahan wrote:
> I'd definitely ignore anything about prereleases of JSF 1.0 ...
> that has
> been out for nearly two years now. A good starting place for
> general JSF
> knowledge and information is <http://jsfcentral.com>. Kito does a
> good job
> of staying on top of the most recent articles and items of
> interest. This,
> by the way, is *exactly* the place to start before looking much at
> Shale
> itself -- Shale *srongly* presumes that you are familiar with JSF,
> and what
> it brings to the table all by itself, because it focuses on adding
> value
> around the edges. Without understanding those edges a little, it's
> harder
> to appreciate the benefits :-).
Okay, I'll try to find a "hello world" JSF example. That might be
enough for me to build on.
A question comes up: what has happened to Tiles? Is it no longer a
part of Struts? I'm still terribly unfamiliar with the new Struts
website.
Do I bother creating a nice Tiles hierarchy of layouts and tiles? Or
is there some other way to get site L&F re-use?
> Beyond the Shale web site[1], there's not a heck of a lot of stuff
> yet. One
> high level overview is the session I did at ApacheCon (reprised
> from one
> that David Geary and I did at JavaOne)[2] ... but the slides lose a
> little
> in the translation without the corresponding demo program, which is
> not in a
> shape that I'm quite ready to check in yet :-).
Okay, I'll hold off worrying about Shale for now. Sounds like I can
work it in easily enough when the time comes.
Here's my big question: do I still think in terms of Struts Actions
handling the business logic of my application (which they rarely do;
they usually glue to the "real" biz code)? Or do I look to putting
all that glue within JSF controllers?
Thanks!
--
Rick
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Advice for Struts expert wanting to try Shale?
Posted by Rick Mann <rm...@latencyzero.com>.
I should clarify: not all our Actions are just "glue". They perform
significant work when such work is constrained to the website needs
(choosing what data to display). When it comes to purchases and
registration, however, they are more like glue, even even more so
when some functions are called by non-web-container code (for
example, our automated subscription renewals).
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Advice for Struts expert wanting to try Shale?
Posted by Craig McClanahan <cr...@apache.org>.
On 1/6/06, Rick Mann <rm...@latencyzero.com> wrote:
>
> Hi. I've done a couple of industrial-strength websites using Struts,
> Tiles & JSTL. I decided to start on a little personal project, mostly
> as a way to get on board with some technologies, some of which I've
> used before (maven 1/2, torque), some which I want to learn (JSF,
> Shale).
>
> I looked around the Shale pages a bit last night, and found myself
> unable to grasp what it offered. I also looked at some of the JSF
> introductory articles, and was concerned that they referenced pre-
> release versions of JSF, and didn't reference Shale.
I'd definitely ignore anything about prereleases of JSF 1.0 ... that has
been out for nearly two years now. A good starting place for general JSF
knowledge and information is <http://jsfcentral.com>. Kito does a good job
of staying on top of the most recent articles and items of interest. This,
by the way, is *exactly* the place to start before looking much at Shale
itself -- Shale *srongly* presumes that you are familiar with JSF, and what
it brings to the table all by itself, because it focuses on adding value
around the edges. Without understanding those edges a little, it's harder
to appreciate the benefits :-).
I'm happy to abandon Struts if it makes sense, and certainly I'd like
> to replace Struts components when functionality is provided by Shale/
> JSF.
>
> Can someone point me to (or give me) an appropriate overview? Thank
> you very much!
Beyond the Shale web site[1], there's not a heck of a lot of stuff yet. One
high level overview is the session I did at ApacheCon (reprised from one
that David Geary and I did at JavaOne)[2] ... but the slides lose a little
in the translation without the corresponding demo program, which is not in a
shape that I'm quite ready to check in yet :-).
--
> Rick
Craig
[1] http://struts.apache.org/struts-shale/
[2] http://people.apache.org/~craigmcc/apachecon-2005-shale.pdf