On Tuesday 17 September 2002 01:45 pm, you muttered:
> >>I've been meaning for a long time to release some code samples--
>
> I have created the ability in the system to have includes shared
> pretty easily with the Share:: namespace, but haven't put anything
> in there yet. This namespace is Apache::ASP::Share more generally,
> so this could then a module like Apache::ASP::Share::Wizard,
> which might export a menu() subroutine, that someone could then
> wire pretty easily into their XMLSubs package namespace?
> Then this sub could be distributed with Apache::ASP.
So basically you're saying create a directory on my system
/usr/lib/<wherever perl goes>/Apache/ASP/Share/Wizard
and put my modules (*.pm) in there...
Then I could:
use Apache::ASP::Share::Wizard::MyModule;
> Alternatively, you could publish this to CPAN as the
> Apache::ASP::Share::Wizard package, and put everything you
> want in there at your leisure. Useful templates can be loaded
> from that like $Response->Include("Share::Wizard/template.inc")
> and the subs/objects can be imported normally. That would
> be cool if at the end of an install, someone could
> man/perldoc Apache::ASP::Share::Wizard
Heh, is that a hint?? ;)
I have tons of '#' comments sprinkled throughout my code but never got in the
habit of doing the perldoc way. Perhaps now is a good time to get started.
You may be doing me a back-handed favor ;)
> I wish I had a better structured interface for this, or
> a XMLSubs namespace mapping ability, but I have neither yet
> hooked into Apache::ASP. The Share:: include namespace
> was hard enough to work out as it was.
>
> >><table><tr><td>
> >><my:menu selected="$$args{cmd}">
> >> <sel><b><a href="__URL__">__CAPTION__</a></b><br></sel>
> >> <norm><a href="__URL__">__CAPTION__</a><br></norm>
> >></my:menu>
> >></td></tr></table>
>
> Did you know that in the body of an XMLSubs, you can do things
> like <%= $Object->URL %> instead of the __URL__.
Unless I misunderstand your meaning, I don't think that would do what I want
in this instance since the __TOKENS__ are not being processed until they get
inside the subroutine, and more to the point, the values of the tokens are
undefined until given meaning (scoped into context) by the page-item
iteration loop. Also, what you're suggesting takes place before the
subroutine anyway... yes?
> I begin to
> see how it would be nice to offer a set of standard XMLSubs
> that can do such things as __TOKEN__ post processing as standard.
Yes, that would be very nice. BTW, I have another, slightly more generic
version of the menu/navbar routine that does something similar to what you're
suggesting. It retrieves a row-hash from a DBI datasource and allows
__TOKENS__ to be substituted if they exist in the row-hash. (This is the
function I was thinking last night when I was doing my description). I'm
planning on releasing it as well. Perhaps that will give you, or others some
ideas.
If you REALLY REALLY wanted to do the world a favor (well, the asp community
anyway)-- make up a nice set of methods to abstract/obscure db results
paging. That is arguably one of the BIGGEST pain-in-the-ass chores there is
as well as an oft-used construct. Surely there could be a better way. ;)
> I have thought about ports a subset of the standard JSP taglibs
> for similar effect so we can have a nice default tag library
> to work with too, but have some namespace issues to work though first.
Hmm- thanks for the clue, I will go research them and bone up. Wasn't aware
there was some sort of standard developing.
> >>One thing to note that is NOT mentioned on the ASP site-- apparently the
> >>parsing algorithm doesn't know how to handle values that are NOT enclosed
> >>in quotes. Html does not require quotes as long as the value contains no
> >>spaces and only alphanumeric characters. You can't do that here. The
> >> other thing to point out is that any perl variables (eg. $myvar) are NOT
> >> escaped in the usual apache::asp way, (<%=$myvar%>) but instead are just
> >> simply passed between the quotes. Personally I think this is an
> >> inconsistancy, and
>
> In Apache::ASP v3.0 ( & 2.9xx betas ), there will be the default
> syntax of <my:sub arg1="<%= $var %>" /> instead of the <my:sub arg1="$var"
> /> today.
Is there any way to handle the "quotes-not-required" bit? (Probably not, but
asking anyway ;)
Its only a minor annoyance to me personally (and is always good for a santyx
error when I go to run the code ;) But my real concern-- and none of the
above really has anything to do with it, since use of the <% %> tags is the
real issue-- is that if an end-user (someone who is allowed to make html
pages using custom tags, etc) is really savvy and perceptive, they could
fathom out some of the inner workings of the apache/perl engine and
application environment and there is a potential security issue in all this.
Since any legal perl code can be operated between <% %> tags, a
suitably-mischievous person could potentially access, (ab)use, or hijack some
portion of the system (that the apache server process has permissions for).
If you (the programmer/webmaster) keep complete control over the pages you're
safe, but you can't safely share it with a unknown (eg non-trusted) user, and
this is a real shame because the potential for giving the end-user some
really nifty items is there (as well as a mechanism for obscuring nasty or
complex code/issues.
On the other hand, the opportunities for mischief are greatly diminished if
only through obscurity-- the end-user isn't likely to have access to the
source code of my application nor knowledge of the intimate data structures
necessary to do a lot of damage to the application directly-- though I myself
have been known to enage in some "perceptive spleunking" from time-to-time.
You never know what you can dredge up that way ;)
>To retain backward compatibility, there will be an
> XMLSubsPerlArgs config that can be set to activate the old method for
> backwards compatibility.
I think the new method will be a nice change-- a move toward a more
consistent, and therefore intuitive, interface.
> Other big things will happen in 3.0 like UseStrict becoming default,
> which is why 3.0 will be the release for them. I have already code forked
> off the 2.xx branch internally from 3.0 so I can keep doing fixes there
> separate from the bigger changes in 3.0.
>
> Thanks for sharing that interesting code sample.
Not a problem. I plan on sharing some more as time permits.
Now I have a question for you... ever since I first started programming ASP
projects I have been trying to fathom how to use the "default module" that
goes along with a project?? Its sorta seems like a dingleberry but I've
always included it mostly out of habit but partly for not knowing better.
Lately I've been looking through it with a more critical view and I just
can't see how its relevant. It appears to be just setting up for some
hypothetical module that might be created, perhaps to run CGI-ish code.
ex.
#! /bin/perl
package WIZORG;
use File::Basename;
sub new {
my($request) = $main::Request;
my($env) = $request->ServerVariables();
my $basename = &File::Basename::basename($0);
my($title) = join(': ', "WIZORG", $basename);
my($self) = bless {
bgcolor => white,
env => $env,
title => $title,
file => $basename
};
$self;
}
1;
So... Is it safe to junk it or have I missed a core concept?
John
-
--------------------------------------------------------------------------------
Check out http://www.Wizard.Org for great deals on Electronic Parts
*NEW* Computer Parts & Accessories - Drives - LCD - Systems - Linux
--------------------------------------------------------------------------------
** Affordable Online Store w/Merchant Card Processing & Paypal **
Write to us: [EMAIL PROTECTED] -- Get your Store Online Today!
--------------------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
