Re: [cgiapp] Merging new dispatching idea with ::Dispatch (was: Re: RFC: Proposal for URL dispatching / routing in CGI::App )
On 12/12/05, Rob Kinyon [EMAIL PROTECTED] wrote: Here is my scenario to how the dispatcher could work. Treat every path as $app/$rm/@params. The dispatcher loads the $app and is defined executes the run mode. The dispatcher would stash the remaining elements (@params) for the run mode to optionally do something with. The run mode would then assign, validate and handle errors. To me this is a lot more straight forward and lightweight then creating an entire syntax to perform these functions IF you need them. A few things you don't seem to be considering: * I don't want my runmode name in my URL. - I want to leave refactoring as a possibility in the future - I want to hide information from potential attackers * I want to provide human-generatable URLs that map back to my runmodes. For example, /report/format/report_name?a=1b=2 would map to My::App::Report::run() and the format doesn't get used until the print() function which is defined in My::App::Base. How does your system handle this? * I want to provide /reports?/format which maps to My::App::Report::display() The addon to what you are commenting on is if a run mode was defined in the dispatch table the run mode is NOT extracted from the URL. I think we moved passed this suggestion though. Yeah - TABLE needs to be an array, not a hash. That was something that was carried over from how CGI::Application::Dispatch currently operates. I agree that it will have to change to an array reference to work as we are discussing. tim/ -- Timothy Appnel http://www.timaoutloud.org/ - Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [cgiapp] Merging new dispatching idea with ::Dispatch (was: Re: RFC: Proposal for URL dispatching / routing in CGI::App )
The addon to what you are commenting on is if a run mode was defined in the dispatch table the run mode is NOT extracted from the URL. I think we moved passed this suggestion though. It's not a suggestion - it's the entire point. If you have the runmode be part of the URL, then it's nothing more than a stupid way to do the current dispatching process. The point is that you divorce the URL from the runmode. Rob - Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [cgiapp] Re: Merging new dispatching idea with ::Dispatch (was: Re: RFC: Proposal for URL dispatching / routing in CGI::App )
On 12/12/05, Michael Graham [EMAIL PROTECTED] wrote: I think the run mode should only be taken from path_info when explicitly requested by the rule (e.g. /foo/:app/:rm ). I guess my concern is how do you automate the selection of run mode in the dispatcher if it can be anywhere (or not at all). is :rm a special variable declaration or is each app module required to know something about the dispatch table in order to select the right run mode? This is an interesting question. For most apps I want the run mode set, but every so often I have an exception, e.g: /get/path/to/file.html /get/other/path/to/other/file.html For an app like this, I don't want the run mode being set to 'path' or 'other'. And I also don't want to be forced to make my URLs artificially longer by including a dummy run mode: /get/view/path/to/file.html /get/view/other_path/to/other_file.html Sorry I'm not following what you mean here. tim/ -- Timothy Appnel http://www.timaoutloud.org/ - Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [cgiapp] Re: RFC: Proposal for URL dispatching / routing in CGI::App
On 12/11/05, Mark Stosberg [EMAIL PROTECTED] wrote: When you say the main code, are you referring to CGI::Application::Dispatch here? It's not clear to me. Me neither. I'm realizing that I may have jumped to the conclusion that we are working with CGI::Application::Dispatch as opposed to starting over. Does anyone disagree with building on what CGI::Application::Dispatch has established? tim/ -- Timothy Appnel http://www.timaoutloud.org/ - Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [cgiapp] Re: RFC: Proposal for URL dispatching / routing in CGI::App
On 12/12/05, Timothy Appnel [EMAIL PROTECTED] wrote: On 12/11/05, Mark Stosberg [EMAIL PROTECTED] wrote: When you say the main code, are you referring to CGI::Application::Dispatch here? It's not clear to me. main-code == CGI/Application.pm There is the current dispatching model within C::A::run() that, imho, needs to be pulled out into a plugin. That would become the default dispatcher. (Well, actually, the default default dispatcher, but that's another thread.) Rob - Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[cgiapp] Re: Trying out Catalyst's PAR support
On 2005-12-12, Michael Peters [EMAIL PROTECTED] wrote: Is it really possible to be able to create a truly platform independent distribution when some of the Perl modules contain XS/C code or are wrappers around other C libraries? From the PAR docs: Q: On what platforms can I run PAR? On what platforms will the resulting executable run? Win32 (with VC++ or MinGW), FreeBSD, NetBSD, Linux, MacOSX, Cygwin, AIX, Solaris, HP-UX, Tru64. The resulting executable will run on any platforms that supports the binary format of the generating platform. Does this mean par's generated on one architecture will not run on another? This is what I would expect. This is where there are limitations to PAR. You are quite right about XS code not being cross platform. PAR does have a multi-arch mode which includes a way to include platform dependent code for multiple platforms, much like Apple has binaries that run on PPC and Intel. However, there is no magic solution to generating platform independent binaries here. To add in the code for target platform, you are expected to run PAR /there/ as well. In the example, it just mentions src.pl. This part of the documentation is not clear. Is there is really a simple PAR command to run on the target server, or would you essentially have to copy the whole application and its dependencies over the new server to create the PAR file? (Which sort of defeats the purpose...) Can FreeBSD run Linux binaries? Generally, Yes. I've done it. But in this case, No, because FreeBSD couldn't find the libc.so.6 file in needed. It existed on the system under /usr/compat/linux, but wasn't found there. Mark - Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [cgiapp] Re: Merging new dispatching idea with ::Dispatch (was: Re: RFC: Proposal for URL dispatching / routing in CGI::App )
I think the run mode should only be taken from path_info when explicitly
requested by the rule (e.g. /foo/:app/:rm ).
I guess my concern is how do you automate the selection of run mode in
the dispatcher if it can be anywhere (or not at all). is :rm a special
variable declaration or is each app module required to know something
about the dispatch table in order to select the right run mode? This
is an interesting question.
Yes, we've been assuming that :rm is a special placeholder name that
sets current_run_mode, not $self-param('rm').
For most apps I want the run mode set, but every so often I have an
exception, e.g:
/get/path/to/file.html
/get/other/path/to/other/file.html
For an app like this, I don't want the run mode being set to 'path' or
'other'. And I also don't want to be forced to make my URLs
artificially longer by including a dummy run mode:
/get/view/path/to/file.html
/get/view/other_path/to/other_file.html
Sorry I'm not following what you mean here.
You were asking whether run_modes should automatically be parsed from
URLs if they are left out of the dispatch parameters and I was
illustrating why that would be a Bad Idea (tm).
Obviously the URL /get/some/file/somewhere.htm wants $rm to be left
unset and $path to be set to '/some/file/somewhere.html'. It doesn't
want $rm set to 'some' and @params set to ('file', 'somewhere.html').
There are other reasons why it's a bad idea to *always* parse the run
mode from the URL (Rob pointed some out), but this is the reason that
hits home for me, since I actually have apps that work like this.
Michael
---
Michael Graham [EMAIL PROTECTED]
-
Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/
http://marc.theaimsgroup.com/?l=cgiappr=1w=2
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [cgiapp] Re: RFC: Proposal for URL dispatching / routing in CGI::App
Timothy Appnel [EMAIL PROTECTED] wrote: I'm realizing that I may have jumped to the conclusion that we are working with CGI::Application::Dispatch as opposed to starting over. Does anyone disagree with building on what CGI::Application::Dispatch has established? CGI::Application::Dispatch has a very central namespace, and it would be good if the community-endorsed next generation dispatcher could use it. However, what we are suggesting is quite different from what CGI::Application::Dispatch currently does. It's similar in spirit, but in implementation, there are lots of little details that differ. I'm worried that the documentation becomes very confusing because the old terminology and new terminolgy are similar, even though the implentation is different. E.g.: %TABLE is used to map specific URLs to specific modules. @DISPATCH is a new system for mapping URL-rules to specific modules. A user familiar with the old system will understand this. A new user will be totally confused. And you can't leave the old behaviour undocumented, because people are still using it and they'll want to look up stuff in the docs. So some options are: * Use a different namespace for the new system (e.g. CA::URLMaps, CA::Routes, CA::Launcher, CA::StartMeUp etc.) * Put all the old docs in CA::Dispatch::COMPAT.pod, but leave all the old features turned on for backwards compatiblity. * Do something as Rob suggests with a pluggable dispatch architecture. In this case CA::Dispatch would probably become CA::Plugin::Dispatch, anyway. Michael --- Michael Graham [EMAIL PROTECTED] - Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [cgiapp] Re: RFC: Proposal for URL dispatching / routing in CGI::App
Michael Graham wrote: Timothy Appnel [EMAIL PROTECTED] wrote: I'm realizing that I may have jumped to the conclusion that we are working with CGI::Application::Dispatch as opposed to starting over. Does anyone disagree with building on what CGI::Application::Dispatch has established? CGI::Application::Dispatch has a very central namespace, and it would be good if the community-endorsed next generation dispatcher could use it. I agree. However, what we are suggesting is quite different from what CGI::Application::Dispatch currently does. It's similar in spirit, but in implementation, there are lots of little details that differ. I'm worried that the documentation becomes very confusing because the old terminology and new terminolgy are similar, even though the implentation is different. E.g.: %TABLE is used to map specific URLs to specific modules. @DISPATCH is a new system for mapping URL-rules to specific modules. A user familiar with the old system will understand this. A new user will be totally confused. And you can't leave the old behaviour undocumented, because people are still using it and they'll want to look up stuff in the docs. I'm not so sure this would be a problem. I think we can document both approaches and note that the old one is deprecated (like D::FV does). Put the newer approach in all examples, but leave the older stuff there, maybe in a different section. So some options are: * Use a different namespace for the new system (e.g. CA::URLMaps, CA::Routes, CA::Launcher, CA::StartMeUp etc.) Dispatch is a much better name though :) * Put all the old docs in CA::Dispatch::COMPAT.pod, but leave all the old features turned on for backwards compatiblity. Right now I'm inclined to do something like this, even if I don't split it out into it's own separate pod file. * Do something as Rob suggests with a pluggable dispatch architecture. In this case CA::Dispatch would probably become CA::Plugin::Dispatch, anyway. But C::A::D can't really be plugin since it sit's outside of C::A. Especially in mod_perl where it becomes you PerlHandler. It doesn't add anything to C::A, it just handles the mapping of URL to module/rm. That said, the new approach would be a mixture of both. C::A::D would still need to sit outside of C::A, but there would need to be another module (or maybe just a different usage of C::A::D) that acts as a plugin to add the uri_for() and link_to() methods to C::A My preference would be to keep all the old features of C::A::D but point people to ways of accomplishing the same thing with the new-way. Maybe even make the old-way work behind the scenes by using the new-way. I'm kinda busy right now, but I have something in my head. If I get some time today or tomorrow, I'll write it up the API and see what others think. -- Michael Peters Developer Plus Three, LP - Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [cgiapp] Re: RFC: Proposal for URL dispatching / routing in CGI::App
On 12/12/05, Michael Graham [EMAIL PROTECTED] wrote: However, what we are suggesting is quite different from what CGI::Application::Dispatch currently does. It's similar in spirit, but in implementation, there are lots of little details that differ. Let me ask the same question I put out earlier. Why not? Mark put out his and I addressed how his issues could be addressed in that framework. I don't see what you mean or why such a path is so necessary. I'm worried that the documentation becomes very confusing because the old terminology and new terminolgy are similar, even though the implentation is different. E.g.: %TABLE is used to map specific URLs to specific modules. @DISPATCH is a new system for mapping URL-rules to specific modules. A user familiar with the old system will understand this. A new user will be totally confused. I don't agree with adding @DISPATH and a new system for mapping though. That is an artificial distinction IMHO. TABLE contains a reference to a hash in the current implementation. It would be trivial to check what type of reference is in there and act accordingly. This way backwards compatibility is maintained and users used to the old way can keep using it. And you can't leave the old behaviour undocumented, because people are still using it and they'll want to look up stuff in the docs. Of course not. As I've illustrated you can support both with little disruption or modification to the code. Granted its not ideally how it would be done if we were building from the ground up, but I think reinventing the wheel is a worse thing(tm). So some options are: * Use a different namespace for the new system (e.g. CA::URLMaps, CA::Routes, CA::Launcher, CA::StartMeUp etc.) If the community is serious about taking some cues from Rails then adding more similar, but different options is not advisable. * Put all the old docs in CA::Dispatch::COMPAT.pod, but leave all the old features turned on for backwards compatiblity. Once again, I don't see why this would be necessary. Adding a note in the documentation stating the array reference is the preference and were the hash reference came from should be sufficient. * Do something as Rob suggests with a pluggable dispatch architecture. In this case CA::Dispatch would probably become CA::Plugin::Dispatch, anyway. This doesn't work for me for a number of reasons. Not every application will have multiple instance scripts/app modules for one. This adds a complexity with little value also. As David Heinemeier Hansson has been known to say flexibility is overrated. I have agree based on my experience -- I'd gladly take one simple way of doing things then being able to do it however I want. Rather then just look at the documentation and APIs to Rails I started reading some of the philosophy and zen behind Rails and found an interesting passage from DHH that I wanted to put out into this conversation. When asked why is Rails so popular he replied... Rails is opinionated software. It eschews placing the old ideals of software in a primary position. One of those ideals is flexibility—the notion that we should try to accommodate as many approaches as possible, that we shouldn't pass judgement on one form of development over another. Well, Rails does, and I believe that's why it works. With Rails, you trade flexibility at the infrastructure level to gain flexibility at the application level. If you are happy to work along the golden path that I've embedded in Rails, you gain an immense reward in terms of productivity that allows you to do more, sooner, and better at the application level. The entire interview is here if you are interested in reading it all: http://www.oreillynet.com/pub/a/network/2005/08/30/ruby-rails-david-heinemeier-hansson.html) This is the biggest point I think Cataylst misses that I'm rather disappointed in it. (Hence I'm here having this conversation and not somewhere else using Catayst.) If we learn anything from the mistakes of others my hope is that it is this. tim/ -- Timothy Appnel http://www.timaoutloud.org/
Re: [cgiapp] Re: RFC: Proposal for URL dispatching / routing in CGI::App
However, what we are suggesting is quite different from what
CGI::Application::Dispatch currently does. It's similar in spirit, but
in implementation, there are lots of little details that differ.
Let me ask the same question I put out earlier. Why not? Mark put out
his and I addressed how his issues could be addressed in that
framework. I don't see what you mean or why such a path is so
necessary.
Sorry, I may be stating the obvious, but all I'm saying is that the
following are two very different systems, but similar enough in spirit
that they may confuse new users:
# old style
TABLE = {
'blog' = 'MySite::Blog',
'admin_users' = 'MySite::Admin::Users',
}
# new style
TABLE = [
'blog/:rm'= { app = Blog },
'admin/:app/:rm' = { prefix = 'MySite::Admin' },
]
But maybe I'm not understanding your question. Are you asking me why I
think these systems are different? Or are you asking me to justify why
I want the second one?
I don't agree with adding @DISPATH and a new system for mapping
though. That is an artificial distinction IMHO. TABLE contains a
reference to a hash in the current implementation. It would be trivial
to check what type of reference is in there and act accordingly. This
way backwards compatibility is maintained and users used to the old
way can keep using it.
Good point - there's no reason why it can't still be called TABLE. That
has the nice side effect that the system doesn't have to figure out what
to do if the user provides both a new-style and an old-style mapping at
the same time.
* Use a different namespace for the new system (e.g. CA::URLMaps,
CA::Routes, CA::Launcher, CA::StartMeUp etc.)
If the community is serious about taking some cues from Rails then
adding more similar, but different options is not advisable.
I tend to favour standardization over competition myself. All I'm
saying is this has to be balanced with legacy code and backwards
compatibility issues. Sometimes it's cleaner to start fresh.
* Put all the old docs in CA::Dispatch::COMPAT.pod, but leave all the
old features turned on for backwards compatiblity.
Once again, I don't see why this would be necessary. Adding a note in
the documentation stating the array reference is the preference and
were the hash reference came from should be sufficient.
I'm certainly willing to go this route. I'm just saying we should be
careful, is all. I've seen modules with layers of legacy documentation
that were really confusing to me when I approached them as a new user.
The Rails quotes on flexibility were interesting. I tend to agree with
whoever said absense of constraints are the enemy of art.
In terms of this discussion, I hope it doesn't look like I'm arguing for
flexibility for its own sake. I'm trying very hard not to request
features that I *might* need in the future. Sure I've done some
speculation, but when I've requested features, I've tried to restrict
myself to real URLs that I already use in my own homegrown mapping
system.
From my perspective, with my variety of real-world mapping requirements,
allowing '/string/:app/:rm' = { prefix = 'Foo' } is a *minimalist*
solution. Believe it or not. :)
Michael
---
Michael Graham [EMAIL PROTECTED]
-
Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/
http://marc.theaimsgroup.com/?l=cgiappr=1w=2
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [cgiapp] Re: RFC: Proposal for URL dispatching / routing in CGI::App
* Do something as Rob suggests with a pluggable dispatch architecture. In this case CA::Dispatch would probably become CA::Plugin::Dispatch, anyway. But C::A::D can't really be plugin since it sit's outside of C::A. Especially in mod_perl where it becomes you PerlHandler. It doesn't add anything to C::A, it just handles the mapping of URL to module/rm. Yeah, I know - but I gather Rob's got some ideas for making C::A's dispatch system pluggable, though. I'm not sold on it, but it seems like it will be an interesting discussion. I do like the idea of being able to use CA::Dispatch as a PerlTransHandler thought. ... My preference would be to keep all the old features of C::A::D but point people to ways of accomplishing the same thing with the new-way. Maybe even make the old-way work behind the scenes by using the new-way. I'm kinda busy right now, but I have something in my head. If I get some time today or tomorrow, I'll write it up the API and see what others think. Coolness! Michael --- Michael Graham [EMAIL PROTECTED] - Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [cgiapp] Re: RFC: Proposal for URL dispatching / routing in CGI::App
On 12/12/05, Michael Graham [EMAIL PROTECTED] wrote:
But maybe I'm not understanding your question. Are you asking me why I
think these systems are different? Or are you asking me to justify why
I want the second one?
I was just curious why you are suggesting a new module and why
CGI::Application::Dispatch couldn't be adapted to provide the features
being discussed.
From my perspective, with my variety of real-world mapping requirements,
allowing '/string/:app/:rm' = { prefix = 'Foo' } is a *minimalist*
solution. Believe it or not. :)
I think you mean app and not prefix in that hash. PREFIX is an
existing option in CGI::Application::Dispatch.
Did anyone have any thoughts on moving the variable assignment into
the hash instead of tacking them onto the TABLE key? I.E.
'string' = { app= 'Foo', params=':app/:rm' }
Does this add clarity so that conflicting dispatch rules are created?
It did for me though I'm still not clear to how a missing required
parameter is handled. (Who handles the error? The run mode or the
dispatcher?)
tim/
--
Timothy Appnel
http://www.timaoutloud.org/
-
Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/
http://marc.theaimsgroup.com/?l=cgiappr=1w=2
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[cgiapp] Everything is a plugin
On 12/12/05, Michael Graham [EMAIL PROTECTED] wrote: * Do something as Rob suggests with a pluggable dispatch architecture. In this case CA::Dispatch would probably become CA::Plugin::Dispatch, anyway. But C::A::D can't really be plugin since it sit's outside of C::A. Especially in mod_perl where it becomes you PerlHandler. It doesn't add anything to C::A, it just handles the mapping of URL to module/rm. Yeah, I know - but I gather Rob's got some ideas for making C::A's dispatch system pluggable, though. I'm not sold on it, but it seems like it will be an interesting discussion. I do like the idea of being able to use CA::Dispatch as a PerlTransHandler thought. Here's the basic concept - CA defines the steps that need to be taken (dispatch, CGI param parsing, runmode execution, error handling, template processing, etc). But, it doesn't implement any code to do those things. It has plugins to do all the things that need done. It merely defines the interface and the order of operations. (And, technically, even THAT should be in a plugin. But, that's getting a little TOO meta for most needs.) So, essentially, CA does the following upon being used: 1) Load all the plugins requested. Each plugin will register as being used for a specific purpose (which could be I add methods). 2) Verify that all required steps (such as dispatching) have a plugin loaded or load the default one. mod_perl will still call CA-handle, just as it does right now. I'm talking about the CA-internal cycle. I haven't fleshed out all the details yet. For one thing, the last time I did any serious looking at the internals was to add error_mode. So, someone would need to document the complete response cycle and we, as a group, would need to identify where we can say THIS belongs to this phase and THAT belongs to that phase. Once that's done, the internals need to be ripped out and rewritten. No new features, though. It is enough to pass the current testsuite. Then, once that's done, dropping items in should be a breeze. Rob - Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [cgiapp] Everything is a plugin
So, essentially, CA does the following upon being used: 1) Load all the plugins requested. Each plugin will register as being used for a specific purpose (which could be I add methods). 2) Verify that all required steps (such as dispatching) have a plugin loaded or load the default one. This sounds a lot like what I concluded when developing Application::Pipeline and WWW::Pipeline, except that I didn't do step 2. Phases in the pipeline that didn't have methods registered simply didn't run. This didn't really present an issue for me because a) there are so few phases in a WWW::Pipeline that they're hard to overlook, and b) A few plugins provided the base methods for most of those phases. It seems to me that perhaps CGI::Application should consider loading 'standard' plugins for steps where a plugin hasn't already been assigned, rather than falling back on hard coded default methods. -Stephen - Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [cgiapp] Re: RFC: Proposal for URL dispatching / routing in CGI::App
From my perspective, with my variety of real-world mapping requirements,
allowing '/string/:app/:rm' = { prefix = 'Foo' } is a *minimalist*
solution. Believe it or not. :)
I think you mean app and not prefix in that hash. PREFIX is an
existing option in CGI::Application::Dispatch.
No, I do actually mean prefix. I'm suggesting that each rule be able to
override the default PREFIX. The :app is already determined from the
rule. Here is a slightly less contrived example table followed by some
example URLs and their results:
PREFIX = 'MySite',
TABLE = [
'blog/:rm'= { app= 'Blog' },
'admin/:app/:rm' = { prefix = 'MySite::Admin' }
'get/:path' = { app= 'GetDoc' }
':app/:rm'= { }
],
URL Module Run Mode
--- --
/blog/show MySite::Blog show
/blog/list MySite::Blog list
/blog MySite::Blog
/admin/users/edit MySite::Admin::Users edit
/admin/users/addMySite::Admin::Users add
/admin/usersMySite::Admin::Users
/foo/barMySite::Foobar
/get/some/doc.pdf MySite::GetDocument
(params: path=/some/doc.pdf)
/get/other/doc.pdf MySite::GetDocument
(params: path=/other/doc.pdf)
So the default PREFIX is always prepended, unless overridden by a rule.
Did anyone have any thoughts on moving the variable assignment into
the hash instead of tacking them onto the TABLE key? I.E.
'string' = { app= 'Foo', params=':app/:rm' }
Does this add clarity so that conflicting dispatch rules are created?
I dunno. I still prefer matches to the left, results to the right.
It did for me though I'm still not clear to how a missing required
parameter is handled. (Who handles the error? The run mode or the
dispatcher?)
Well, that's an argument against, right there. We're not doing input
validation, but rather URI matching. So we don't have required
parameters in the validation sense. It's simply that non-matching URIs
don't match.
So while these are duplicates:
'blog/:year/:month?/:day?' = { app = 'Blog' }
'blog/:page' = { app = 'Blog' }
these aren't:
'blog/:year/:month/:day?' = { app = 'Blog' }
'blog/:page' = { app = 'Blog' }
In the second case, /blog/2002/12 matches the first rule, but /blog/2002
matches the second.
Michael
---
Michael Graham [EMAIL PROTECTED]
-
Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/
http://marc.theaimsgroup.com/?l=cgiappr=1w=2
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [cgiapp] Re: RFC: Proposal for URL dispatching / routing in CGI::App
Timothy Appnel wrote:
On 12/12/05, Michael Graham [EMAIL PROTECTED] wrote:
PREFIX = 'MySite',
TABLE = [
'blog/:rm'= { app= 'Blog' },
'admin/:app/:rm' = { prefix = 'MySite::Admin' }
'get/:path' = { app= 'GetDoc' }
':app/:rm'= { }
],
PREFIX is optional in Dispatch. What is the harm in this?
TABLE = [
'blog/:rm'= { app= 'MySite::Blog' },
'admin/:app/:rm' = { app = 'MySite::Admin' }
'get/:path' = { app= 'MySite::GetDoc' }
':app/:rm'= { }
]
This won't work as intended because the 'admin/:app/:rm' rule can't work with
multiple apps under the 'MySite::Admin' prefix. In order to make this work with
a non-overridable PREFIX, he'd need to make an entry for each app class under
the 'MySite::Admin' namespace, which could get kinda tedious.
I personally think that being able to override things like PREFIX, on a
case-by-case basis would be a good thing.
This also brings up another question. If a rule has ':app' in it, should a
warning/error be thrown if the right-hand side has app = 'Foo' in it? If not,
what should happen?
So while these are duplicates:
'blog/:year/:month?/:day?' = { app = 'Blog' }
'blog/:page' = { app = 'Blog' }
these aren't:
'blog/:year/:month/:day?' = { app = 'Blog' }
'blog/:page' = { app = 'Blog' }
In the second case, /blog/2002/12 matches the first rule, but /blog/2002
matches the second.
I had to read your example three times before I understood why which
is what I'm getting at. This still seems too confusing. It seems to me
there has to be a better way or perhaps, in order to support what you
propose, some form of simple regex pattern matching is required to
disambiguate URL patterns like in your first example. This way :year
can be defined as 4 digits (\d{4}) and will let single parameters fall
to another rule. Rails has such a feature in their routes. That left
side could get really gruesome looking if your patterns are complex
enough.
We've already talked about using regexes on the left hand side in previous
emails and here are the main reasons against that:
+ regexes don't allow for named captures. You couldn't have it automatically
know which part of the match was the :app or :rm if any. This would require
inventing a new synax for that and then created our own regex parser to deal
with it
+ regexes are uglier. Not an important reason, but a reason non-the-less.
Regexes are their own mini-language, and no one will deny that they can be
pretty complex and sometimes confusing. We feel that all cases could be handled
by the syntax that's been proposed.
--
Michael Peters
Developer
Plus Three, LP
-
Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/
http://marc.theaimsgroup.com/?l=cgiappr=1w=2
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [cgiapp] Re: RFC: Proposal for URL dispatching / routing in CGI::App
On Mon, 12 Dec 2005 17:39:34 -0500, Timothy Appnel wrote:
Hi Tim
first example. This way :year can be defined as 4 digits (\d{4})
and will let single parameters fall to another rule. Rails has such
But what if I have a non-year value which is 4 digits?
--
Ron Savage
[EMAIL PROTECTED]
http://savage.net.au/index.html
-
Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/
http://marc.theaimsgroup.com/?l=cgiappr=1w=2
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[cgiapp] Re: Everything is a plugin
On 2005-12-12, Stephen Howard [EMAIL PROTECTED] wrote: So, essentially, CA does the following upon being used: 1) Load all the plugins requested. Each plugin will register as being used for a specific purpose (which could be I add methods). 2) Verify that all required steps (such as dispatching) have a plugin loaded or load the default one. This sounds a lot like what I concluded when developing Application::Pipeline and WWW::Pipeline I was thinking the same thing. I would suggest anyone interesting in further exploring this line of thinking take a hard look at those modules. While I believe Stephen designed them well, note how long they've been released and the relatively small amount of developer energy around. My own sense that they define an academic extreme, while CGI::Application hits a sweet spot in the amount of functionality it provides versus abstracts. Mark -- http://mark.stosberg.com/ - Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[cgiapp] running modes in sequence
Hi all.
New to CGI::App and am wondering how to do the following in C::A that I
was doing with a switch statement previously.
The old:
SWITCH: for ($query-param('funct')) {
/save project/ido { saveproject(); editproject(); last; };
}
The above runs sub called 'saveproject' and then when completed runs
'editproject'. How do I run two runmodes in one trip to my application
with C::A?
The new:
sub setup {
$self-start_mode('menu');
$self-mode_param('rm');
$self-run_modes(
'menu' = 'adminmenu',
'save' = 'saveproject',
???
}
Is there anyway to send a hash, something like:
sub setup {
$self-start_mode('menu');
$self-mode_param('rm');
$self-run_modes(
'menu' = 'adminmenu',
'save' = { 'step1' = 'saveproject',
'step2' = 'editproject'}
}
Of course, I could call 'editproject' from 'saveproject', but that defeats
the modularity of the script.
Thanks, Brad
-
Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/
http://marc.theaimsgroup.com/?l=cgiappr=1w=2
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [cgiapp] running modes in sequence
Hi,
Look into CGI::Application::Plugin::Forward, it does this.
Usually after you finish a runmode that saves something, or deletes
etc, you want to forward onto a function that draws your page, pulls
in your variables and lists etc.
This function is ideal for that.
Jeff.
On 12/12/05, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Hi all.
New to CGI::App and am wondering how to do the following in C::A that I
was doing with a switch statement previously.
The old:
SWITCH: for ($query-param('funct')) {
/save project/ido { saveproject(); editproject(); last; };
}
The above runs sub called 'saveproject' and then when completed runs
'editproject'. How do I run two runmodes in one trip to my application
with C::A?
The new:
sub setup {
$self-start_mode('menu');
$self-mode_param('rm');
$self-run_modes(
'menu' = 'adminmenu',
'save' = 'saveproject',
???
}
Is there anyway to send a hash, something like:
sub setup {
$self-start_mode('menu');
$self-mode_param('rm');
$self-run_modes(
'menu' = 'adminmenu',
'save' = { 'step1' = 'saveproject',
'step2' = 'editproject'}
}
Of course, I could call 'editproject' from 'saveproject', but that defeats
the modularity of the script.
Thanks, Brad
-
Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/
http://marc.theaimsgroup.com/?l=cgiappr=1w=2
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Jeff MacDonald
http://www.halifaxbudolife.ca
http://www.nintai.ca
-
Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/
http://marc.theaimsgroup.com/?l=cgiappr=1w=2
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [cgiapp] Re: Everything is a plugin
Mark Stosberg wrote: On 2005-12-12, Stephen Howard [EMAIL PROTECTED] wrote: So, essentially, CA does the following upon being used: 1) Load all the plugins requested. Each plugin will register as being used for a specific purpose (which could be I add methods). 2) Verify that all required steps (such as dispatching) have a plugin loaded or load the default one. This sounds a lot like what I concluded when developing Application::Pipeline and WWW::Pipeline I was thinking the same thing. I would suggest anyone interesting in further exploring this line of thinking take a hard look at those modules. While I believe Stephen designed them well, note how long they've been released and the relatively small amount of developer energy around. While some part of me certainly wouldn't mind having more people using my code, Mark is right ... my order of tuits has been back ordered for months, and there are a number of updates that I either haven't implemented or haven't uploaded to CPAN. Mark has been kind enough on more than one occasion to make good suggestions along the same lines. But my point of posting was more a prior art kind of thing. That _if_ people are wondering what a sparse-skeleton/all-plug in architecture looks like, I've made one, and use it in production on a daily basis. I apologize if it merely looked like I was taking a chance for self-promotion. -Stephen My own sense that they define an academic extreme, while CGI::Application hits a sweet spot in the amount of functionality it provides versus abstracts. Mark - Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [cgiapp] Re: RFC: Proposal for URL dispatching / routing in CGI::App
Timothy Appnel [EMAIL PROTECTED] wrote:
On 12/12/05, Michael Graham [EMAIL PROTECTED] wrote:
...
Prefix is a nice short hand when all
modules share the similar names, but it complicates matters when you
are dealing with modules from completely different namespaces.
Which is why you don't use 'prefix' when you really mean 'app'. That's
why I gave examples of both:
'admin/:app/:rm' = { prefix = 'MySite::Admin' }
'get/:path' = { app= 'GetDoc' }
In some cases (when you have a bunch of modules under a namespace), you
want to use a prefix. In other cases you don't even want to derive the
module name from the URL.
The reason I want to allow 'prefix' in the results section is because
sometimes a dispatcher sits in front of more than one namespace.
This feels like a fringe case to me.
Well, it may seem esoteric to you, but the examples I gave are pretty
close to what I use every day.
Yes, but these examples are deliberately contrived to illustrate the
mechanics of the mapping system, and the various edge cases. They are
not meant to be real world examples. If you used a mapping like the
above in real life, you get what you deserve, IMO.
I don't see these are being edge cases since your scenario it
precisely how Movable Type constructs its URLs by default. Not to say
that we're going to build MT here, but that your example URL scheme is
not that exotic or outlandish.
I don't have an MT system handy to test with, but I do want to point out
that that we're only talking about *optional* parameters. There is no
ambiguity here:
'blog/:year/:month' = { app = 'Blog' }
'blog/:id' = { app = 'Blog' }
I'm either for really simple or going all the way (i guess that would
essentially be a port of what Ruby's Routes does) with really simple
being my overwhelming preference. What you are advocating is between
the two and seems more incomplete then a compromise.
Well that seems a bit like all-or-nothing thinking to me. The syntax
I've been promoting is good enough to handle all of the mapping
scenarios that I've had to deal with, so I can't say it seems
incomplete to me.
You seem to have latched on to a very small aspect of the system, namely
the it's possible that programmers will shoot themselves in their feet
by accidentally entering duplicate rules. I suspect that this is going
to be a trap with *any* system that involves matching.
For instance, using your proposed syntax:
'blog' = { app = 'Blog', params = ':rm' }
'blog/admin' = { app = 'Admin', params = ':rm' }
What does 'blog/admin' match? By your reckoning it should be *obvious*
that it matches the first rule, but it isn't obvious to me.
Michael
---
Michael Graham [EMAIL PROTECTED]
-
Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/
http://marc.theaimsgroup.com/?l=cgiappr=1w=2
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
