forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Portier <...@outerthought.org>
Subject Re: Why resources/images? (Re: Foreign html + javascript links + .js file)
Date Wed, 12 Mar 2003 20:49:09 GMT
coincidence: was solving a smaller thing on pass-through word 
docs today for a customer of us that started using forrest...

they can link ./diagram.gif  from an xdoc and just drop the image 
next to it

however they cannot do so with *.doc extended stuff

I'm all for removing differences between images and any other 
binary (non-processed) content, but *that* difference can maybe 
go along with it?

we might end up questioning why we keep holding onto the xdocs 
directory?


-marc=


Jeff Turner wrote:
> On Wed, Mar 12, 2003 at 11:53:24PM +1000, Peter B. West wrote:
> 
>>Jeff,
>>
>>Attached are the diffs of the changes I made to get the 
>>resources/scripts files to be picked up.
> 
> 
> I've never really understood the historical reason for 'resources' being
> different from 'content'.
> 
> Wouldn't it have the same effect to put these things in content/scripts?
> 
> IMHO, anything that gets served to the user is 'content', and anything
> that helps produce content (XSLT, DTDs, catalog files) are 'resources'.
> 
> But this is not the original plan, or we wouldn't have resources/images/
> 
> So a question for everyone: are there any reasons for resources/images/,
> or can we deprecate it in favour of content/images/?
> 
> 
>>I also had a lot of fun trying to work out why some of my .ehtml files
>>would be recognised, while others generated empty files.  The
>>difference turned out to be that the <HTML/> tags were upper case.
> 
> 
> :/  Well we could turn on JTidy when parsing *.ehtml.  Simply a matter of
> changing:
> 
> <map:generate src="content/xdocs/{../1}.ehtml"/>
> 
> to
> 
> <map:generate type="html" src="content/xdocs/{../1}.ehtml"/>
> 
> However I found that JTidy doesn't like/expect input to contain the <?xml
> version="1.0"?> XML declaration, so it would break backwards-compat.
> JTidy is generally yucky - wish someone would add support for NekoHTML.
> 
> --Jeff
> 
> 
>>Peter
>>
> 
> 

-- 
Marc Portier                            http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at              http://radio.weblogs.com/0116284/
mpo@outerthought.org                              mpo@apache.org


Mime
View raw message