Front Page | Recent Comments | Sample Apps | Archives | Weblog | Login
Book | JIRA | Confluence | Forum

Last 20 Comments

Commenting on The word is out?:

Hi, I'm definately interested in your coming book. And I do hope you will be able to add in advance stuff as planned. Good luck.

Posted by hamdi on February 23, 2004 at 08:29 PM EST

Commenting on Integrating Spring with WebWork2:

I believe that the message and issue you refer to only detail not-yet released functionality (i.e. xwork v1.1). My "intimidating" :) article details how to do it in currently available versions. In either case, it's good to see this is an issue that is being actively pursued.

Posted by Ryan Daigle on March 09, 2004 at 11:09 AM EST
Website: http://www.ryandaigle.com

Commenting on Integrating Spring with WebWork2:

Thanks for the clarification Ryan. I'll most likely be integrating the two in the next month, so I'll keep your article handy.

Posted by Matt Raible on March 09, 2004 at 07:36 PM EST
Website: http://raibledesigns.com

Commenting on [BeanValidatorBuilder] Allows Validation via Spring's IoC, Groovy/Beanshell or Java:

Hey Matt I had it pointed out to me I made a few typos in the example bean declaration (note the accidental closing tag on the open bean declaration.:-) oops, that's the last time I try to type a sample in on the fly from memory (don't know what's worse I did that or that I actually *know* spring xml's format well enough to try :-)) keith

Posted by kdonald on March 11, 2004 at 08:22 PM EST

Commenting on [BeanValidatorBuilder] Allows Validation via Spring's IoC, Groovy/Beanshell or Java:

Thanks for the heads up - fixed now.

Posted by Matt Raible on March 11, 2004 at 09:04 PM EST

Commenting on [BeanValidatorBuilder] Allows Validation via Spring's IoC, Groovy/Beanshell or Java:

Matt, fyi - I just sent a updated copy of sample bean declarations for the declarative validation stuff to the spring-dev list. It's straight from the unit tests.

Posted by kdonald on March 14, 2004 at 10:06 PM EST

Commenting on [BeanValidatorBuilder] Allows Validation via Spring's IoC, Groovy/Beanshell or Java:

Hey Matt, One question: is the big need for commons-validator support for the client side javascript validation? Any other features? I know our base framework will be used to power rich-client field validation, and I'd sure like to see it power client-side webapps, too... (and with features like typing hints and decorating certain fields with specific contraints (like required) in a different color, I think we could really offer some innovating things here.)

Posted by kdonald on March 14, 2004 at 10:11 PM EST

Commenting on [BeanValidatorBuilder] Allows Validation via Spring's IoC, Groovy/Beanshell or Java:

Keith - the main advantages to using commons-validator (as I see them) are (1) good JavaScript validation and (2) XDoclet generation of the validation.xml file. It's also nice that there's a large community (Struts) using it - so it's constantly being tested, maintained and added too. I'm sure you can come up with or make something better - but why not enhance the wheel, rather than re-invent it? Personally, I'd love to see a validation framework that can be used across MVC frameworks - i.e. Struts, WebWork, Tapestry, etc. I don't know if it's possible - but I can dream, can't I? ;-)

Posted by Matt Raible on March 16, 2004 at 11:37 AM EST

Commenting on [BeanValidatorBuilder] Allows Validation via Spring's IoC, Groovy/Beanshell or Java:

Matt, thanks for the info. Yea, I promise I'm trying not to reinvent the wheel. :-) But I hear you. I don't dislike commons-validator, but I do think the API could be simplified/cleaned up a bit and I'm not a fan of all the deprecated methods. But that's the design purist in me talking... :) I just couldn't get commons to fit with the rich client stuff. The main value I see in what we're doing is it integrates nicely w/ Spring (including the internationalization/messaging stuff) and the javabeans API and Swing support. I am hoping the design gets some good review so its made clear what's different and why. btw, the commons-attributes stuff is pretty slick, too, since you don't even need a validator.xml.

Posted by kdonald on March 16, 2004 at 10:04 PM EST

Commenting on [BeanValidatorBuilder] Allows Validation via Spring's IoC, Groovy/Beanshell or Java:

Now that I think about it, the commons-attribute stuff is probably just as good as the commons-validator stuff. I like the validator b/c I can write @struts.validator type="required" on my POJO and I'll get client and server-side validation for that property (using XDoclet to generate validation.xml). Arguably, the commons-attributes stuff makes this even simpler because you can write @@ValidationRule("required") and never even have to worry about XDoclet or the generated XML file. If this can produce client-side JavaScript validation too - I think this is definitely better than the POJO -> XDoclet -> validation.xml model.

Posted by Matt Raible on March 17, 2004 at 10:03 AM EST

Commenting on [BeanValidatorBuilder] Allows Validation via Spring's IoC, Groovy/Beanshell or Java:

Matt, I'll create an issue in Spring's JIRA to track client-side (javascript) validator generation using the declarative validation framework.  The declarative stuff is due to release w/ the first Spring 1.1 milestone release targeted the end of April - hopefully between now and then I can find someone to jumpstart the javascript stuff.

Posted by kdonald on March 19, 2004 at 04:51 PM EST

Commenting on Tiles and easy switching of layout templates:

Don't you mean just "display tag only works with JSPs"? I thought StrutsMenu could use Velocity.

Posted by Lance on March 23, 2004 at 09:15 PM EST

Commenting on Tiles and easy switching of layout templates:

Struts Menu uses Velocity to render the HTML for the menu - however, it still uses JSP tags to invoke the Velocity Displayer. I'm sure there's a way to re-write the 2 Struts Menu tags to work with Velocity, and only Velocity. I'd be awesome to get the display tag and struts menu working with Velocity - and eliminate JSPs altogether - just to prove its possible.

Posted by Matt Raible on March 23, 2004 at 10:45 PM EST

Commenting on J2EE Made Easy:

That is OpenOffice exporting a PowerPoint presentation to html.

Posted by Thomas Risberg on March 24, 2004 at 10:51 AM EST
Website: http://www.jroller.com/page/buggybean

Commenting on Tiles and easy switching of layout templates:

Okay, I understand the distinction.

Posted by Lance on March 24, 2004 at 12:02 PM EST

Commenting on XDoclet for Spring:

Breaking the XML file into tier-specific pieces is a good move. But, it still doesn't help achieve DRY programming. Furthermore, instead of one monolithic XML file, you now have several XML files to manage. I guess my point here is that it's the same amount of stuff to manage...just broken into bite-size pieces (which, BTW, are still separate from the real bean code). Using XDoclet, we've been able to program DRY and close to the problem domain (eg, the bean) and still achieve the same level of reuse/testability afforded by writing the XML files by hand. Now...I'm not saying that this XDoclet module is ideal for every Spring-ified project. Certainly there will be apps out there where XDoclet generation of the XML files will be silly. At the same time, it is wrong to state that XDoclet is of absolutely no use with Spring. Regarding Juergen's use of XDoclet with Commons Attributes...it is my understanding that they don't use XDoclet as much as they use XJavaDoc. In any event, I do acknowledge that Spring's use of metadata is pretty cool. But it is still a separate topic from generating the Spring XML file. Finally...I've recently taken a look at AppFuse. Very nicely done. I was thinking of doing a similar thing sometime ago, but my ideal mix would be Spring MVC in the presentation layer, Spring in the middle, and Hibernate as ORM. My idea of the "dream team" would be Spring and Hibernate in my app and XDoclet generating the Spring XML and Hibernate mapping files. AppFuse comes mighty darn close to what I had in mind.

Posted by Craig Walls on March 25, 2004 at 11:00 AM EST

Commenting on XDoclet for Spring:

Craig - I'm an XDoclet lover (as evidenced by AppFuse) and when I first started working with Spring, I longed for XDoclet to generate Spring's applicationContext.xml for me. Especially since I wouldn't need separate XML files if it was generated (or composed) based on the tier I was compiling/testing. Therefoer, I thank you for adding this support. I don't know if I'll use it, but it's great to know it's available. Let me know if it starts getting some traction and I might be able to squeeze it into the book. As for AppFuse and a Spring MVC layer - it's coming in the next couple weeks. I have most of it done - I just need to package it up and release the sucker. AppFuse will still use Struts out-of-the-box, but I'll make it easy to replace it with Spring.

Posted by Matt Raible on March 25, 2004 at 11:13 AM EST

Commenting on Yeah it's good...:

I'm not, actually. Not anytime soon. I kinda like spring, it certainly beats the stuffings out of amateurish toys like pico, so for now, it has no place on bileblog, sorry!

Posted by Hani Suleiman on March 25, 2004 at 04:30 PM EST

Commenting on J2EE Made Easy:

Matt, thanks for the ref. Looking forward to your April presentation - I intentionally didn't cover much in the way of the web-tier...we're all itchin' for a crash course on how to build webapps quick with AppFuse. :-)

Posted by kdonald on March 27, 2004 at 09:09 PM EST

Commenting on [Presentations] Intro to Spring and JDBC/DAO Support:

Matt: Do you have a copy of Eduardo's presentation. The link seems to be broken. Thx - Anand

Posted by anand sharma on March 31, 2004 at 12:54 AM EST


 
Weblog Archives
Click this photograph for National Geographic's Photo of the Day
Photo of the Day
XML
Spring Logo
+ SourceBeat Weblogs

+ Spring Framework

Spring Live Book
• Raible Designs
• Who is Matt Raible?
AppFuse