• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

EL implicit objects - MVC ?

 
Ranch Hand
Posts: 74
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Guys,
The following EL implicit objects:
  • param
  • paramValues
  • cookie
  • header
  • headerValues

  • Is it a good practise to use any of the above?
    [ September 01, 2007: Message edited by: Muni K Reddy ]
     
    Sheriff
    Posts: 13411
    Firefox Browser VI Editor Redhat
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    As with any tools, I would say it's got more to do with how you use them then whether or not you use them.

    Personally, I like to have all of my business logic and non-view decisions figured out before I forward to the JSP and then use JSTL and EL for help building up the markup only.

    With that line of thinking, I can't picture myself using, cookie, header or headerValues in a JSP. A case may come up but, usually, if I'm reading headers, it's because I want to branch on them and make the app behave differently according to their values or because I'm logging something like a referrer header. Neither of these things are things I would typically do in the view.

    For a small app, I might use the param object for re-populating a form that has failed validation but, in most cases, by the time validation fails, I've already used those parameters to populate a bean and it's easier (or clearer) to use the bean's properties to repopulate the form.

    Your mileage may vary.
     
    Muni K Reddy
    Ranch Hand
    Posts: 74
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    Thanks Ben!
     
    Ranch Hand
    Posts: 114
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    I agree with Ben in that you are probably best dealing with business logic before you get as far as the template. I'd probably consider it a bit of a code smell if you feel the need to tinker with the response headers, cookies etc in a template. I'd be taking a step back and havig a coffee to think things over at that point ;)

    The only things I deal with in the view layer are model data which I'm rendering a view for, view helpers and very occassionally an arbirtrary request parameter.

    It makes sense for EL to make them available for ad-hoc times when you may find a need for them, but I wouldn't encourage putting that sort of logic in templates much.
     
    With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
    reply
      Bookmark Topic Watch Topic
    • New Topic