Pattern Doubt.
Sandeep Chhabra
Ranch Hand
Posts: 340
posted 11 years ago
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
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
Regards<br />Sandy<br />[SCJP 5.0 - 75%]<br />[SCWCD 1.4 - 85%]<br />------------------<br />Tiger, Tiger burning bright,<br />Like a geek who works all night,<br />What new-fangled bit or byte,<br />Could ease the hacker's weary plight?
posted 11 years ago
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!"
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!"
A good workman is known by his tools.
Charles Lyons
Author
Ranch Hand
Ranch Hand
Posts: 836
posted 11 years ago
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.
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
posted 11 years ago
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 ???
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 ???
Regards<br />Sandy<br />[SCJP 5.0 - 75%]<br />[SCWCD 1.4 - 85%]<br />------------------<br />Tiger, Tiger burning bright,<br />Like a geek who works all night,<br />What new-fangled bit or byte,<br />Could ease the hacker's weary plight?
Charles Lyons
Author
Ranch Hand
Ranch Hand
Posts: 836
posted 11 years ago
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.
Please don't shout (i.e. use all uppercase). I'm pretty immune to its effects, but some find it rude.WILL I GET SUCH TYPES OF VAGUE QUESTIONS IN REAL EXAM ???
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
posted 11 years ago
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.
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.
Regards<br />Sandy<br />[SCJP 5.0 - 75%]<br />[SCWCD 1.4 - 85%]<br />------------------<br />Tiger, Tiger burning bright,<br />Like a geek who works all night,<br />What new-fangled bit or byte,<br />Could ease the hacker's weary plight?
