You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by Jeff Emminger <je...@jeffemminger.com> on 2004/04/01 22:19:43 UTC
Re: separation of logic
ok, further along now but still having some problems...attempting to
decouple Hibernate code and login mechanics from my LoginPanel component
currently:
LoginPanel
extends BaseComponent
CLoginManager
extends ILoginManager
i guess the confusion i'm having stems from the fact that LoginPanel
needs to extend BaseComponent to be Tapestry-aware, and also needs to
extend CLoginManager to access the actual login mechanics
so do i need to build another intermediate class to combine
BaseComponent with CLoginManager, and let LoginPanel extend this instead??
should i forget about all this decoupling nonsense at my newbie stage,
build the app however i can, then worry about learning this stuff later?
thanks for your help!
jeff
Kertis, Dennis wrote:
> The login interface will not have any logic, just the list of services
> between the clients and your implementation.
>
> Yes. You would create a concrete class that implements the login interface
> and provides all the business logic. This class (your login component) will
> extend the class that implements ILoginManager.
>
> One thing to watch for when decoupling your logic is that your login classes
> do not import any tapestry classes. If they do, you are coupling yourself
> with tapestry. The classes that implement your UI (tapestry classes) should
> only use the interfaces (ILoginManager) you create and your interfaces and
> implementations should avoid using any tapestry stuff. You may need to
> create an intermediary to tie the two together.
>
> This is what they call an MVC Model-View-Controller architecture. Your
> tapestry components are the view. Your LoginManager is the Model (soft of)
> and the class you use to tie the two together is the controller.
>
> -Dennis
>
> -----Original Message-----
> From: Jeff Emminger [mailto:jeff@jeffemminger.com]
> Sent: Monday, March 29, 2004 10:59 AM
> To: tapestry-user@jakarta.apache.org
> Subject: Re: separation of logic
>
> i'm trying to implement this now, but i have some confusion (my
> apologies - i'm a java newbie):
>
> if ILoginManager is an interface, then it will not actually contain the
> logic in its method login(), right? ...which means i need to create a
> class that implements it - would this be my login component? or would
> my login component extend the class that implements ILoginManager?
>
> are there any examples of such decoupling of logic that i can study?
>
> thanks again,
> jeff
>
>
> tsvetelin wrote:
>
>>Hi Jeff,
>>
>>You could define a interface called ILoginManager that will be responsible
>>for authentication the user.
>>public interface ILoginManager{
>> public CLoginInfo login(CLoginData loginData)throws ELoginFailed;
>>}
>>
>>The interface could have a method called login that will contains the
>
> logic
>
>>for authentication. I will required the login data(user name, password
>>etc...). If the login is successful the method will return the login
>
> info(in
>
>>this case CLoginData or CUser object). If there are some problems the
>
> method
>
>>will throw the exception.
>>
>>You login component after submitting the login form will invoke the login
>>method from ILoginManaged and will store the login info (in Visit object
>
> for
>
>>example) if the user is authenticated successfully or will show error if
>>there is a problem.
>>
>>Using this approach you achieve the following benefits:
>> 1. The presentation and logic are clearly decouple
>> 2. You will be able to change the implementation of the authentication
>>login during the time without changing the component.
>>
>>
>>Tsvetelin
>>
>>-----Original Message-----
>>From: news [mailto:news@sea.gmane.org]On Behalf Of Jeff Emminger
>>Sent: Wednesday, March 24, 2004 8:27 PM
>>To: tapestry-user@jakarta.apache.org
>>Subject: separation of logic
>>
>>
>> hi all,
>>
>>i have a bit of an architectural best practices question:
>>
>>for my "login" component, is it better to have the component
>>(login.java) contain the logic that passes/fails a login attempt, or
>>should i move this logic to my Visit object if i'm going to store the
>>login state there anyway?
>>
>>my feeling is the latter, since the tapestry component acts more as just
>>the controller.
>>
>>any opinions?
>>thanks,
>>jeff
>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
>>For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
>>For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>>
>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: separation of logic
Posted by Dylan Spence <dy...@comcast.net>.
Maybe you could also have the CLoginManager contained within the LoginPanel?
This might lead to the separation you were after.
----- Original Message -----
From: "Petter Måhlén" <pe...@elevance.se>
To: "'Tapestry users'" <ta...@jakarta.apache.org>
Sent: Thursday, April 01, 2004 3:35 PM
Subject: RE: separation of logic
> ok, further along now but still having some problems...attempting to
> decouple Hibernate code and login mechanics from my
> LoginPanel component
>
> currently:
>
> LoginPanel
> extends BaseComponent
>
> CLoginManager
> extends ILoginManager
>
> i guess the confusion i'm having stems from the fact that LoginPanel
> needs to extend BaseComponent to be Tapestry-aware, and also needs to
> extend CLoginManager to access the actual login mechanics
>
> so do i need to build another intermediate class to combine
> BaseComponent with CLoginManager, and let LoginPanel extend
> this instead??
>
> should i forget about all this decoupling nonsense at my
> newbie stage,
> build the app however i can, then worry about learning this
> stuff later?
The main question is if you need to have other classes than the LoginPanel
access the login functionality. If not (which is usually the case from the
beginning), then I would definitely build the login logic into the
LoginPanel. The motivation being to minimise code and complexity until there
is a need for it.
If (or when) there is a need to share it, what you could do is to possibly
create an abstract LoginComponent class that inherits Tapestry logic by
extending BaseComponent and has your login logic in it. LoginPanel and any
classes in addition to LoginPanel that need the login logic can inherit that
from LoginComponent. Your other components will (possibly) extend
BaseComponent directly. There are plenty of other possible solutions as
well, but again, I personally always try to go for the simplest stuff at
first and only add complexity when absolutely necessary. With unit testing,
refactoring is safe and not too much work.
/ Petter
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
RE: separation of logic
Posted by Petter Måhlén <pe...@elevance.se>.
> ok, further along now but still having some problems...attempting to
> decouple Hibernate code and login mechanics from my
> LoginPanel component
>
> currently:
>
> LoginPanel
> extends BaseComponent
>
> CLoginManager
> extends ILoginManager
>
> i guess the confusion i'm having stems from the fact that LoginPanel
> needs to extend BaseComponent to be Tapestry-aware, and also needs to
> extend CLoginManager to access the actual login mechanics
>
> so do i need to build another intermediate class to combine
> BaseComponent with CLoginManager, and let LoginPanel extend
> this instead??
>
> should i forget about all this decoupling nonsense at my
> newbie stage,
> build the app however i can, then worry about learning this
> stuff later?
The main question is if you need to have other classes than the LoginPanel
access the login functionality. If not (which is usually the case from the
beginning), then I would definitely build the login logic into the
LoginPanel. The motivation being to minimise code and complexity until there
is a need for it.
If (or when) there is a need to share it, what you could do is to possibly
create an abstract LoginComponent class that inherits Tapestry logic by
extending BaseComponent and has your login logic in it. LoginPanel and any
classes in addition to LoginPanel that need the login logic can inherit that
from LoginComponent. Your other components will (possibly) extend
BaseComponent directly. There are plenty of other possible solutions as
well, but again, I personally always try to go for the simplest stuff at
first and only add complexity when absolutely necessary. With unit testing,
refactoring is safe and not too much work.
/ Petter
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org