Re: New option: BASEHREF

[Mark Woon <morpheus@SMI.Stanford.EDU>]

Earl Hood wrote:

> On March 26, 2002 at 23:58, Mark Woon wrote:
>
> > I recently started using MHonArc, and am pretty pleased with the results
> > so far.  Unfortunately, because of my setup, I cannot use relative
> > links, and need to be able to prepend something before all href's.  To
> > do this, I added a new option, BASEHREF (-basehref), to MHonArc.
>
> Just curious, but what is it about your setup that prevents
> you from using relative URLs?  It is generally good practice to
> use relative URLs since it make data more relocatable.

I know.  However, we have a dynamic JSP site template that all pages must
use.  In order to plug the HTML pages generated by MHonArc into our
templates, I'm changing all href's to read something like
/mhonarc.jsp?pg=maillist.html instead of just mailist.html.  The JSP then
serves the MHonArc-generated page between the header and footer.  This makes
it a lot easier to make template changes without having MHonArc regenerate
all the pages.


> > For example, if BASEHREF is set to "/this/directory/", any time MHonArc
> > is about to print <a href="somefile.html">, it prints <a
> > href="/this/directory/somefile.html"> instead.
>
> For cases excluding the mimefilters, you can do this by customizing
> the page layout resources.

I'm not sure what you mean by this?


> > Is anyone else interested in this?  If so, I can send patches. I'd love
> > to see this folded into the official distribution so I won't have to
> > path this every time MHonArc gets updated.
>
> Wrt resource variable expansion, there will be ambiguities on when
> BASEHREF should be added to the expanded value.  For example,
> should $MSG$ include BASEHREF or not?

Why wouldn't it?  Basically, any time a MHonArc would generate an href, it
should prepend the BASEHREF.

The only exception I've found so far is when dealing with attachments, and my
current solution is to add an ATBASEHREF parameter.  This is because
attachments don't need to be templatized.  I'm guessing this is a hack, as
I should really figure out how the filters get their parameters (eg. iconurl)
and pass this through that way.


> I am initially cautious to the enhancement request; I must evaluate the
> maintenence impacts and to know if your reason for the feature is a
> unique case.

Understood.  I don't think that this will be used by the majority of MHonArc
users, based on how I see it being used on the web.  However, I don't think
my changes would break anything.  If you don't specify these parameters,
everything works the way it did before.

I see that getting MHonArc into CVS is on the TODO list.  If this doesn't get
incorporated into MHonArc, it would be great if I could get the code via CVS,
instead of a tarball.  It would make upgrading a whole lot easier...

Thanks,
-Mark