admin's interface - the best way to implement

[truetype]

One way is to create admin's part within project's folder using
namespaces so that admin controllers are stored in app/controllers/
admin/ and restrict access to these controllers for mere mortals using
authentication. It means that both users and admins work with the same
database, they share the same models, only the controllers are
different.

The other way is to create another project totally dedicated to
administration of the first, main project. So that models,
controllers, logs, libraries (all that stuff) for admin's project and
the main project are stored in different folders (locally on the
server). Admins have an access to the same models user have. Admins
have an access to the database of the main project (which could be
done in rails). Yet users don't have an access to admin's database
(and even more so for controllers), since these are different
databases, unlike the first way to implement this.

I slightly tend to implement it the second way. For security purposes.
Namely, mere users and admins don't share databases. Of course, admins
need to authorize themselves to gain control to administration anyway,
but, obviously, it's secure, when the databases are separated from
each other.

However, I believe, as always, both methods have their advantages and
disadvantages. Yet I cannot foresee disadvantages of the second way,
since this is the first time ever I'm trying to implement
administration.

Which is the best way in your opinion? And what are the pros and cons
of both ways?

Thanks.

[Greg Willits]

I do both depending on the application. When Admin functionality
closely follows application functionality and is generally limited to
CRUD and simplistic approval process functions, then I just build
admin inline with the application.

However, when admin functionality starts to look like a completely
different application because of the way data must be combined for
review, reports, business logic more complex than simple approvals,
and especially when the UI demands go beyond simple list & record
views, then I build a separate application because at that point it
really is a separate application due to differing UI, organization,
logic, etc.

IMO there's no real security advantage to either structure.

--
def gw
acts_as_n00b
writes_at(www.railsdev.ws)
end

[truetype]

Thanks for your answer.

How about deployment? I've never deployed ror application to date, so
the deployment itself could become an experience for me, let alone
simultaneous deployment of two applications. Is there any difference
or do any challenges arise, when you deploy application and its admin
part?

Thanks.

[Jashugan]

If you had two different applications, why would you have two
different databases? It seems like it would be a mess because you
would have to specify the connection type for some of the models.
Wouldn't it make sense just to use the same database and models, and
just have separate everything else? You could synchronize the Models
folder using source control, so you wouldn't have to repeat any of
that functionality across the two apps.

You would then need to specify all the routes, but you're doing that
anyways, because you're using resources, right? ;)

On Dec 16, 12:03 pm, truetype <oleg.lya...@gmail.com> wrote:
> Thanks for your answer.
>

> How about deployment? I've never deployed rorapplicationto date, so

> the deployment itself could become an experience for me, let alone
> simultaneous deployment of two applications. Is there any difference

> or do any challenges arise, when you deployapplicationand its admin

> > closely followsapplicationfunctionality and is generally limited to  

> > CRUD and simplistic approval process functions, then I just build  
> > admin inline with theapplication.
>
> > However, when admin functionality starts to look like a completely  

> > differentapplicationbecause of the way data must be combined for  

> > review, reports, business logic more complex than simple approvals,  
> > and especially when the UI demands go beyond simple list & record  

> > views, then I build a separateapplicationbecause at that point it  
> > really is a separateapplicationdue to differing UI, organization,