Brian, Thanks. I have around 50 Entities in my database, so I guess that I Am going to end up with 50 List .vm and .javas, and either 50/100/150 Edit and Display .vms and .javas. I'd rather not let them all be Called Default :)
Funny thing, when looking at the files I've produced, they are somewhat Formulaic; it should be possible to generate them all from the initial Torque, Schema.xml file, apart from the one-to-many and many-to-many Relationships of course; you would have to extend the schema dtd to Declare the relationships for those. There's a challenge for someone....... 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]
