使用 Stripes 的实际经验？
我有 Enterprise Java 背景，涉及相当重量级的软件堆栈，最近发现 Stripes 框架； 我最初的印象是，这似乎很好地减少了用 Java 构建 Web 应用程序的不愉快的部分。
有人在已经上线的项目中使用过 Stripes 吗？ 您能分享一下您在该项目中的经验吗？ 另外，您是否考虑过任何其他技术？（如果有）您为什么选择 Stripes？
I am coming from an Enterprise Java background which involves a fairly heavyweight software stack, and have recently discovered the
Stripes framework; my initial impression is that this seems to do a good job of minimising the unpleasant parts of building a web application in Java.
Has anyone used Stripes for a project that has gone live? And can you share your experiences from the project? Also, did you consider any other technologies and (if so) why did you chose Stripes?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
如果您可以选择像 GWT 这样更现代的东西，Stripes 已经是昨天的技术了。
Stripes is yesterdays technology, if you can pick something a little more modern like GWT.
我们现在已经在多个制作项目中使用了 Stripes，到目前为止，体验非常好。 设置时间很短，配置管理问题似乎也更少。 我们有使用 Stripes/Dojo/Hibernate 运行的 Web 应用程序以及其他混合使用 Stripes/Spring/JSP/Jquery 等的 Web 应用程序。由于它们支持集成现有 Spring 配置，因此将 Stripes 添加到我们现有的项目中相当简单。 将 Stripes 与 JSP 结合使用很有趣，尽管有时您确实觉得需要用 Java 编写代码，而不必过多使用 JSTL。
笔记：
这是一个老问题，但考虑到当您搜索 Stripes 用法时它会很快弹出，我正在添加对此的响应。
We have now used Stripes in multiple production projects and so far the experience has been great. Setup time is low and the configuration management issues seem to be fewer. We have webapps running with Stripes/Dojo/Hibernate and others with a mix of Stripes/Spring/JSP/Jquery etc. Adding Stripes to our existing projects was fairly simple thanks to their support for integrating existing Spring configurations. Using Stripes with JSP is fun although sometimes you do feel the need to code in Java and not have to use the JSTL so much.
Note:
This is an old question, but given that it pops up pretty fast when you search for Stripes usage, I am adding a response to it.
我也有 Struts 和 JSF 的背景，后来进入了 Stripes。 我从一个在较新的项目中主要使用 struts 和 JSF 的大型企业环境，转变为一个在 Stripes 中完成所有 J2EE 的较小环境。
看起来 Stripes 可以为您提供 Web 框架中所需的功能，而不会造成太多干扰。 正如其他人已经提到的那样，不需要太多配置。 开发速度非常快，让您可以专注于演示等，而不用为框架而烦恼。
如果我必须开始一个全新的项目并且我有发言权，我会选择 Stripes 或 JSF。 如果我不得不做出切换到 Stripes 的决定，我可能会被吓到，因为它看起来/感觉像是一个 Sourceforge 地下室项目，而不是一个企业级框架，但它似乎相当可靠。 我们使用 Stripernate 来实现简单的 ORM。
然而，它让我想起了水果条纹口香糖，它太失去了味道快速地。
I also came from a Struts and JSF background into Stripes. I went from a large enterprise environment that used mostly struts and JSF on newer projects, to a smaller environment that did all their J2EE in Stripes.
Seems like Stripes gives you what you want in a Web Framework without getting in the way too much. Not much configuration is necessary, as others have already mentioned. Very quick development and allows you to focus on presentation etc. instead of hassling with the framework.
If I had to start a fresh new project and I had my say, I would choose either Stripes or JSF. I might have been scared away from Stripes if I had to make the decision to switch to it, because it kind of looks/feels like a sourceforge basement project instead of a enterprise-grade framework, but it seems to be fairly solid. We use Stripernate for easy ORM.
However, it reminds me of Fruit Stripe gum, which lost its flavor WAY TOO FAST.
我们在大约一周内将自制的 Web 框架转换为 stripes。 我们目前正在生产中使用它，它是一个很棒的框架。 社区非常有帮助，而且框架不会妨碍您。 它可以在许多地方扩展以改变您认为合适的行为。 url 绑定功能也很棒。 我们使用注释和拦截器实现了一个强大的安全框架。 我们使用 spring 进行依赖注入，stripes 对此有很好的支持。
如果您要使用新的 1.5 版本，我肯定会使用它。
我是这个框架的超级粉丝。 我有 struts 背景，这正是我正在寻找的框架。 我们团队中的其他开发人员非常喜欢使用 stripes 框架。
我刚刚从务实程序员的网站上购买了 Stripes Beta 版书。 这是 Stripes 1.5 上的一个很棒的资源。
We converted a home-grown web framework to stripes in about a week. We're using it in production at this time and it's a great framework. The community is extremely helpful, and the framework doesn't get in your way. It can be extended in many places to change the behavior as you see fit. The url binding feature is awesome as well. We implemented a robust security framework using annotations and interceptors. We're using spring for dependency injection and stripes has excellent support for that.
I'd definitely use the new 1.5 release if you're going to use it.
I'm a huge fan of the framework. I came from a struts background and it's the exact framework I was looking for. The other developers on our team really enjoy using the stripes framework.
I just bought the stripes beta book from the pragmatic programmer's site. It's a great resource on Stripes 1.5.
我们现在在所有生产基地都使用条纹，并且已经使用了大约一年。 与我们之前使用的 struts 相比，它是一个很棒的产品。 事实上，实际上没有 XML 配置文件，并且您可以使用最少量的类和注释来设置所有这些，这真是太棒了。
在缩放方面 速度上它实际上似乎比 struts 更好，我的猜测是因为涉及的层数较少。 您最终得到的代码也更加简洁，因为您不必去单独的 XML 文件来找出重定向的去向。
我们将它与 EJB3 后端一起使用，两者似乎可以很好地协同工作，因为您可以在 actionBean 对象中使用 EJB POJO，而不需要像 struts 中那样的表单对象。
在我们的评估中，我们考虑了 struts 的 alpha 版本（支持注释）和许多其他框架，但 stripes 因其卓越的文档、稳定性和简洁性而获胜。
无法弄清楚如何发表评论：所以回答你的第二个问题，据我所知，我们在 Stripes 中没有遇到任何错误。 对于一个开源框架来说，这是相当令人印象深刻的。 我还没有尝试过最新版本（1.5），但是1.4.x非常稳定。
We use stripes now on all our production sites, and have been for about a year now. It is an awesome product compared to struts, which we used to use before that. Just the fact that there are literally no XML config files and that you can set it all up with a minimal amount of classes and annotations is awesome.
In terms of scaling & speed it actually seems to be better than struts, and my guess would be because there are less layers involved. The code you end up with is a lot cleaner as well, because you don't have to go off to seperate XML files to find out where redirects are going.
We use it with an EJB3 backend, and the two seem to work really well together, because you can use your EJB POJO inside your actionBean object, without needing a form object like in struts.
In our evaluation we considered an alpha version of struts (that supported annotations) and a lot of other frameworks, but stripes won because of it's superior documentation, stability and clean-ness.
Couldn't figure out how to leave a comment: so to answer your second question we haven't encountered a single bug in Stripes that I know of. This is quite impressive for an open source framework. I haven't tried the latest version (1.5) yet, but 1.4.x is very stable.
我们使用 Stripes 已有大约 4 年了。 我们的堆栈是 Stripes/EJB3/JPA。
许多人使用 Stripes 和 Stripernate 作为单一的全栈解决方案。 我们不这样做，因为我们希望我们的业务逻辑位于 EJB 层中，因此我们只是依赖 JPA 实体作为模型和 DTO 的组合。
Stripes 绑定到我们的实体/DTO，然后我们将它们推回 EJB 层进行工作。 对于我们的大多数 CRUD 内容来说，这是非常简单的事情，使得我们 80% 的用例使用起来很简单。 然而，对于总是出现复杂应用程序的边缘情况，我们可以灵活地做任何我们想做的事情。
我们有一个非常大的基础 Action Bean，它封装了大部分 CRUD 操作，这些操作回调特定于实体和表单的各个子类。
我们还有一个大型内部标签文件库来管理我们的页面、安全、导航、任务等。一个简单的 CRUD 编辑表单只不过是一个字段名称列表，我们获得了所有的镶边、菜单和访问控制“免费”。
这样做的好处在于，我们可以保留我们喜欢的基于 HTTP 请求的隐喻，并且可以选择系统的各个部分，而不是使用一个庞大的堆栈。 条纹层简洁而朴素，并且永远不会妨碍我们。
我们有一堆集成 YUI 和 JQuery 的 Ajax，所有这些都可以轻松地针对我们的 Stripes 和 EJB 堆栈工作。
我还将该堆栈的较轻版本移植到 GAE 作为示例项目，基本上需要对我们的 EJB 层做一些小工作。 因此，整个堆栈非常灵活且易于更改。 条纹是其中的一个重要因素，因为我们让它做它能做的几件事，而且做得很好。 然后将其余部分委托给堆栈的其他部分。
一如既往，人们有时宁愿拥有不同的部件，但坦率地说，条纹将是我们堆栈中的最后一个部件。 它可以更好地支持完整的 HTTP 动词集，但我宁愿修复 Stripes 来更好地做到这一点，而不是切换到其他东西。
We've been using Stripes for about 4 years now. Our stack is Stripes/EJB3/JPA.
Many use Stripes plus Stripernate as a single, full stack solution. We don't because we want our business logic within the EJB tier, so we simply rely on JPA Entities as combined Model and DTO.
Stripes does the binding to our Entities/DTO and we shove them back in to the EJB tier for work. For most of our CRUD stuff this is very thing and straightforward, making our 80% use case trivial to work with. Yet we have the flexibility to do whatever we want for the edge cases that always come up with complicate applications.
We have a very large base Action Bean which encapsulates the bulk of our CRUD operations that makes call backs in to the individual subclasses specific to the entities and forms.
We also have a large internal tag file library to manage our pages, security, navigation, tasks, etc. A simple CRUD edit form is little more than a list of field names, and we get all of the chrome and menus and access controls "for free".
The beauty of this is that we get to keep the HTTP request based metaphor that we like and we get to choose the individual parts of the system rather than use one fat stack. The Stripes layer is lean and mean, and never gets in our way.
We have a bunch of Ajax integrating YUI and JQuery, all working against our Stripes and EJB stack painlessly.
I also ported a lighter version of the stack to GAE for a sample project, basically having to do minor work to our EJB tier. So, the entire stack is very nimble and amicable to change. Stripes is a big factor of that since we let it do the few things that it does, and does very well. Then delegate the rest to other parts of the stack.
As always there are parts folks would rather have different at times, but Stripes would be the last part to go in our stack, frankly. It could be better at supporting the full HTTP verb set, but I'd rather fix Stripes to do that better than switch over to something else.