Still around :-)
Using a more direct IoC (or DI) makes dependencies very clear and easy
to change. Also, it will remove the need for some (but not all)
factories. So, if you are up to it, I propose moving into a type 2/3
IoC, rather than the current model.
/niklas
Rana Bhattacharyya wrote:
Hi,
These are the things I understand.
1. SecurityManager and UserManager are two different
activities. So there should be two different
components where UserManager is an optional component.
2. SecurityManager will use Credentials and
UserManager will use User. As the UserManager is an
optional component, the User is also an optional
object.
3. FileSystemView depends on what .... Credentials or
User? It is not very clear.
4. We will be able to create User when we have an
UserManager (which is an optional component).
Please write your comments about my understanding. Let
us first clarify our doubts then we shall think about
implementations. We do not want to modify the codebase
in a hurry when there is a major change.
Now I understand what Niklas Gustavsson meant by
"Inversion of Control" :).
Niklas, where are you?
Thanks,
Rana Bhattacharyya
--- Sergey Vladimirov <[EMAIL PROTECTED]> wrote:
Hi, Rana,
1. User Manager can use any User implemetation, this
is true. But what
should, for example, FileSystemManager use if it
need user implementation
from UserManager, not BaseUser?
For current moment it need to take user name from
request and lookup for
actual User from UserManager.
I don't think it is good. I don't think that
isolation User from UserManager
and User in request is good idea. In fact, my own
implementations of
FileSystemManager and SecurityManager would be much
simple with just storing
User from UserManager in Request.
More over, it is much better from perfomance point
of view.
2. Creating Users should be optional possibility of
UserManager, not
FTPServer. One more time about mine implementatios -
they don't allow to
create new users at all.
If "setters" needs only to create users, just leave
them in
AbstractUserManager which would use BaseUser.
5. Using BaseUser as Credentials is confusing. I
prefer to set user to null
until it is logged-in.
Sergey
2006/5/5, Rana Bhattacharyya <[EMAIL PROTECTED]>:
Hi,
Please find my comments below.
1. User manager can use any User implementation.
It is
not necessary to use BaseUser. It just happens
that
the user managers provided with the server use
BaseUser.
2. From API point of view, we only need the
getters
method from the User interface. But for setting we
need setters. So BaseUser has both getters and
setters. We need these setters for creating users.
3. The FTP server populates BaseUser to isolate
UserManager provided User implementation and the
BaseUser used internally. We do not assume that
the
UserManager provided User is BaseUser.
4. Probably, we can rename BaseUser to say FtpUser
to
remove the confusion.
5. We are using BaseUser internally just like the
Credentials object.
Thanks,
Rana Bhattacharyya
--- Sergey Vladimirov <[EMAIL PROTECTED]> wrote:
äÏÂÒÙÊ ÄÅÎØ, áÎÔÏÎ
Good day, Anton,
I considered different ways of implementation.
At
least two of them:
1. Store user name in request until user log-in.
2. Retrieve user by user name from UserManager,
but
set the flag, that it is
not init yet.
I selected first way, because there is
possibility
to create UserManager
which can retrieve user only with user name and
password. So we need to
store user name.
But I prefer to do it in new class, Credentials,
instead of using new String
field, because it is more readable and
understandable from my point of view.
So by this patch I "fix" two issues at one time:
1. Partially replace BaseUser with it
UserManager
specific implementation
2. Remove User from Request until User is
logged-in.
Sergey
2006/5/5, Anton Goldberg
<[EMAIL PROTECTED]>:
Hi Sergey,
(or should I say Sdravstvuy!). I looked
through
your patch and while I
totally agree with the idea behind the patch I
don't quite understand
the implementation.
Let me go into more details here.
As far as I understand UserManager works like
a
Factory (pattern) for
User. I.e. the particular implementation of
UserManager knows what
specific class implementing User interface it
needs to instantiate. So
the default (BaseUser) implementation should
be
replaced by
UserManager supplied implementation on log-in.
(PASS/USER commands).
As a thing that gets replaced BaseUser works
just
fine, without
introducing the new class Credentials, because
Credentials exposes a
subset of User (and BaseUser) functionality.
Now I have a slightly different issue - if you
noticed, I didn't reply
to the list. The reason being that while I
subscribed to the list
fine, I am unable to post from any of my email
addresses - I tryed my
workaddress, this gmail account and also my
personal mail server. I
wonder if you in your contributor role could
check
it out and let me
know what might be the reason I can not post.
You are quite welcome to reply in Russian, my
email client can read
russian letters just fine.
--
Anton
--
Sergey Vladimirov
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam
protection around
http://mail.yahoo.com
--
Sergey Vladimirov
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
