Freddy, Will, Ben, and all the regulars and new faces -
Long time, no see, had some time and a wild hair and decided to see what was up
on the Stripes boards. I hope all is well with you and yours.
Interesting to see some existential discussion and debate--always healthy to
see
that come up periodically. I got on the Stripes bandwagon pretty early and my
heart is still there. But I haven't been able to completely commit to Stripes
enough to wholeheartedly evangelize it to our enterprise here as our group's
profile has risen and influence has grown. The problem is that our enterprise
(huge IT org of 16k people with dev groups all over the world) is starting to
roll out enterprise infrastructure like (websphere) portal that everyone is
being expected to integrate with. With all the massive emphasis on portal,
Stripes is almost a non-starter. If only Stripes had a portlet framework, the
Spring apologists wouldn't have a leg to stand on. As it stands, I'm faced
with
the prospect of telling groups to use Stripes for their web apps, but to use
Spring's portlet framework and then to have to do all their integrations on
both
fronts. At that point, no one has patience to continue listening, especially
since SpringMVC is a reasonable option. SpringMVC still stinks compared to
Stripes, but it has come a long way. The frustrating thing is that SpringMVC
has come far enough that those who only really look at the surface similarities
(either because that's how they roll, or because they are Spring apologists
looking for an excuse) see more similarities than really exist. Can you have
an
EntityTypeConverter (ala Stripersist or my stack) in Spring? Yep, and it's
almost as good, once you decide on which of the 4 parallel/competing ways of
creating a Spring analog to Stripes TypeConverters that you are going to use.
Can you have controllers with multiple handlers on them, driven by annotations?
Sure, but you have to do your own cooperation between form and controller to
get
that to work, and the annotation must be there--less convention-over-config.
And even then, you need to have a new CommandBean for each multicontroller if
you really want to get close to the Stripes experience. (Apologies if this
info
is a touch out of date, we last dived deep into SpringMVC several months ago.)
But again Spring has gotten closer. Close enough that situations like not
having a portlet framework are now the deciding factor.
I still don't think that extending Stripes out to a full-stack option is the
way
to go. The framework's uncanny ability to be easily integrated with all manner
of other frameworks for other areas of the stack I think is at least partially
due to the base design decision to favor as few other frameworks as possible
and
stay neutral. Way back when, the only other stack parts that had "official"
endorsement were o'reilly's file upload stuff and OGNL. Tim even found a way
to
give you a choice other than o'reilly and completely got OGNL out of the
picture. It's a philosophy that works--leave trying to be everything to
everyone to Spring, and let them deal with the consequences and related
bloat/drag.
I'd say, add support for the latest servlet api standards, perhaps finding some
crafty opportunities for enabling something Stripe-y. Also, add a portlet
framework, so anyone in an org where an enterprise portal is required
integration has a nice Stripesy dev experience available to them. And perhaps,
encourage /several/ shadow communities (such as informally exists with
Stripersist) to post links or maybe even host their codebases on the official
Stripes site. As most have seen, Stripes is a framework that has centered thus
far on choice. Let new users see several different full-stack options to
available to them via these shadow communities. Let those communities (and
this
proposed resident status for them) drive the perception that the community is
thriving, even if the core rarely needs much TLC.
I certainly hope Stripes never dies out--it's a great framework and a great
community. I also hope Stripes grows to fill only enough gaps such that there
doesn't emerge several reasons to take Stripes off the table in today's
enterprise.
-BD
________________________________
From: Freddy Daoud <xf2...@fastmail.fm>
To: stripes-users@lists.sourceforge.net
Sent: Fri, September 3, 2010 3:25:15 PM
Subject: Re: [Stripes-users] Stripes Development and its Future... (long)
Hi Joel,
> We are 99% sure we are going to go with Spring MVC. We are still implementing
the JPA/Spring based back end, so right now the UI is simply hello world, but it
was pretty simple to get at least something put together.
> The other consideration was JSF 2. I've been using JSF at my full time job
for about 3 years now and seen some successes and some difficulties with it.
While JSF 2 is much, much better than JSF 1.x, for this project the whole
component model felt way too heavy, which is why Stripes was such a draw.
> I'm anxiously looking forward to your thoughts on the subject, Freddy.
Well, if I was not allowed to use Stripes for whatever reason, I would
definitely prefer Spring MVC over JSF 2. JSF 1.x is awful, and JSF 2,
although not as bad, is still unnecessarily complicated.
I looked at Spring 3 briefly and liked what I saw. I didn't dig deep, so
I can't form a real opinion (there is more to a real web app than a
hello world form), but at least the "Spring requires too much configuration"
argument is no longer valid. Spring 3 does its part in using convention
over configuration, and using annotations instead of XML.
Cheers,
Freddy
------------------------------------------------------------------------------
This SF.net Dev2Dev email is sponsored by:
Show off your parallel programming skills.
Enter the Intel(R) Threading Challenge 2010.
http://p.sf.net/sfu/intel-thread-sfd
_______________________________________________
Stripes-users mailing list
Stripes-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/stripes-users
------------------------------------------------------------------------------
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev
_______________________________________________
Stripes-users mailing list
Stripes-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/stripes-users
