forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thorsten Scherler <thors...@apache.org>
Subject [RT] forrest:templates practical experience
Date Sun, 30 Jan 2005 21:49:28 GMT
Hello devs,

actually I got the chance @work to work with forrest:templates or better
forrest:view. I have created an Adobe Indesign Exchange Format (*.inx)
forrest output plugin. BTW I just love forrest plugins, awesome work
that you have done McPlugin. ;-)

ATM I am sadly not able to release it to forrest because the client
wants to save his investment for a while. It is one of the first
solutions (if not *the first*) that is able to create serversided
INX-documents.

Anyway, I actually used forrest:view's as controller files for the
output. Besides that I am using an indesign template from the designer
and user data as content.

- designer -> Indesign templates
- programmer -> forrest:view
- user -> content

The user content is xhtml, the rest pure xml. For indesign the
forrest:view is pretty straight forward. The forrest:view is matching
the hooks in inx to the user-specific elements. I am using
hooks/nuggets/fbits like following.

<forrest:hooks />
In inx I have till now two kinds of hooks. @name="sprd" and
@name="page". An inx document can contain more then one page in one
slide (sprd). To make it possible to look up user-data objects (which
have been stored in a paged structure) one have to use "page". Static
forrest:nuggets can be be direct sons from "sprd" where semi-dynamic
content should be stored in a "page". 

REMARK: In INX I do not really need the hooks. This is totally different
in xhtml, where I heavily depend on hooks.

FURTHER REMARK: In xhtml the differents between nuggets and fbits is not
really practical, in INX it is. In the fbits plugin (that we should
rename to 'contracts') I am focussing for now just on html and I would
rather call nuggets and fbits 'contracts' then trying to seperate them.
This is because the processing for both are not different. 

Now trying to divide the contracts I am using in the fbits plugin for
inx I came up with the following definitions for nuggets and fbits. In
inx there is a different processing.

<forrest:nuggets />
This is content which is static or semi-dynamic. Semi dymanic means that
the actual content is user specific but the inx element location is fix.
A forrest:nugget for inx can have @type="static|txt|img".

<forrest:fbits />
If I want to configure absolute dynamic data in the inx output I am
using forrest:fbits. This are advanced customizable functions and
methods that will inject the user data. Now the element location as well
depends on user data. This fbits are controlled by a forrest:view to
tell the plugin which nuggets are used in the fbit.

I reckon in fo it will be more or less the same usecase with similar
definitions. Bottom line is that the forrest:view can be seen as format
independend controller file for the different output formats.
-- 
thorsten

"Together we stand, divided we fall!" 
Hey you (Pink Floyd)


Mime
View raw message