> It be a plugin, but I think the definition of a standard API for this
> belongs in the core. Since we are talking about a single (5 line? )
> optional method, I think it's reasonable to add there. It can still be
> ignored or overridden if you choose.
Fair enough. Having it built in would basically make it into a no-op, I
guess. It would mean that plugins could always call ->config without
fear of 'method not found'.
> > * need a clean way of dealing with config formats that don't support
> > hierarchical data structures.
>
> I see that happening like this: The session plugin declares:
>
> "You can configure me through your config file if you use one of the
> plugins that is powerful enough to support hierarchical data structures.
> Otherwise, configure me manually."
>
> In other words, if you want to stick with a less powerful config file
> system, you aren't any worse off than you are now.
Good point. And maybe someone can eventually write a config plugin that
overcomes this limitation if they really feel motivated to do so.
> > But if the app is running under PAR, then maybe 'root_dir' is in
> > some magical faraway place under $ENV{'PAR_TMP'}, and maybe the
> > exact directory name isn't known until runtime. In this case, the
> > system could allow the PAR plugin to override this single
> > parameter only.
>
> I want CGI::Apps to eventually have something like 'mark par'. Part of
> 'mark par' conuld involve altering the configuration to adjust this.
> Exactly how...I'll leave to someone else.
Yeah, I want that feature too! One of the main barriers IMO is making
C::A-based apps relocatable - i.e. they don't care where in the
filesystem they run from. I'd even be in favour of first class
methods for this purpose, if people would use them:
my $root = $self->root_dir;
my $uri = $self->root_uri;
my $path = $self->relpath('foo/bar/baz');
Maybe a CAP::Relpath plugin that CAP::PAR could depend on :)
Anyway, someone can correct me if I've got the details wrong, but I
think that when a PAR file is first run, it creates a randomly named
directory in either /tmp or the user's home dir. Into this directory it
unpacks all of its modules, scripts and datafiles.
So at the time when you package up the app, this directory doesn't
actually exist yet, so you can't edit the config files to point to it.
It would have to be done via a config plugin that computes a value for
'root_dir' based on the runtime value of $ENV{'PAR_TMP'}.
Michael
---
Michael Graham <[EMAIL PROTECTED]>
---------------------------------------------------------------------
Web Archive: http://www.mail-archive.com/[email protected]/
http://marc.theaimsgroup.com/?l=cgiapp&r=1&w=2
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
