forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ross Gardler <>
Subject Re: Forrest plugin
Date Wed, 06 Oct 2004 18:09:13 GMT
Clay Leeds wrote:
> On Oct 6, 2004, at 4:35 AM, Ross Gardler wrote:
>> Clay Leeds wrote:
>>> On Oct 5, 2004, at 3:54 PM, Clay Leeds wrote:
>>>> I'm interested. I've followed these instructions[1] and am a 
>>>> willing   participant. Please let me know what I need to do to move 
>>>> OOo  related  files to a plugin.
>> Do "forrest run" using the branch and you will find the start of the  
>> docs at http://localhost:8888/docs/plugins.html
> after doing a /forrest/, I got a BUILD FAILED with one error in the  
> processing:
> X [0]                                     docs/site:dtd-docs    BROKEN:  
> No pipeline matched request: docs/site:dtd-docs
> [..]
> /Users/Shared/_WebDLs/_repos/forrest/src/core/targets/site.xml:43: Java  
> returned: 1
> Total time: 6 minutes 27 seconds

There was a bug introduced a while back that caused this. It looks like 
I create the branch when that bug existed. I don't have the time to 
merge the changes in trunk into the branch right now. However, if you do 
a "forrest run" everything works fine.

>> When developing a plugin you can do so directly in the  
>> FORREST_HOME/plugins directory. We only need to package it for  
>> download once it is complete.
> I'll check it out. Do you have a "starter" zip of an OOo plugin to get  
> me started? I'd thought you mentioned you had something started, which  
> enabled one to use an .sxw file with embedded images.  
> Can you get me a copy of that?

No, I seem to have misled you, sorry. I have some enhancements to the 
OOo integration but it is using the existing system not the proposed 
plugin system. I was hoping that we could extract the existing 
functionality into a plugin and then add my enhancements.

If you would prefer you are welcome work the other way around and work 
my enhancements into the existing OOo stuff. When we extract the plugin 
it will come with it.

I'll open an issue and attach a zip of the files I have modified so you 
can get at them. However, you should be aware that these enhancements 
need merging with changes that have been made in the OOo stuff here in 
Forrest, there have been quite a few since I first made my changes so I 
am not sure how easy this will be. I don't expect it to be a hard job, 
but who nows what will turn up.

> To be honest, I don't even know which files will be necessary to build  
> the plugin. I assume they're the *openoffice* files (the below files  
> except openoffice-writer.sxw) but it would help to pare down the list:


> I'm thinking the plugin should have the following structure:
> OpenOffice/
> OpenOffice/openOffice.xmap
> OpenOffice/resources/stylesheets/openoffice-common2forrest.xsl
> OpenOffice/resources/stylesheets/openoffice-impress2forrest.xsl
> OpenOffice/resources/stylesheets/openoffice-writer2forrest.xsl
> OpenOffice/resources/stylesheets/aggregates/openoffice-writer.xml
> OpenOffice/resources/stylesheets/aggregates/openoffice-writer.xsl
> Is that correct?

Yes. Seems you already pared the list down quite nicely.

One small point, the xmap is called "sitemap.xmap" not "openOffice.xmap".

>> Yes, but don't worry about how we enable that right now, we'll 
>> package  it once it is working.
> I would think it would be included in the download, and only be used if  
> something matches .sxw...

What do you mean "the download"? The idea is the same as with custom 
skins, a config file will indicate what plugins are required to build a 
site (this does not exist as yet). When someone does "forrest *" one of 
the first actions of Forrest is to ensure it has the necessary plugins 
available. Any that are missing are automaticaly downloaded and installed.

The plugins are not included in the original Forrest download because 
not everyone needs them and not all plugins will be managed by the 
Forrest community.

>>> How would I go about 'shrinking' the files for the web page. Would 
>>> I   just specify a width/height (after somehow determining that an  
>>> image's  width and height are greater than one of those, apply the  
>>> appropriate  ratio)? Does forrest have some type of hook to a 
>>> program  that can read  images? Should I make it read and then shrink?
>> The problem here is that we don't know the size of the browsers  
>> display. I think we can discover it through Javascript, but not sure  
>> if we want to do that. However, assuming we solve that problem I  
>> imagine we can find/create a Cocoon Generator that will do the 
>> scaling  on the server side for us. First thing will be to get my 
>> simple (non  scaling) approach to work, then we can do as you suggest 
>> (browser  scales using height/width) then we'll do the clever stuff.
> Personally, I don't want my site to rely on Javascript for any  
> functionality. Not that I don't use it, I just don't like to use it for  
> what I deem to be 'critical' features

Yes, I would agree with you and I think most people here would too.

> This size should be configurable within  
> (IMHO) so that a web developer could specify  
> 1024x768 or larger even.

Yes, that sounds like a reasonable idea. So our XSL will scale the image 
according to the target screen size set in the properties file.

>> I'm really busy over the next couple of days, but I will have more  
>> time on Friday (I hope). I will do what I can with guidance via email  
>> until then.
> OK. But if you can get me your 'starter' stuff you've  
> started, that would help.

It's up to you where you want to start, either extracting the existing 
OOo code into a plugin or merging the changes I have made in the files I 
attach to the issue into the existing Forrest work.

>>> Once I have that working, would I have forrest cp   
>>> [the-embedded-image(s)] *.sxw/Pictures images/ (or ack!   
>>> ../../../resources/images/)
>> No copying involved, it extracts the images directly from the sxw  
>> archive. Once we have the OOo plugin working I'll put what I have 
>> into  it and we can go from there.
> But won't we need to generate the thumbnail/screenshot images? Those  
> will need to be generated, if not copied.

The image is read from the sx* archive using a Cocoon generator. All we 
need to do is make that generator scale the image accordingly (actually 
it may be the job of a Transformer rather than a generator). Cocoon 
itself will cache the results, we need not worry about copying it 
anywhere (at least this is how I *think* it works I'm no expert on 
Cocoons internals, so we'll have to check that out we get to this stage).


View raw message