News: Loom 1.0 final released
- Posted by: Ignacio Coloma
- Posted on: November 25 2008 14:39 EST
- smells like by M.J Milicevic on November 26 2008 11:04 EST
- Re: smells like by Will Hartung on November 26 2008 11:53 EST
- Re: smells like by H??ctor L??pez on November 26 2008 12:30 EST
- It all started as a stripes patch by Ignacio Coloma on November 26 2008 12:54 EST
- Loom and Jolene by Dan Howard on November 28 2008 18:36 EST
- Re: Loom 1.0 final released by shawn spencer on November 28 2008 20:39 EST
- Loom is the name of a widely know Description Logic by Anthony Berglas on November 29 2008 04:57 EST
- Re: Loom is the name of a widely know Description Logic by Ignacio Coloma on December 01 2008 06:08 EST
http://www.stripesframework.org something that already has some folowers, book(s) written about it and it works TM... So, I am wondering, why did pretty much "rebuild it" instead of trying to work with Stripe devs and build upon it.. I guess, answer is, because we can..
Really? Where does that leap come from? Given the 2 minutes I took to scan the "about", at a glance is seems to be a REST friendly, Ajax centric server side framework. While Stripes also handles validation through annotations, it certainly doesn't dig down in to the JPA level to support those annotations. Also, Stripes has no direct support for REST (and in one case is REST hostile), and certainly doesn't offer the CSS and JS consolidation features that Loom is promoting. Seems like Loom has a higher level "component" tag library over and above the basic building blocks that Stripes supports. So, as a fan, advocate, and "Friend" of Stripes, this doesn't look anything like it, and seems to handle a more specialized use case over what Stripes provides.
In defense of Loom and Ignacio (who does not pursue fame with Loom, i can assure), i must say that he implemented a patch for Stripes to add JPA Annotations to it. That patch was uploaded to the Stripes JIRA in 2006 IIRC (you can see it for yourself), but was "ignored" by the team. The issue is marked as pending with high priority (again IIRC), but there's no single comment on it. As you can see, cooperation is a two way desire... But anyway, Loom has many features that, IMO, fall behind the Stripes focus, and bureaucracy between a project lead and a prolific developer is often a headache.
Hi Héctor, thank you for explaining. It's pity it went this way, cause there are some interesting things done in Loom (which I would like to see within Stripes, either as a core or some add-on). In a next few days I'll have a closer look at Looms and if it's learning curve is close to that of Stripes well hoe knows ;-) Although, it would be much easier if it was part of Stripes... I already see it has a lot of potential (don't be discouraged by "yet another framework" comments, if those appear)
As Hector pointed out, some ideas were originally conceived as a Stripes patch: http://mc4j.org/jira/browse/STS-316 After a couple of months without response to this or other issues (such as the proposal to calculate automatically the maxlength attributes) we decided to switch to a different provider. Since there was nothing better at the time, we decided to roll our own solution. We considered forking at the time, but it was not really worth it and I didn't want to harm the Stripes community.
As Hector pointed out, some ideas were originally conceived as a Stripes patch:Interesting. I think it's noble that you didn't fork Stripes in order to protect the community, but on the other hand I think it's a shame you didn't. I think it's a shame that you had to redo the work, I think it's a shame that there is a bit of "core" code that's "not quite, but almost like Stripes" (I don't know how close in the end it really was). And, finally, I think it's a shame because if you HAD forked it, then perhaps there may have been motivation or consideration to later reintegrate with the core Stripes. And if you had forked, it most likely would have been much easier to do so. Mind, the goal is not to turn Stripes in to something like Loom, but rather turn Stripes in to something that something like Loom could more easily be made from. Because I think there's real value to the Stripes community in being that kind of core piece of infrastructure that larger frameworks like Loom could rise up and build upon. As Stripes would have improved, so would Loom, much like Seam gets "better" with JPA 2, without losing what Seam is. We've done it ourselves at our company, a full stack framework with Stripes as a core piece, and it's a wonderful place for it. Because we all know that a major problem in general with full stack frameworks is that they work great as long as your application is "philosophically" aligned with the framework, but once you leave the reservation, the frameworks can be more difficult to work with. The more rigid the framework (or I should say, the more rigid the presentation of the framework) to the end developer, typically the easier the framework is use, since much of that rigidity comes from internal coded assumptions. It's always a balance. But if you can rather than use an off the shelf framework, but perhaps "knit together" your own from larger pieces (a little Spring here, some Stripes there, a taste of Hibernate or iBatis, or whatever) then you pretty much get the benefits of a high level, "rigid" framework while at the same time maintaining some flexibility since you're the one who pieced it together, you have better understanding of the tradeoffs involved and what needs to be done when your early decisions prove insufficient. And I think it would have been nice for something like Loom to have been a package and consolidation of more "off the shelf" bits that folks could use as an out of the box tool, or as a loosely integrated bit of kit upon which to build something even more useful and sophisticated internally.
After a couple of months without response to this or other issues (such as the proposal to calculate automatically the maxlength attributes) we decided to switch to a different provider. Since there was nothing better at the time, we decided to roll our own solution.
We considered forking at the time, but it was not really worth it and I didn't want to harm the Stripes community.
I think it's a shame that there is a bit of "core" code that's "not quite, but almost like Stripes" (I don't know how close in the end it really was).We kept the common "Action-Event" naming and some of the annotation ideas, but the rest was all started from scratch. We already had some experience with the guts of stripes, struts, spring MVC and JSF, so we decided to start something that could better suit our own needs, taking the best from each of them. We imitated some interfaces, but with our own implementations. By the way we are talking about exactly the same thing that has been criticized about stripes from the struts community.
Ignacio, since Loom uses JSP could you look at Jolene http://jolene.sourceforge.net and let me know (via email if you like) how to implement a plugin for it. TIA
one more web framework !!! why ?
Yet Another Framework :) Seems nice to me, demo looks good, but it is nothing more that a easy to build crud application. It would be nice to see some more sophisticated examples. Main example for me is Authentication and Authorization. Show me how you intend to support this in Loom. If this is not included into the framework then it is of no use for application developers. After all we need to know who accesses our applications and we use it to restrict access to pats of our application. Kind regards, Marc
Loom is developed by ISI. The scruffy version of Classic. I always think that it is important to try to develop largely unique, and Googlable names. Anthony
Sorry about that. We did our homework, and the only hit we got for "loom java" was a framework developed by codehaus that seems to have no activity since 2005. I am of the same opinion, even if the java landscape is full of exceptions to the rule (spring, struts, seam...) Having said that, the truth is that we dedicated very little time to find a name :)