On 12/28/06, Matt L. <[EMAIL PROTECTED]> wrote:
I took a quick look at the Velosurf project, but I don't think it would meet my needs. I really want to avoid having any SQL in a template. The template author should only be able to call methods on abstracted objects, IMHO. I am definitely going to use a database layer such as Hibernate.
fair enough.
My discomfort with the two servlet solution is that I was always told that there should be only one universal servlet. It seems more elegant to have every destination in the site be a vm file. Maybe I am being too idealistic and not pragmatic enough.
i don't know who told you that, neither can i imagine why they would say that. heck, the so-called "standard" is jsp, in which every jsp file is compiled to be a separate servlet automatically. what ideal is being upheld by using just one servlet? having multiple servlets supports the "separation of concerns" ideal (which is a sub-ideal of KISS). :) that said, i do agree that it is elegant to have every destination be a vm file. however, i don't think every stop along the way needs to be a vm file. the "action" servlet can update the model and then forward or redirect back to a vm file that the VVS would handle.
Is it fair to say that you never envisioned VVS to handle form submission?
i wouldn't say it like that. i'd say i envision it as a "view" layer servlet that was not designed with model/controller usage in mind. i can't say i've never thought of using it as anything else though, nor would i draw a 1-to-1 mapping between form submissions and updating the model.
You always assumed there'd be a seperate servlet?
yeah. historically, VelocityTools was originally driven by the desire for VelocityStruts integration where Struts was responsible for being the controller. i've long since stopped using VelocityStruts myself, though.
Thanks, Matt Nathan Bubna wrote: > > If you are going to use the 2nd way, i would recommend checking out > the Velosurf project. > > That said, i honestly don't see anything kludgy about have a second > servlet to handle form submissions. Updating the database and reading > from it are two totally separate functions. Task division is > perfectly normal and sensible. > > On 12/27/06, Matt L. <[EMAIL PROTECTED]> wrote: >> >> I am using the VelocityViewServlet (VVS) and I would like to handle html >> form >> submission that will be writing to a database. What is the best >> practice/industry standard way of doing this? >> >> Just off the top of my head I can think of two ways. One would be to use >> an >> entirely different servlet to handle the form submissions. It's certainly >> more appealing to have everything going through the VVS - two servlets >> seems >> pretty kludgy to me.. >> >> I could also have a destination template read the parameters and, via a >> tool, write to the database. My concern there is that the Velocity >> template >> language may not be rich enough to pull off that level of functionality. >> I >> also wonder about performance. >> >> I'm sure there is something obvious that hasn't occurred to me. I looked >> in >> the documentation and searched online, but I didn't find anything to >> address >> this. Regardless, I apologize for asking such a basic question. >> >> Thanks, >> >> Matt >> -- >> View this message in context: >> http://www.nabble.com/VVS-Form-Submission---Best-Practices-tf2888050.html#a8068626 >> Sent from the Velocity - User mailing list archive at Nabble.com. >> >> >> --------------------------------------------------------------------- >> 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] > > > -- View this message in context: http://www.nabble.com/VVS-Form-Submission---Best-Practices-tf2888050.html#a8080409 Sent from the Velocity - User mailing list archive at Nabble.com. --------------------------------------------------------------------- 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]
