Re: [cgiapp] a question about urls mapping to the project directory layout

[punkish <suppressed>]

On Fri, 10 Dec 2004 13:58:02 +0900, Thilo Planz <suppressed> wrote:
>
> Hope that helps, I confused myself a little writing this,

;-)

Thanks much for your detailed response.


> > how does my url map to my various sub apps? Taking the example of a
> > relatively common app which has a general public area, a members only
> > area, and an admins only area, I would like my url to still stay
> 
> You mean you have "sub-apps" as in many instance scripts (as opposed to
> just one script with many runmodes)?
> If so, you should use the URL to dispatch between the scripts.
> 
> You could have
> 
> http://myapp/members/
> http://myapp/public/
> http://myapp/admins/
> 

yes, the above would be the easiest and the most logical approach.
However, I was hoping (wondering?) to avoid doing so. I would thinking
that I was have a simple http://myapp/runmode?and_a_bunch_of_params no
matter what the status of the viewer -- public, member, admin,
whatever. The aim is equal parts simplicity and obfuscation.

..
> 
> > The above would imply that I would have only one index.cgi, hence one
> > instantiation of my $public_app. How would I go about getting hold of
> > the correct $member_app or $admin_app based on who is looking at my
> > app (public or a common member or an admin)?
> 
> If you do not want to have separate scripts, you could
> 
>         1) have different runmodes for different people.
>                 The runmodes can check if access is permitted or not.
> 
>         2) have the same runmode do different things for different people
>                 (which is maybe a little confusing)
> 
> It seems you want to have your default runmode do different things for
> different people.
> (Method 2 above)
> I would set up a default runmode that just dispatches to the
> appropriate runmode for that group.
> 
> sub start{
>         my ($app) = @_;
>         # find out somehow what we really want as a start page
>         return $self->admin_start() if $admin;
>         return $self->member_start() if $member;
>         return $self->public_start();
> }
> 

yes, but once I have determined that I want, say, admin_start(), how
would I instantiate an $admin_webapp object?

I feel I might not be explaining this clearly. Let me try again --

I have a web application (driven by a db) that has records visible to
anyone who visits. However, once a user logs in, new powers become
available. These powers are different based on the type of user
(roles). I have kept all the scripts for each of these kinds of users
(I have 4 or 5 kinds of users) in separate folders. Converting this
whole enchilada to the C-A paradigm, I would probably start by
creating a virtual base class from C-A and put some common nonsense in
it. With this base class as the base(!), I would create a Public.pm, a
Usertype1.pm, Usertype2.pm, Admin.pm, etc. These packages would hold
the respective methods and such.

So far so good. However, if I want only index.cgi/blah?bunch_of_params
then I have to do an if..then..else somewhere to figure out which
package I would use to create my App->new()

-- 

punkish

---------------------------------------------------------------------
Web Archive:  http://www.mail-archive.com/suppressed/
              http://marc.theaimsgroup.com/?l=cgiapp&r=1&w=2
To unsubscribe, e-mail: suppressed
For additional commands, e-mail: suppressed