I'll make a note of it :) Henning said he would work with me towards putting the book together. We have hurricane Isabel sweeping through my neighborhood today so I have some off time till Monday to do some writing.
turning my computers off for a few days... Jeffery On Thu, 18 Sep 2003, cctech wrote: > Thanks to Brian, Matt and Jeffery! > > You think that you know everything from reading the instructions, but > there's no substitute for experience when it comes to actually producing > something using Turbine. > > I have used the ideas and cut the number of files per database table > down to 5; > > EditTableEntry.java EditTableEntry.vm and UpdateTableEntry.java > Plus > ListTable.java and ListTable.vm > > Plus, I've learnt to use the addPathInfo to pass my mode parameters (and > getParameters in my java to put it back into the context). > > And, I've learnt to use #if ($mode == blah) liberally in my screen .vm > files to sort out what should be displayed and what shouldn't, and what > should be editable and what shouldn't. > > And I'm far happier for the experience... > > This stuff should be in the "turbine book" talked about on the list; > supplement the technical reference with real experience, "how-tos". > > Thanks to all for your help! > > Steve > > > -----Original Message----- > From: Brian Lawler [mailto:[EMAIL PROTECTED] > Sent: 17 September 2003 15:39 > To: Turbine Users List > Subject: Re: Velocity newbie question > > > Turbine's implementation of MVC pretty much implies a one-to-one > mapping between Screen templates and Screen classes, but there is one > wrinkle: Default.java > > The order of resolution for finding a screen class includes looking for > a Default.java file if there is not a correctly named class to service > the Screen request. Basically, the order for resolving a screen called > foo/bar/Baz.vm is to first look for the foo.bar.Baz class, then for > foo.bar.Default, then for foo.Default, then for Default. If you are > doing things on a very granular level (i.e. one subdir per data > element) then you could conceivably use the Default class as the single > point for your logic. > > Having said all that, it is probably a bad idea, as your system may > soon contain dozens of classes named Default. > > So my initial suggestion is still the one I would go with. Perhaps you > could put all of the code in ShowDetails and have EditDetails extend > ShowDetails. That gets you down to 2 and preserves reasonable naming > for your screen classes. > > -Brian > > On Wednesday, September 17, 2003, at 07:08 AM, cctech wrote: > > > Brian, > > > > Thank you. That would be the correct OO way of doing it (Why didn't I > > think of that?). Slight drawback is that I've got three files now > > (although one with actual code), > > And I was rather trying to get to one file. > > > > Thanks, > > > > Steve > > > > -----Original Message----- > > From: Brian Lawler [mailto:[EMAIL PROTECTED] > > Sent: 17 September 2003 13:54 > > To: Turbine Users List > > Subject: Re: Velocity newbie question > > > > > > Steve- > > > > You can make a base class for the 2 screens and have both of your > > actual screen classes extend it: > > > > BaseDetails - has all of your common code. > > > > ShowDetails extends BaseDetails > > EditDetails extends BaseDetails > > > > Just be sure to call super.doPerform() from you child classes. > > > > -Brian > > > > On Wednesday, September 17, 2003, at 04:43 AM, cctech wrote: > > > >> I'll fairly new to Turbine and Velocity, but nonetheless, I have gone > > >> Headlong into building a complex application with a large data model. > >> > >> I have been constructing screens using Velocity for both displaying > >> Table data and for editing it. Trouble is, I seem to create Action > >> Classes for both display and for edit that are both exactly the same. > >> > >> E.g. ShowDetails.java for ShowDetails.vm > >> And EditDetails.java for EditDetails.vm (then goes to > >> UpdateDetails.java) > >> > >> In this case the code for the two java classes (Show, Edit) is > >> exactly > > > >> the same except with different class names. > >> > >> Is there anyway of re-using the same class for different velocity > >> templates? Have I missed something simple? > >> > >> Thanks, > >> > >> Steve > >> > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: [EMAIL PROTECTED] > >> For additional commands, e-mail: [EMAIL PROTECTED] > >> > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > -- Jeff Painter ------------ [EMAIL PROTECTED] President Kiasoft, Inc. PO Box 4315 Cary, NC 27519-4315 http://kiasoft.com (919) 677-8525 --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
