From: damien l. <da...@ba...> - 2003-03-23 16:01:10
|
i'd like to know recommendations regarding custom code that is relevant globally, not just in a specific OI package: for OI.regex_chunk() i need a multiple-line match; i could add an 's' before the semicolon in the line: my ( $item ) = $str =~ /$match/; or should i subclass Plugin.pm somehow, or use a component? if i do the latter, for miscellaneous components like this, should i wrap it in a new OI package? or just edit $OIWEBSITE/conf/action.perl and put a mysite.pm somewhere and a use() somewhere (where?)? damien -- http://babelguides.com/ <<world literature in translation>> |
From: Chris W. <ch...@cw...> - 2003-03-23 17:22:36
|
damien leri wrote: > i'd like to know recommendations regarding custom code that is relevant globally, not just in a specific OI package: > > for OI.regex_chunk() i need a multiple-line match; i could add an 's' before the semicolon in the line: > > my ( $item ) = $str =~ /$match/; > > or should i subclass Plugin.pm somehow, or use a component? > > if i do the latter, for miscellaneous components like this, should i wrap it in a new OI package? or just edit $OIWEBSITE/conf/action.perl and put a mysite.pm somewhere and a use() somewhere (where?)? A little-documented (and tested) feature is for a package to make available a Template Plugin that is accessible in all templates. In your package's package.conf you should be able to specify a plugin like this: name mypackage version 1.00 author Foo <fo...@ba...> url http://www.foo.com/ template_plugin MyPlugin OpenInteract::Template::MyPlugin description Blah blah And then reference the plugin as normal, using the first entry in the configuration line as the plugin name: [% USE MyPlugin %] [% matched = MyPlugin.multiline_match( var ) %] ... Chris -- Chris Winters (ch...@cw...) Building enterprise-capable snack solutions since 1988. |
From: damien l. <da...@ba...> - 2003-03-25 13:16:38
|
On Sun, Mar 23, 2003 at 12:32:19PM -0500, Chris Winters wrote: > template_plugin MyPlugin OpenInteract::Template::MyPlugin cool,thanks. another plugin function i have an issue with is make_url(), which joins params with '&', rather than '&'. Why not avoid both by using ';' as the param delimiter? d -- http://babelguides.com/ <<world literature in translation>> |
From: Chris W. <ch...@cw...> - 2003-03-25 15:24:07
|
damien leri wrote: > another plugin function i have an issue with is make_url(), which joins params with '&', rather than '&'. Why not avoid both by using ';' as the param delimiter? This is one of those issues that I was too lazy to research and went with what worked. Do GET parsing engines regard a lone '&' as an error? Do '&' and ';' work with everything? Chris -- Chris Winters (ch...@cw...) Building enterprise-capable snack solutions since 1988. |
From: Swen T. <swe...@te...> - 2003-03-25 15:44:03
|
On Tue, Mar 25, 2003 at 10:41:53AM -0500, Chris Winters wrote: > > This is one of those issues that I was too lazy to research and > went with what worked. Do GET parsing engines regard a lone '&' > as an error? Do '&' and ';' work with everything? Hmm. I do not know what you mean with "GET parsing engines". The problem is, that you have to make a distinction between HTTP and HTML here. The HTTP protocol defines '&' as the parameter separator. Since HTML is an SGML dialect or instance, the & has to be encoded in HTML as &, because & is special in SGML (and XML), it starts an entity (as ö or &oring; etc.). So in HTML you have to write something like <a href="blah?b=1&c=3">... The browser then decodes the entity & to & and uses this in the GET request for HTTP: GET blah?b=1&c=3 HTTP/1.0 A problem arises, when you want to do a redirect. If you have for example a library method redirect($url), which does not decode the entities, then you must not use & in the URL, you have to use & Most browsers allow you to use & in URLs, so you normally will get away with this, but this will not be the case for XHTML, which has to be wellformed XML. My guts feeling is, that ';' as separator might not work with every HTTP server, but I do not really know this. Hope this helps. Greetings, Swen |
From: <me...@st...> - 2003-03-25 15:53:38
|
>>>>> "Chris" == Chris Winters <ch...@cw...> writes: Chris> damien leri wrote: >> another plugin function i have an issue with is make_url(), which >> joins params with '&', rather than '&'. Why not avoid both by >> using Chris> ';' as the param delimiter? Chris> This is one of those issues that I was too lazy to research and went Chris> with what worked. Do GET parsing engines regard a lone '&' as an Chris> error? Do '&' and ';' work with everything? [Hmm. I have to repeat this on every mailing list I'm on, it seems.] A URI with CGI info generally looks like: http://some.host/cgi/scriptname?fred=flintstone&barney=rubble However, 99% of the time, you'll be putting that into an HTML page, where it has to be coded like: <FORM ACTION="http://some.host/cgi/scriptname?fred=flintstone&barney=rubble"> because "&" has to become "&" even in attributes. There are a *few* CGI processors that have adopted the "; is the same as &" recommendation, but at this point, you still shouldn't count on it. -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 <me...@st...> <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! |
From: Chris W. <ch...@cw...> - 2003-03-25 16:06:48
|
Randal L. Schwartz wrote: > [Hmm. I have to repeat this on every mailing list I'm on, it seems.] I knew that the subject would bait you into posting ;-) > A URI with CGI info generally looks like: > > http://some.host/cgi/scriptname?fred=flintstone&barney=rubble > > However, 99% of the time, you'll be putting that into an HTML page, > where it has to be coded like: > > <FORM ACTION="http://some.host/cgi/scriptname?fred=flintstone&barney=rubble"> > > because "&" has to become "&" even in attributes. > > There are a *few* CGI processors that have adopted the "; is the same as &" > recommendation, but at this point, you still shouldn't count on it. Crystal clear, thank you. I'll update the plugin to separate the parameters with '&'. Chris -- Chris Winters (ch...@cw...) Building enterprise-capable snack solutions since 1988. |
From: Andrew H. <hu...@ll...> - 2003-03-25 16:50:40
|
>There are a *few* CGI processors that have adopted the "; is the same as &" >recommendation, but at this point, you still shouldn't count on it. Wouldn't this only matter if you supported more than one CGI processor? If I recall correctly, Scoop used Apache::Request, and it supported ';' as an argument delimiter. Also, if the cgi processor you used didn't support it, couldn't you just get the whole URI and process it yourself? It's just 3 splits, on ?, on /, and on ;. So, am I missing a piece of the puzzle here? Or am I on the right track? -Andrew |
From: Chris W. <ch...@cw...> - 2003-03-25 17:16:46
|
Andrew Hurst wrote: > Wouldn't this only matter if you supported more than one CGI processor? > If I recall correctly, Scoop used Apache::Request, and it supported ';' > as an argument delimiter. Also, if the cgi processor you used didn't > support it, couldn't you just get the whole URI and process it > yourself? It's just 3 splits, on ?, on /, and on ;. > > So, am I missing a piece of the puzzle here? Or am I on the right track? Most of the time, yes. But you could be generating URLs for other sites, or other applications in the same site. Those may use an entirely different technology -- I was dismayed to learn that Tomcat, the reference Java Servlet container, doesn't recognize ';' as a query argument separator. Plus, down the path of manually parsing URIs lies madness :-) Chris -- Chris Winters (ch...@cw...) Building enterprise-capable snack solutions since 1988. |
From: Chris W. <ch...@cw...> - 2003-03-31 15:16:49
|
(cc'd to oi-dev) damien leri wrote: > on a table using an multifield object_id, there's trouble with > object_keys table, as shown in my log here. Should the value > for the object_id column be '8,1' or what? I'm pretty sure it should. I actually haven't used any with objects in OI, which is why I never ran into this problem. > quite possibly i've fouled up my spops conf for this class? i > could add an auto_increment field and make the current pkey > merely a unique one, if you think that would boost performance > or stability... i expect less than a few thousand records in > this table. the spops is at the end of this email. No, your SPOPS configuration is right. The problem is with something OI is trying to do: create an index of all objects so it can normalize the keys. so instead of having a 'class/object_id' in every table you just have an 'object_key', a 32-character MD5 checksum. I'm probably going to get rid of this in the next version, or at least make it more integrated. In any case, the fix will be in the next version. The problem is this in OI::SPOPS line 102: my $row = $self->db_select( { %{ $p }, from => OBJECT_KEY_TABLE, select => [ 'object_key' ], where => 'class = ? AND object_id = ?', value => [ ref $self, $self->id ], return => 'single' }); See, $self->id is in list context, which means it returns a list of your multiple keys rather than concatenating them. Easy to fix: just change it to 'scalar( $self->id )' and it should work. You can get around it now by using a surrogate primary key (auto-increment, which I generally recommend anyway) or by adding 'skip_object_key => 1' to your SPOPS configuration. Later, Chris -- Chris Winters (ch...@cw...) Building enterprise-capable snack solutions since 1988. |
From: damien l. <da...@ba...> - 2003-03-31 21:43:48
|
On Mon, Mar 31, 2003 at 10:34:57AM -0500, Chris Winters wrote: > In any case, the fix will be in the next version. The problem is > this in OI::SPOPS line 102: > > my $row = $self->db_select( > { %{ $p }, > from => OBJECT_KEY_TABLE, > select => [ 'object_key' ], > where => 'class = ? AND object_id = ?', > value => [ ref $self, $self->id ], > return => 'single' }); > > See, $self->id is in list context, which means it returns a list > of your multiple keys rather than concatenating them. Easy to > fix: just change it to 'scalar( $self->id )' and it should work. > yes this does it... also need to add the scalar() call in save_object_key() a few lines up. thanks damien |