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]
