Sorry for asking, but i'm confuse.
hi i'm quite new with java. and just recently i learn about J2EE pattern.
but when i try to implement it to JSF. i got confuse. so my webpage have all coding put into 2 bean. one for access database. and one for other.
Can anybody please explain to me how to connect aFront Controller, View Helper, Data Acces Object, Intercepting Filter, and Business Object into a web database application using JSF?
And where should i put the session for authenticate the user? i'm now put it in "other bean".
thank's in advance.
[558 byte] By [
yantoa] at [2007-10-2 17:30:34]
> hi i'm quite new with java. and just recently i learn
> about J2EE pattern.
> but when i try to implement it to JSF. i got confuse.
> so my webpage have all coding put into 2 bean. one
> e for access database. and one for other.
>
Hmm... not that it would be 'wrong' to have a bean as your DAO, but it is non-standard. But take a step back. JSF has *nothing* to do with your database code or your business logic. None, nada, zip, zero.
So, rather than looking at the whole thing and saying, "OMG!" take each step apart. Is your database access code working? If yes, great! If no, fix it. Does your business logic (or application logic) work properly? If yes, great! If no, fix it.
Now, finally, you are ready to tackle the controller and view (JSF, see the MVC pattern if the above is unclear). Separate your view and controller concerns from your model.
> Can anybody please explain to me how to connect a
> Front Controller, View Helper, Data Acces Object,
> Intercepting Filter, and Business Object into a
> web database application using JSF?
>
Ahh... pattern fever. Well, first of all, don't try everything at once. Second of all, since your application apparently only has two classes, do you *need* all the above?
But don't despair, you have much of it done already. JSF itself is a FrontController, so you are done there. You have a 'data access' bean, so DAO is done as well. That leaves the following:
> ViewHelper - you can think of your form bean as a view helper if you like. This is not really, IMO, a pattern but just an example of delegation. One object is doing too much (whether view or controller or model), so you move some of that functionality into another, helper object.
* InterceptingFilter - see the Servlet spec. Any filter you write will in effect be an InterceptingFilter by definition. But, again, what are you using the filter for? Don't code things you don't need.
* BusinessObject - this is not a pattern, again IMO.
> And where should i put the session for authenticate
> the user? i'm now put it in "other bean".
>
Now you have an actual case where InterceptingFilter is used. Create a subclass of Filter. Define it in web.xml. Then code your authentication/session routines.
> thank's in advance.
You are welcome.
- Saish
Saisha at 2007-7-13 18:47:29 >
Thank you very much Saish.
now i get most of it done.
your are a very good teacher indeed.
but i got new problem here.
considering that i put my session atribute into a bean properties.
i.e. UserBean should i put the bean properties into a "Transfer Object" or put it with the session bean?
and if i should put the bean properties into Transfer Object, can i put it with other properties bean like cartBean, or itemBean so it would look like a Transfer Object Assembler ?
i think it's good to do that, so we have a bean that sum all the properties of our web, what do you suggest?
thank's again for your advice.
yantoa at 2007-7-13 18:47:29 >
