Home

News: Trails video: 11 minute walk through

  1. Trails video: 11 minute walk through (22 messages)

    I've seen a lot of posts by people suggesting somone should take up the challenge of making a Railsesque video of how fast app development in Java can really be done. I decided to give it a try. Here's me recreating the Recipe example application from a recent onLamp.com article in Trails in 10:53.

    I have 2 versions: with narration and without. Here is the blog entry.

    Threaded Messages (22)

  2. OUTSTANDING Film![ Go to top ]

    Worth an Oscar!!!!!!!!!!!!!!!!!!
    Impresive.
    I tell my developers 3 screens per day or you go home late. (not realy but a guideline)
    I think I need to up it.
    Take that Rails!

    Another speed tip: I have Tomcat point to my development WEB-INF and you can just do re-load via it's manager application, or a simple url command, takes a second.

    And don't flame me... but I stoped using beans for Domain. After ActionScript, P-langs, Groovy, etc.... I used Maps ("associative arrays"). On long/large projects, get/sets get stale over time. Loosley typed I think is the future. (Don't flame me here, I used to use beans for years and know the benefits of strongly typed)

    ( ... I tell Eclipse not to show jars by clicking filters: *.jar, it looks nicer)

    I plan to do a video for JDNC/WebStart at JL... soon I hope.

    .V

    ( I had these 30 short videos done for Struts
    http://wiki.apache.org/struts/StrutsTutorials )
  3. OO is the way to go[ Go to top ]

    I've actually seen what happens when you have a huge application that takes the approach of using Maps. It's an anti-pattern I term Map Oriented Programming. In real life, I find that having real domain objects makes development easier as the project grows. What I mean by this is if I have a good domain model, changes later in the project are actually easier to do. With MOP exactly the opposite was true, small changes became incredibly difficult and the project pretty much collapsed under it's own weight. The goal of Trails is to make Domain Driven Development, ie, having a real OO domain model, the easiest way to develop an application.

    --Chris
  4. Re: OO is the way to go[ Go to top ]

    The real crime is simply that "it shouldn't matter".

    Ideally, you should be able to do:

    bean.property = "New value";

    at that point, you don't know whether bean is a real actual Java bean, or a map.

    That way you can use the fast and loose map model early in development, then later start changing over to more strict beans, without having to recode your application.

    i.e. these should both "work".

    Map myMap = new Map();
    Bean myBean = new Bean();

    myMap.prop1 = "New Property";
    myMap.prop2 = 10;

    myBean.prop1 = myMap.prop1;

    etc.

    Later you can change to:
    MyNewBean myMap = new MyNewBean();

    and the compiler will start spitting out errors.

    But we can't do that at all in Java.

    Well, not totally true.

    We can create a "smart bean" that supports a Map interface that reflectively works on its member variables, but we lose typing information on get("..") methods.

    But that can give you the best of both worlds, to a point.
  5. Re: OO is the way to go[ Go to top ]

    The real crime is simply that "it shouldn't matter".Ideally, you should be able to do:bean.property = "New value";at that point, you don't know whether bean is a real actual Java bean, or a map.

    That's where using scripting languages, or OGNL (http://www.ognl.org) is very handy ... they let you manipulate Java objects without respect to type, and often have built in mechanisms to smooth out the differences between a Map and bean.
  6. Re: OO is the way to go[ Go to top ]

    Well, the advantage of maps seems that they're easily extensible, whilst with beans you hard code the fields, but get in return code completion, strict typing, and the ability to add logic (ok, you could subclass the Map and add methods to it too, but...).

    You can have both: use the bean as the base class, but attach to it a map for "extended properties" that you may need to add to support a customization request. It seems this way you can have the best of both worlds.
  7. Re: OO is the way to go[ Go to top ]

    Well, the advantage of maps seems that they're easily extensible, whilst with beans you hard code the fields, but get in return code completion, strict typing, and the ability to add logic (ok, you could subclass the Map and add methods to it too, but...).You can have both: use the bean as the base class, but attach to it a map for "extended properties" that you may need to add to support a customization request. It seems this way you can have the best of both worlds.

    The kind of extensibility is, a lot of times, very arguable and can be substituted with more managable OO approaches - like well-designing your architecture and using Interfaces smartly.

    Yet, yes - there are groups of problems where OO comes short, but the answer is not using Maps and going away from typesafe structures, but - Aspect Oriented Programming (AOP). It can solve a lot of your concerns, very elegantly, not destroying the managebility of your code, too.
  8. Nooooo![ Go to top ]

    And don't flame me...

    Bah! ;)
    but I stoped using beans for Domain. After ActionScript, P-langs, Groovy, etc.... I used Maps ("associative arrays"). On long/large projects, get/sets get stale over time. Loosley typed I think is the future.

    I still bear the scars from a project which used hashmaps instead of beans. (Previous team - we ended up ditching most of the code as it was unmaintainable. You were always afraid to remove anything as it was not readily apparent who used the values.)

    Use beans; buy IDEA; then refactor like a madman. ;) Let the your IDE/compiler do the heavy lifting for you.

    Cya,
    Andrew.
  9. Nooooo![ Go to top ]

    You were always afraid to remove anything as it was not readily apparent who used the values.

    Please, excuse the straightforward comment, but this, apparently, must have been due to the fact that your code was not covered enough with the unit-tests. There is no refactoring without unit-tests and there is no quality code without constant refactoring, whether you use Beans, Maps, typesafe, non-typesafe coding or even PHP embedded into your Java code, for that matter :)
  10. What color was the cool aide?[ Go to top ]

    There is no refactoring without unit-tests and there
    > is no quality code without constant refactoring

    You drank quite a bit.
  11. Nooooo![ Go to top ]

    You were always afraid to remove anything as it was not readily apparent who used the values.
    Please, excuse the straightforward comment, but this, apparently, must have been due to the fact that your code was not covered enough with the unit-tests. There is no refactoring without unit-tests and there is no quality code without constant refactoring, whether you use Beans, Maps, typesafe, non-typesafe coding or even PHP embedded into your Java code, for that matter :)

    The first unit test is: does my code compile? Strong typing provides that test.
  12. I think this is great stuff; I really look forward to a time when I'm not doing the most interesting development with (or even of) Tapestry, and Trails looks to be a major step in that direction.
  13. Trails video: 11 minute walk through[ Go to top ]

    Howard, is Tapestry as easy as it looks in the demo? Web dev is such a pain. I've been giving JSF a whirl, it is pretty good but ... .
  14. Trails video: 11 minute walk through[ Go to top ]

    Howard, is Tapestry as easy as it looks in the demo? Web dev is such a pain. I've been giving JSF a whirl, it is pretty good but ... .

    Yes, that's the whole point of Tapestry. It is very, very easy.

    Further, Tapestry has built into it the structures (in this case, libraries of pages and components) to allow this kind of vertical framework to be built.

    As I've said ... I'm looking forward to the time when other people are doing the most interesting work in Tapestry.
  15. Hi I installed RAD6.0 in my system but i want to upgrade the Eclipse version from 3.0 to 3.2 in RAD6. Can anyone tell me whether its possible to upgrade in RAD6? will RAD6 support Eclipse 3.2 version? Please reply at high priority Thanks in advance. sss
  16. XDoclet tags[ Go to top ]

    If you change the default eclipse getter comment to generate the @hibernate.property as part of the default comment that can also help speedup the process. You can then add the hibernate.class tags when you need the class to be persisted. Just to buy another few seconds ;).
  17. XDoclet tags[ Go to top ]

    I did think about this, but Eclipse would then add the hibernate.property for every getter I made, which seems a little icky. I really probably need a Trails Eclipse plugin to give you a little add Trails property panel that will stick in the appropriate xdoclet comments for Hibernate and BeanInfo stuff.
  18. Re: XDoclet tags[ Go to top ]

    Chris, you could call your Eclipse plugin HappyTrails! :-)
  19. Re: XDoclet tags[ Go to top ]

    Great idea, Jim. And actually my next video will be a sing-along :)
  20. This is a very nice video and we should be thankfull to the author for its creation.

    That said, I think it may be presented wrongly. For me - it shows very well (and proves, yet again) that modern Java technologies can be used for fast prototyping. It shows that those who claim Java is heavy and only for huge teams or those with years of experience, or costs too much - are just bad-mouthing a wonderful technology.

    But the code produced during the fast prototyping (though useful in itself) is not necessarily the best code to maintain. In my limited experience - the most important and costy is the maintenance, indeed (that - if your prototype flies and you get funding for the actual thing, heh). So, the "trail" of J2EE application creation does not, necessarily, lead to the best solution. This may or may not be the key thing, depending on a project, but is useful to keep in mind!

    For example, binding your Java beans to Hibernate using XDoclets, does save you time, but I know a lot of people who still prefer to hand-write their hbm.xml files and it is not because they do not understand the handyness of XDoclet-created mappings during the prototyping. The reason is - it does not, necessarily, lead to the best maintenance experience on the long run.

    Whether this particular example of Hibernate mappings is the best one or not (and I am sure it is not) the same comment is true for any automatically-generated code (and, alas, those are the ones that speed-up the development, eh?). The thing is - everybody likes stuff being done for him (her) but 90% of the time - you need to customize what has been done automatically for you, and if the next run of the automatic code-generation tool destroyes your customizations - you better not use that tool, at all!

    IMHO, this is why a lot of people do not use WYSIWYG GUI-designer tools of their IDEs and why and why hand-coders have remained a highly-appreciated cast all along.

    Once again - the importance of this may be different from project to project, but the understanding of what we secrifice, using tools that "speed up development", is essential and may not be neglected.
  21. But the code produced during the fast prototyping (though useful in itself) is not necessarily the best code to maintain.
    I wonder if you have looked at the code. I think you're missing the point of "Rails On Ruby" which was the inspiration for the "Trails On Java". Rails gives you reasonable defaults, but you can easily overrule/customize whatever you like in a maintainable manner. It is not meant to be a throw away prototype.
    For example, binding your Java beans to Hibernate using XDoclets, does save you time, but I know a lot of people who still prefer to hand-write their hbm.xml files and it is not because they do not understand the handyness of XDoclet-created mappings during the prototyping.
    It's a matter of taste. I find it easier to maintain if the mapping is described in the Java class. Doing so I only have to look at one place to get the picture. BTW It is also the direction chosen by the EJB 3.0 SG ;-).
    the same comment is true for any automatically-generated code (and, alas, those are the ones that speed-up the development, eh?).
    Haha, you did not take a look at the code. Trails is not about code generation.
    Quote from the Trails site:
    "The main, big,important difference between Trails and something like MDA is that MDA and it‘s ilk seem to be mostly about code generation. The problem I always have with code generation is that it‘s still code. Code to maintain, change, and worst of all, worry about how not to step on when I regenerate. With Trails, there is no generated code. You only write code when you want to override what Trails gives you. And since there is no code generation going on, you never have to worry about your code getting stepped on."
    Using generic components on top of Tapestry/Spring/Hibernate is in my opinion better maintainable than a lot of manually created boiler plate code.
  22. The thing is - everybody likes stuff being done for him (her) but 90% of the time - you need to customize what has been done automatically for you, and if the next run of the automatic code-generation tool destroyes your customizations - you better not use that tool, at all!IMHO, this is why a lot of people do not use WYSIWYG GUI-designer tools of their IDEs and why and why hand-coders have remained a highly-appreciated cast all along.
    From a historical perspective, a fair point, but don't cast all modern GUI design tools in this light. Enlightened IDEs will put the effort into GUI tools that don't stomp on your customizations and give you the capability to edit visually and / or in source, as and when you choose. This is an approach that Oracle JDeveloper takes, and OK it may not be perfect but it certainly points the way to how WYSIWYG Design tools should work with the developer's "Style du Jour" rather than trying to impose a way of working.
  23. RAD is not new[ Go to top ]

    RAD tools is not a new thing. Tools like this (Oracle Designer, etc) has been on the market for decades. It is the OO community that by some reason has refused to use such tools. Now, when almost everyone has forgotten how easy it could be to develop database applications in the pre-OO era, this appears to be a new innovation.

    If you want to see a more powerful and easier tool, have a look at http://butler.sourceforge.net.

    /Fredrik