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
