Discussions

News: Loom 1.0 final released

  1. Loom 1.0 final released (13 messages)

    With 700+ java classes, 400+ tests, 35 javascript test pages and a hell of a week polishing rough edges, Loom 1.0 is out the door. Getting together a selection of the best unique features included in this release is no easy task, but here it goes: * Scaffolding: the project includes a scaffolding tool to start a web project in 10 minutes. * This release can concatenate, minify and gzip javascript and CSS resources without involving any build scripts. Images referenced from CSS files are supported, even from the classpath. * Support of JAX-RS mapping annotations: @Path, @GET, @POST, @DELETE, @PUT * JavaRebel support: modify your action class, go to the browser, refresh. Repeat. * Includes an almost transparent pagination component * Automatic validation of your JPA constraints using javascript and server-side code. We are really excited with this release. Feel free to poke at the demo application or take a look at the documentation (easy - the docs are still a work in progress). Any comments would be really welcome!

    Threaded Messages (13)

  2. smells like[ Go to top ]

    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..
  3. Re: smells like[ Go to top ]

    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.
  4. Re: smells like[ Go to top ]

    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.
  5. re: In defense of Loom[ Go to top ]

    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)
  6. It all started as a stripes patch[ Go to top ]

    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.
  7. 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.
    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.
  8. 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.
    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)
    This is the main complaint of the .NET community about java: that there are no reasonable defaults put together. The setup of a scaffolding application can be dismantled into pieces: you are by no way forced to use JPA, in fact one of our deployed applications interact with a Reuters service and has no database or form validations. You can also remove all the provided javascript (the demo can be used with javascript turned off and you will not notice the difference) or replace it with your own. Loom does not generate a single line of javascript, what you see in the demo was put by the application developer. The idea was to build a reasonable platform to build components upon. Anyways, I liked the idea of further componentization in the stripes way (we are not there yet), we will probably add some effort in that direction for the next release. Thanks!
  9. Loom and Jolene[ Go to top ]

    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
  10. Re: Loom 1.0 final released[ Go to top ]

    one more web framework !!! why ?
  11. Re: Loom 1.0 final released[ Go to top ]

    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
  12. Security way[ Go to top ]

    Main example for me is Authentication and Authorization. Show me how you intend to support this in Loom.
    Fair enough :) You can use spring-security and JSR-250 annotations out-of-the-box: @RolesAllowed({ "admin", "helpdesk"}) public class MailAdminAction extends AbstractActionImpl { @RolesAllowed({"admin"}) public Resolution create() { // ...event method code... } } The cool part is that links pointing to an unauthorized action/event pair automatically get the "unauthorized" css class added, so with a bit of javascript and CSS you can choose to display a "not enough permissions" warning or just remove the links altogether, depending on your personal taste. If you are interested in more advanced examples, you should give a look at the @Cache example here: http://loom.extrema-sistemas.org/doc/1.x/ref/method-annotations
  13. 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
  14. 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 :)