On March 27, 2002 at 16:18, Mark Woon wrote:
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.
Why not make MHonArc generate jsp pages directly and then use the
include mechanism of the Java Servlet/JSP API to include your standard
header and footers? MHonArc has resources to change the filename
extensions of the files it generates. For example, instead of
generating maillist.html, you generate maillist.jsp. In the page
layout resources, you add JSP include mechanisms to include your header
and footer.
We have one user that does something like this, but with PHP.
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?
Take the following template mhonarc invocation:
% mhonarc -definevar 'BASE-HREF=/.../' ...
Then in your resource file, you do something like:
<LiTemplate>
<li><strong><a $A_NAME$ href="$BASE-HREF$$MSG$">$SUBJECTNA$</a></strong>
<ul><li><em>From</em>: $FROM$</li></ul>
</li>
</LiTemplate>
This way, you control where the base href is applied and no code changes
are needed.
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.
See above example for where you have problems. I.e. Many users
control how href's are generated by customizing the resource settings
and MHonArc has no direct control over this. Hence, they can use a
custom resource variable to get the effect of having a base href
applied.
Have a look at the documentation for the resource variables $SUBJECT$
and/or $A_ATTRS$. You will see that these are just convienence
variables that can be defined by other resource variables. For many
cases, users will role their own equivalenet of $SUBJECT$ or
$A_ATTRS$. In these role-your-own cases, mhonarc does not know
anything about any href attribute.
BTW, you have a problem where you may not want a base href to be
applied in all cases. The custom resource variable technique that I
have shown allows you to pick-and-choose how the base href is applied.
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.
My alternative solutions above will avoid attachment problems.
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.
I do not see adding a feature that can be already be solved with
existing mechanisms. I think what I have discussed above can solve
your problems.
--ewh
