-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Resending to the list... (replying at the bottom)
<off-topic>
People, please try to keep discussions on the list, for all HM's users
benefit ;-)
Could some mailing list administrator configure this list to properly
modify/add a Reply-To header? It would be a great help for our lazy
behinds. ;-)
I'm having a hard time too to getting used with GUI based MUAs but I'm
trying (to always hit the "reply to all" button - as Ctrl-Shift-R will
NEVER-EVER get under my skin - Mozilla Thunderbird here) ;-)
</off-topic>
<message>
Allen S. Rout wrote:
> Marius Feraru <[EMAIL PROTECTED]> writes:
>
> [...]
>
> OK, so I'm on basically the right track, and shouldn't quail at
> absolute pathing. But you've left me with a confused impression about
> one thing: You recommend
>
>> comp_root => [
>> [ private => $r->document_root ],
>> [ shared => $SharedComps ],
>> ],
>
> but also
>
>> Don't even think about using some separate comp_root for your
>> taglib (like: [ taglib => $TagLibDir ] ). It's just a clear case
>> of shooting yourself in the foot:
>
> Is the difference between these cases simply the subdirectory of
> shared?
>
>
> I've also got a few other questions:
>
>> - overriding a taglib component will become a mess
>
> Do you mean that it would be hard to override a taglib component
> (which I don't get) or that it would be unfortunately easy to do so,
> since all the comp_roots share the same namespace?
>
>> - no _clean_ way to protect direct calls to taglib comps
>> - more comp_roots, more component resolving time
>
> How much does the performance suffer? I see it globs all the
> comp_roots on each lookup, but from your experience is that a large
> efficiency hit?
>
>> - ... (TMTE, I could talk about this all day long, but for now,
>> saying that I'm heavily using HM for more than 5 years should
>> be enough)
>
> Heh. Can you also expand 'TMTE' ? :)
>
> Thanks for your help.
>
> - Allen S. Rout
</message>
> OK, so I'm on basically the right track
for sure.
>> Don't even think about using some separate comp_root for your
>> taglib (like: [ taglib => $TagLibDir ] ). It's just a clear case
>> of shooting yourself in the foot:
>
> Is the difference between these cases simply the subdirectory of
> shared?
Let me rephrase:
Don't even think about using some separate comp_root for your
taglib _only_
Let's use the power of (bad) examples by figuring out an hypothetic
scenario. First, the file-system:
/www
|- /vhosts
| |- /www1
| |- /www2
| |- /www3
| |- /www4
| |- ...
|- /shared
|- /taglib
Next, the HM objects:
my @shared_comp_dirs = (
[ taglib => '/www/taglib' ],
[ shared => '/www/shared' ],
);
...
my $HM;
...
$HM->{$siteID} = MyApacheHandler->new(
...
comp_root => [
[ private => $r->document_root ],
@shared_comp_dirs
],
...
) or ...;
And now we're developing (starting from www1, OFC) :)
We're happily crafting private components (in '/www/vhosts/www1')
making use of the bright taglib components (in '/www/taglib').
Next, we'll move on to www2. At some point we'll see that we have to
bake the same cookies as in www1 (let's say a 'list' component), so it's
time for refactoring. OK, let's move it to 'taglib'. Oops, cannot do
that, there's already a 'list' widget in 'taglib'! No problem, let's
make use of 'shared' comp_root. Oops again, you'll never see it (as
taglib's 'list' has higher priority). Changing priority? No way, then
you'll lose taglib's 'list' widget (behind shared's one).
Then what? Either accept the bad design and keep on duplicating each
component inside the 'private' comp_root, or call a higher ranked mage
to help you tricking HM around (HM's wiki and this mailing list's
archives will help you on that - but please don't :)
Need more rant? There's an easy way out: develop like in PHP -
everything behind the /index.php (?page=...., etc) ;-)
OK, back to the 'list' component. Let's say you woke up and decided to
raise the priority of 'shared' (comparing to 'taglib') and solved the
problem, because you remembered that 'taglib' is in fact (to be)
protected from direct client access and, after all, your 'list' was
really supposed to be accessed like that :))
Next you'll want to override some taglib widgets. OK, let's crowd the
private space with lots of 'fooooooter', 'heaaaader', 'seleeeeeect',
'griiiiid' components :(
OK, you've done your job, you cleanly documented your design and
architecture and moved on to better lands. You left behind an army of
maybe-not-so-bright techies who are supposed to support those "sites".
In some component they see (and want to modify):
<h1><& /page/title &></h1>
Visually compare it now with:
<h1><& /TAGLIB/page/title &></h1>
Which one do you presume is taking more seconds to reckon? :)
And yes, I know
ls /www/{vhosts/www1,taglib}/page/title
sounds simple for you ;-)
This message is a mess, so let's repeat one thing: component names
clashes :))
>> - overriding a taglib component will become a mess
> Do you mean that it would be hard to override a taglib component
> (which I don't get) or that it would be unfortunately easy to do so,
> since all the comp_roots share the same namespace?
I answered already to this one too, but let's repeat it: you have a
'header' widget in taglib. Now there's some site where you really need
to change that 'header' for whatever purpose, so you create a component
with the same name inside your 'private' comp_root. Simple, but very
cluttering.
>> - more comp_roots, more component resolving time
> How much does the performance suffer? I see it globs all the
> comp_roots on each lookup, but from your experience is that a large
> efficiency hit?
No. At least not usually. But I had a case a few years ago (I don't
remember the exact details) where the development settlement was
lightning fast comparing with the production just because of that (two -
or something - more comp_roots). After recoupling everything together
back in just two comp_roots, everything went back to normal.
> Heh. Can you also expand 'TMTE' ? :)
Hehe, did I jump enough? :)
Anyway, as Dave said some time ago, people should get into this boat and
help each one out figuring more about these issues:
On Fri, 13 Jan 2006, Dave Rolsky wrote:
> On Thu, 12 Jan 2006, Dave Mabe wrote:
>> Any best practices out there for Mason?
> There have been threads along these lines on the Mason-users list at
> various times. I wrote a chapter in the Mason book that touches on
> some similar topics, which is available at
> http://www.masonbook.com/book/chapter-10.mhtml
>
> There's also this page on MasonHQ:
> http://www.masonhq.com/?MasonStyleGuide,
> which I created a long time ago.
> I was hoping others would add to it, but AFAICT that hasn't happened.
> I'd love to get more ideas onto that page in particular.
(This was on PBP list, no one replied, silence all the way) :/
(Oh, heck, I'm already getting over-bored. You too. Sorry, I'm not much
of a writer/talker, usually I'm the one who's reading/listening) ;-)
I'm sure you lost me already. Unluckily, that's the obvious dead-end.
I highly recommend getting a copy of "Embedding Perl in HTML with
Mason", Dave and Ken did a way better job in explaining how's the wheel
spinning. Ah, it's also available on-line at masonbook.com. ;-)
Dave keeps updating it in secret. One example:
" This book was written before MasonX::WebApp and
MasonX::Interp::WithCallbacks were available or widely used.
Both of these were written to make it easier to move application
logic out of components into modules.
"
(http://masonbook.com/book/chapter-10.mhtml)
Should I also mention HTML::Mason::Plugin besides those two? :))
OK, enough delirium for today/this_year. It's Saturday! Let's get back
to books/tv/beer/etc. ;-)
Cheers
- --
Marius Feraru
-----BEGIN PGP SIGNATURE-----
iD8DBQFD7iGgtZHp/AYZiNkRAsONAKDWHpiY5ME1qQhueYkbYGQMlX1TZQCeL3Uh
6AsMzOorN/33wTtLL+nH3r4=
=B6RE
-----END PGP SIGNATURE-----
smime.p7s
Description: S/MIME Cryptographic Signature
