Why resources/images? (Re: Foreign html + javascript links + .js file)

[Jeff Turner <je...@apache.org>]

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
> 

Re: Why resources/images? (Re: Foreign html + javascript links + .js file)

[Marc Portier <mp...@outerthought.org>]

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