• 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
  • Ron McLeod
  • Paul Clapham
  • Devaka Cooray
  • Tim Cooke
Sheriffs:
  • Rob Spoor
  • Liutauras Vilda
  • paul wheaton
Saloon Keepers:
  • Tim Holloway
  • Tim Moores
  • Mikalai Zaikin
  • Carey Brown
  • Piet Souris
Bartenders:
  • Stephan van Hulst

Pattern Doubt.

 
Ranch Hand
Posts: 340
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
While giving a mock exam, i found this question:

While reviewing a webapplication a developer discovers that a majority of the JSP pages contain same helper tag code to perform access control.
Which two patterns, taken independently, can be used to refactor the JSP code so that these duplicate tags can be eliminated?

a Front Controller
b Service Locator
c Transfer Object
d Business Delegate
e Intercepting Filter

I answered a and d , but correct answeres are a and e.

Kindly anyone please clarify.

Thanks
 
pie sneak
Posts: 4727
Mac VI Editor Ruby
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Yuck. That's a horrible question. I don't know what in world it's meaning by duplicate tags. Tags are meant to avoid duplication. Not only that, but if access control is field-based, then tags are your best option. If instead access control is page-based then, yes, handling it in a Filter OR Front Controller is more logical because you'd want to prevent the client from entering a view (page) that they aren't allowed to access.

The principle is much like telling your child "No" before she touches the hot stove. You want to do so as soon as possible before she gets too close. Filter and Front Controller are the first two things that interact with a request, so one of them should be responsible and say "No-no-no!"
 
Author
Posts: 836
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I agree with Marc - this is yet another one of those cases where a patterns question is ambiguous... The phrase "access control" means very little on its own; for example, should it throw an exception if the user isn't authorised, or maybe return a 401 status code, or possibly just block out material... If it was the status code option, I'd be highly dubious about putting that in a tag anyway - as it would probably be ignored as a result of the output being committed prior to the tag's invocation. If it was the exception, that's dangerous territory (throwing and then not catching exceptions is not a good idea unless you want to see ugly error messages)... and if it's just blocking out certain material from site, then in fact a custom tag would be a perfect way to do that.

Now the best sorts of components for general authentication and authorisation are indeed filters and front controllers (separately, possibly with a preference for filters).

My general advice when stuck is that the best way to approach these questions is by elimination: it can't be B or C as these make no sense (except C could be a contributing factor if you were obtaining a vast amount of user profile data or credentials from an EJB in order to do the authorisation!). It's also unlikely to be D as a Delegate is used as a course-grained front-end for an EJB application; there is no reason to suspect that our Web application is interfacing with an EJB in any way (if it were, B would also be advisable)... So by elimination we've arrived at A and E.
 
Sandeep Chhabra
Ranch Hand
Posts: 340
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator


Well...After reading the comments of you both...I better change my question. :roll:

WILL I GET SUCH TYPES OF VAGUE QUESTIONS IN REAL EXAM ???
 
Charles Lyons
Author
Posts: 836
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

WILL I GET SUCH TYPES OF VAGUE QUESTIONS IN REAL EXAM ???

Please don't shout (i.e. use all uppercase). I'm pretty immune to its effects, but some find it rude.

From experience, I would say the only area on the exam where the questions are vague is with patterns. Unfortunately they aren't always the best worded questions, which is more of a reflection that they are essentially not programming questions, but more architectural questions. I mean, you could probably write essays on different patterns!

Sometimes you'll have to assume things for other questions - for example, you might need to assume that given a snippet of servlet code, that any 'request' and 'response' variables shown correspond to (Http)ServletRequest and (Http)ServletResponse respectively. Some small things like this are occasionally inferred, but it should be quite obvious from the context.
 
Sandeep Chhabra
Ranch Hand
Posts: 340
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator


WILL I GET SUCH TYPES OF VAGUE QUESTIONS IN REAL EXAM ???


Oops !!! Sorry for it.... But intentions were not rude...

I just got upset of such types of questions. I have got them a couple of times now in many mocks...and now I just feel I am not well prepared for the exam.

anyways thanks for your response.
 
Too many men are afraid of being fools - Henry Ford. Foolish tiny ad:
Gift giving made easy with the permaculture playing cards
https://coderanch.com/t/777758/Gift-giving-easy-permaculture-playing
reply
    Bookmark Topic Watch Topic
  • New Topic