Re: [cgi-prototype-users] Using multiple base classes for an app
Andrew == Andrew Gianni [EMAIL PROTECTED] writes:
Andrew I'd like to be able to do something like this:
Andrew sub config_class_prefix{
Andrew return qw( Project1::App Project2::App );
Andrew }
Andrew Then I could call name_to_page or shortname on pages from
Andrew either project. Does this sound like a good idea, or can you
Andrew suggest a better way to share pages and functionality between
Andrew applications?
This would be handled with a local-policy ::Mapper::*, as I just described
in my previous message.
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
merlyn@stonehenge.com URL:http://www.stonehenge.com/merlyn/
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
---
SF.Net email is Sponsored by the Better Software Conference EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile Plan-Driven Development * Managing Projects Teams * Testing QA
Security * Process Improvement Measurement * http://www.sqe.com/bsce5sf
___
cgi-prototype-users mailing list
cgi-prototype-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/cgi-prototype-users
Re: [cgi-prototype-users] CGI::Prototype::PathInfo
A == A Pagaltzis [EMAIL PROTECTED] writes:
A Looks sensible enough, but the mapper must be more abstract than
A you propose. Abstraction on the level you have in mind is not
A tenable because ::State::Pathinfo needs knowledge from
A ::Mapper::StrictLookup to be able to tell that
A /edit/user/ap
A is supposed to mean
A state = 'My::App::edit::user',
A positional_param = ['ap'],
A rather than
A state = 'My::App::edit',
A positional_param = ['user,'ap'],
A or
A state = 'My::App::edit::user::ap',
A positional_param = [],
Ewww. I'd never use code like that. But if you want to do it,
I suppose you can replace all of -dispatch isntead.
A How would a generic protocol for ::State::* to ask ::Mapper::*
A for possible states look? Is it sensible to define one?
A ::Mapper::Prefix would have to crawl @INC or something like that,
A f.ex.
Yeah, hadn't envisioned that. In my mind, state should come entirely
from the incoming environment. Mapping that to a class should be a
separate responsibility for maximum pluggability. Looks like the
best way is to leave -dispatch and call yours something like
CGIP::Dispatch::VariablePathinfo
or something like that, using ::Dispatch:: rather than ::State:: or
::Mapping:: to show that it's replacing both.
A After all is said and done, ::State::Pathinfo will have to be
A specific to ::Mapper::StrictLookup anyway, so that separation
A makes no sense. The only thing that does make sense to abstract
A is how a state is mapped to a class *after* it is fully looked up
A and validated.
A But that is so trivial a task that I don’t really see the point
A in a separate ::Mapper::* hierarchy. Putting a -get_class with a
A default `eval require ${prefix}::${state}` implementation into
A CGIP would suffice.
I'm presuming the default -get_class simply returns the prefixed
string classname, which is presumedly defined using some other means
(like all in one file). The autoload override allows it to be
dynloaded if it doesn't exist, but there are CGIP instances where that
won't be necessary, and I'm trying to keep the core CGIP as lean as
possible.
Consider also something like Slashdot, where the templates are loaded
from a database... I can also see that here. Maybe state-to-class is
dynamic based on current user ID or other security parameter? Really,
there's policy there, and it's best to let that be plugged in.
But if you need to poke around in order to even know the state, you've
got a tight coupling there, so you're going to be overriding all of
-dispatch, it seems.
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
merlyn@stonehenge.com URL:http://www.stonehenge.com/merlyn/
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
---
SF.Net email is Sponsored by the Better Software Conference EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile Plan-Driven Development * Managing Projects Teams * Testing QA
Security * Process Improvement Measurement * http://www.sqe.com/bsce5sf
___
cgi-prototype-users mailing list
cgi-prototype-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/cgi-prototype-users
Re: [cgi-prototype-users] CGI::Prototype::PathInfo
Randal == Randal L Schwartz merlyn@stonehenge.com writes: Randal Consider also something like Slashdot, where the templates are loaded Randal from a database... I can also see that here. Maybe state-to-class is Randal dynamic based on current user ID or other security parameter? Really, Randal there's policy there, and it's best to let that be plugged in. To further this, let's say I had a $big_client that needs to show a login page if the user isn't logged in, regardless of whatever state the -get_state returns. They can override -get_class to simply return the login page if not logged in, regardless of whatever state it's asked to show, and yet the old state is preserved for a return to FOO link. And then the -get_state can be changed from hidden fields to pathinfo without messing up the authorization section. -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 merlyn@stonehenge.com URL:http://www.stonehenge.com/merlyn/ Perl/Unix/security consulting, Technical writing, Comedy, etc. etc. See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training! --- SF.Net email is Sponsored by the Better Software Conference EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile Plan-Driven Development * Managing Projects Teams * Testing QA Security * Process Improvement Measurement * http://www.sqe.com/bsce5sf ___ cgi-prototype-users mailing list cgi-prototype-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/cgi-prototype-users
Re: [cgi-prototype-users] CGI::Prototype::PathInfo
* Randal L. Schwartz merlyn@stonehenge.com [2005-08-15 19:50]:
Ewww. I'd never use code like that.
At the HTTP level, it is cleaner design. Nobody on the other side
of the app interface will care whether it requires uglier
scaffolding under the hood, nor should they. Thus, neither do I.
Yeah, hadn't envisioned that. In my mind, state should come
entirely from the incoming environment. Mapping that to a
class should be a separate responsibility for maximum
pluggability. Looks like the best way is to leave -dispatch
and call yours something like
CGIP::Dispatch::VariablePathinfo
or something like that, using ::Dispatch:: rather than
::State:: or ::Mapping:: to show that it's replacing both.
I suppose that I’ll stick with the current monolithic design and
mind my own business for the time being, then. Since ::PathInfo
builds onto CGIP itself it should be unaffected by stuff that
gets added on top of that. I will see how it can be merged with
the future CGIP design that materializes.
Regards,
--
#Aristotle
*AUTOLOAD=*_=sub{s/(.*)::(.*)/print$2,(,$\/, )[defined wantarray]/e;$1};
Just-another-Perl-hacker;
---
SF.Net email is Sponsored by the Better Software Conference EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile Plan-Driven Development * Managing Projects Teams * Testing QA
Security * Process Improvement Measurement * http://www.sqe.com/bsce5sf
___
cgi-prototype-users mailing list
cgi-prototype-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/cgi-prototype-users
