Barry, I like your idea of having stripes core and all the "shadow" libs In one
repo. This would let the core maintain it's great focus but also allow a great
community to be built around it. Think of what rails has done by allowing
people to easily extend it with it's own plugins. Something around maven could
be built to easily download and install plugins into a basic stripes project.
I agree that what is needed is not a pre packaged full stack framework, but a
loosely organized community of interdependent projects. Spring isn't it
either. Their new commercial intent has changed the tone of that community.
Stripes is in and interesting position to take advantage of the opportunity
that spring has created by disenfranchising a number of people.
The news stripes website is a great start. What can we do to organize the core
and extensions in a similar way?
Evan
Sent from my iPad
On Sep 17, 2010, at 9:48 PM, Barry Davies <barry.davi...@yahoo.com> wrote:
> 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
------------------------------------------------------------------------------
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
