Along the lines of making it easier for new users, we need something like this:
http://www.springframework.org/docs/MVC-step-by-step/Spring-MVC-step-by-step.html If someone else wants to do it, great... If not, I'll eventually try to get to it. Jason > -----Original Message----- > From: Drew McAuliffe [mailto:[EMAIL PROTECTED] > Sent: Sunday, August 17, 2003 9:01 PM > To: [EMAIL PROTECTED] > Subject: RE: [OS-webwork] Simplicity of WW2 - Practical ideas > > > I would argue against anything that would increase the > possibility of subtle errors. If a solution like the one you > suggest could be done while "fireproofing" against problems > when classes change packages, then I wouldn't be so against > it. I just hate having to track down subtle bugs in a system > that were caused by attempts to make things easier (e.g., > most of Windows). > > As far as the searching algorithm you suggest, I'd have to > say that I don't have anything against its usefulness but I > would have an issue if it forced a lot of computation to > handle the searching. As it is now in WW2, I understand that > a lot of the getText() functionality is maybe a little slower > than it could be because it searches from the current class > on up through the package hierarchy (e.g., if no text > resource is found for "com.package.sub.MyClass", it searches > in "com.package.sub", then "com.package", etc.). I appreciate > these features on the one hand but since I find the > alternatives the avoid to be not that much more difficult, > I'd rather avoid the performance hit if possible. I know > we're talking ms here of difference but it adds up. WW1 was > pretty fast, especially with velocity, and I've seen > disappointing results with ww2 thus far. I would think it > would be best to concentrate on performance tuning at this > point, now that it's in Beta, and save convenience > enhancements for later. > > Of course, it's not up to me. Oh, and for the record, even > though I'm disagreeing with you on these points, I do agree > that efforts should be taken to make ww2 easy to adopt. It's > just that I'm interested in making sure that those efforts > don't interfere with how more advanced users do things, by > introducing the chance for subtle errors or hurting performance. > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On > Behalf Of boxed > Sent: Sunday, August 17, 2003 4:30 PM > To: [EMAIL PROTECTED] > Subject: Re: [OS-webwork] Simplicity of WW2 - Practical ideas > > > Mike Cannon-Brookes wrote: > > >You can already test actions to setup xwork.xml - just > instantiate the > >object, call your setter methods and run! > > > > > Are you trying to scare users away now? I was talking WW2, > not XW, so a > web-based interface where you can get immediate feedback in the > environment you're gonna use seems reasonable. Writing even > more code is > > hardly user friendly. > > >People doing J2EE understand XML, they have to. All descriptors are > >XML. Xwork.xml is not _that_ complex for a hello world > example, most of > > >the elements are optional. > > > > > I think you overestimate "people doing j2ee". Maybe you need > to come and > > spend a day or two in #java and listen to the questions > people who are > trying to understand WW (1 and 2) are asking. Many are new to java, > people just don't learn programming the logical way by > working upwards, > they start in the middle and work outwards. Sure, it's not "_that_" > complex for a hello world app. It is however an order of > magnitude more > complex than it was in WW1 and _already that level_ confused a lot of > newbies. If we want WW2 to be used and to be able to compete with > things like Struts, you can't have this kind of elitist thinking. > > If you have a competent person who knows XML and all that, > the odds are > he's already used to Struts and we do NOT want to make him give up on > his evaluation of WW2 because it's a big hassle. We want to give the > view (illusion if you will) that it's easier than Struts, and > not just a > > little easier, a _lot_ easier. No one will change if they don't see > their time invested will be worth it down the line. > > >However, there _is_ a problem with WW2 at the moment that if > a view is > >not found, no debug page is shown. I think it should be ("action > >returned "input" but not "input" view found). > > > > > So you agree with the full debug output? Fine, I still hold > to my view > that if we give the illusion of ease of use, people will > believe it is > easy to use. Call me crazy, but I think people believe what they see. > > I'd also like some arguments against my ideas other than "it's not so > complex" and "I don't think so". You began the email with "I have to > say that this is a _bad_ idea." and then proceeded to give zero > technical arguments against the idea. I am fully willing to throw my > idea in the garbage bin, given actual problems with it. You have not > shown any. > > Anders Hovmöller > > > > > > ------------------------------------------------------- > This SF.Net email sponsored by: Free pre-built ASP.NET sites > including Data Reports, E-commerce, Portals, and Forums are > available now. Download today and enter to win an XBOX or > Visual Studio .NET. > http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet _072303_01/01 _______________________________________________ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork ------------------------------------------------------- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01 _______________________________________________ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
