MasonCompRoot and globs

T

Tim Watts

Hi,

Couldn't find this by searching... I'm a perl programmer, but trying
out Mason for the first time. Any Mason folk here?

[Posted to the Mason Users list but that looks almost dead]


I've got this in my Apache 2 config (ignore linewraps in email):

PerlAddVar MasonCompRoot
"html=>/vol/www/www.robertsbridge.org/html"
PerlAddVar MasonCompRoot
"liblocal=> /vol/www/www.robertsbridge.org/html/*/_mason"
PerlAddVar MasonCompRoot
"libglobal=>/vol/www/www.robertsbridge.org/_mason"

and it's not doing what I'd hoped...

What I want is:

--- /_test/_test.html ---
The value is: <& var.mas &>
-----

To search:

(docroot)/_test/_mason/
(docroot)/_mason/
/vol/www/www.robertsbridge.org/_mason

Look at the HTML::Mason::Resolver man page, I was under the impression
globs were allowed?

Or do I need to implement my own resolver?


On an aside, I'd like to access the resolver directly: eg, if I have a
menu.mas component that loads a menu.dat (a perl data structure), I'd
like to have it search in the current outermost component's directory
(eg the location of the .html file), then up a directory, then up until
it hits the DocumentRoot until it finds one.

Any tips on whether I can leverage Mason for this, or do I do it the
"hard" way in perl by making my own search routine?

Many thanks. So far very impressed with Mason :)

Cheers

Tim
 
T

Tim Watts

Hi,

Judging by the resounding lack of action re Mason here and on the MasonHQ
lists do I conclude that using Mason on a new project is a bad idea?

Is there something better that's solid?

Cheers

Tim
 
J

J. Gleixner

Tim said:
Hi,

Judging by the resounding lack of action re Mason here and on the MasonHQ
lists do I conclude that using Mason on a new project is a bad idea?

Post your question to the Mason mailing list. That will
go to the authors and to others who are very knowledgeable about
Mason.

I've done what you want to do using a simple component, going
up a directory at a time, looking for a certain file, but maybe
there's a better way that would be mentioned by the mailing list.

Maybe this will help you:

http://masonhq.com/?Component:Recurser

It's pretty simple to write what you want to do, if
it's not already available in Mason.
Is there something better that's solid?

Catalyst might be of interest. CGI::Application, Template Toolkit, etc.
 
T

Tim Watts

I'd give it some time before drawing any conclusions - there's less
than a day between this message and your previous one.

Yes. Though the lists are suspiciously quiet (20 messages / month is quiet).
Maybe I'm too impatient - I'm used to uk.d-i-y where you generally get
something in 30 minutes - in fact it's so chattery it's practically ICQ!
Further, the lack of response to your question may indicate something
entirely different - for example, although I've used Mason in several
sites and had no problems with it, I've never tried what you're trying
and don't have an answer for you.

I think I've found a way.

The HTML::Mason::Resolver does not have any knowledge[1] of who called it so
it cannot ascertain the source directory of any components that are
"calling" it. So doing what I thought isn't possible that way (I added some
Data::Dumper routines in to see what it "knew").

[1] Well, there must be knowledge in the process somewhere, but it's not
passed to the Resolver in a clean way.

However, the answer may be in the autohandler and attributes... It's
possible to have a chain of autohandlers which are called from the top
(shorter) of the path down to the path that the URL maps to. One can set a
default attr or attrs in the top level autohandler and override if required
going down which is basically the "right thing" (TM).

I'm looking at def's and methods too but haven't groked them yet.

He forgot:

6) No one knows the answer - quite common IMO to get null replies to such a
post *unless* someone else
Template Toolkit is popular too, but I'd hesitate to call either one
"better," since both have been reliable in my experience.

Mason seems solid. There's a fair bit I don't "get" yet, so I'm trying some
stuff in the MasonBook and reading the source where necessary.

I did my website in SSI (start simple I say). That's OK, but it's on the
limit and I'd like a slightly smarter templating system. And although I've
done some PHP I've not much liked it compared to perl.

Thanks for your post anyway :)

Cheers

Tim
 
T

Tim Watts

Post your question to the Mason mailing list. That will
go to the authors and to others who are very knowledgeable about
Mason.

Hi

I did that first - mason-users anyway.

That's a very low volume list of late which makes me suspicious. It either
means Mason is used by no one but experts who know everything already, or
it's used by noone full stop...
I've done what you want to do using a simple component, going
up a directory at a time, looking for a certain file, but maybe
there's a better way that would be mentioned by the mailing list.

Maybe this will help you:

http://masonhq.com/?Component:Recurser

It's pretty simple to write what you want to do, if
it's not already available in Mason.

Ah - I see. That's pretty neat - in fact it does what I want. I hadn't
thought to make a component as a wrapper to execute another component - I
was trying to hack Mason's guts to do that (and failing miserably!).
Catalyst might be of interest. CGI::Application, Template Toolkit, etc.

Name rings a bell. I should look at that now. I'm not committed to Mason,
I'm just looking for the next stage up from SSI to do my website.

Thanks for the post! :)

Cheers

Tim
 
T

Tim Watts


Hi,

Yes I found that most useful.

I rehacked a version that will do what I want (wit due credits to your
source in the comments which are snipped here for brevity).

Mine bases its search path relative to the request component as that's the
canonical search path for my application.

eg if I want a component called '_mason/wibble.mas' and the request uri was
/a/b/c/doobry.html

I want it to search

/a/b/c/_mason/wibble.mas
/a/b/_mason/wibble.mas
/a/_mason/wibble.mas
/_mason/wibble.mas

I kept the reverse, exec and collectall functionality as I could see that
being useful and the cost is minor (complexity and speed).

=========

<%perl>
# Cleanup the path
$name =~ s#/{2,}#/#g;

my @sdirs = split('/', $m->request_comp->dir_path);
my @paths = ();

while (@sdirs)
{
my $path = join('/', @sdirs) . '/';
if ($m->comp_exists($path . $name))
{
push @paths,$path . $name;
last if !$all;
}
pop @sdirs;
}
@paths = reverse @paths if $reverse;
if ($exec)
{
foreach my $comp (@paths)
{
$m->comp($comp);
}
}
else
{
scalar @paths > 1 ? return \@paths : return $path[0]
}
print join(':', @paths);
</%perl>

<%args>
$name
$exec => 1
$all => 0
$reverse => 0
</%args>

========================

Thanks again.
 
T

Tim Watts

Post your question to the Mason mailing list. That will
go to the authors and to others who are very knowledgeable about
Mason.

I've done what you want to do using a simple component, going
up a directory at a time, looking for a certain file, but maybe
there's a better way that would be mentioned by the mailing list.

Maybe this will help you:

http://masonhq.com/?Component:Recurser

It's pretty simple to write what you want to do, if
it's not already available in Mason.


Catalyst might be of interest. CGI::Application, Template Toolkit, etc.

Long term follow up:

I re jigged my recurser again (I should submit that to MasonHQ once I work
out how).

Anyway, re-did my web site in Mason - not hard. Most of the SSI "components"
were ripe for translating to Mason components.

Nearly every component is called via my recurser so overriding is trivial.

One other trick I did was I found the whole "OO" think in Mason to be
completely brain damaged, but the caching and syntax suger were very nice.

I allow .html to be handled without template wrapping, but if the file is
missing, the dhandler (default-no-file handler) will look for alternate file
endings in the same translated directory and then marry those with a
template wrapper.

eg: /index.html will actually call webroot/index.mhtml wrapped with
mhtml.tem.

Each module may have an init method (not an %init section - those didn't
work very well IMO) and the autohandler will call those in sequence:
template, then target. Those return hashed whose keys get merged into a
global hashref $g which the other components may call on.

This way I can have more than one template without filling the autohandler
with cruft.



In summary: Mason had a lot of good ideas, but didn't seem to implement some
of them very wisely (mostly the %attr, %init and all the inheritance stuff).
Fortunately it's solid enough to offer the flexibility to do what I did
cleanly and I'm very happy. It seems pretty quick too.

Cheers

Tim
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,904
Latest member
HealthyVisionsCBDPrice

Latest Threads

Top