Re: Dumping some ideas on views

[Diwaker Gupta <di...@apache.org>]

(some of the comments here might not be specific to views and encroach into 
other areas of Forrest)

Experiences as a user
=====================

Let me first talk a little about my user experience of views so far:

o Its *really* easy to write up new contracts and design your views

o Its still quite frustrating that a "single view" has to touch so many files 
-- default.fv, default.css, any private contracts that you might want to add 
-- these live in different directories, have different extensions and so on. 

<aside>
This is a problem I've had with Forrest in general. I understand that its good 
to have multiple possible locations for a resource, but there should be ONE 
recommended, unambiguous, default location for each type of resource. Take 
project images for instance -- they can live in site/content/xdocs/images or 
in site/resources/images. Both work just as well.

I still have to dive deep into locationmap, but looks like some/most of these 
problems would/should go away with locationmaps
</aside>

o I don't like the strong coupling between a view and the CSS (I know the 
implementation doesn't impose any such coupling, I'm just talking about how 
we intend to package and promote views). In my mind, a view gives the 
structure of your output. The CSS just skins it. I might want to preserve the 
same structure, but would still like to have the option to choose different 
skins for my view.

Alright, now let me get back to Ross's email:

> Templates as Individual View Plugin
> ===================================
> 
> I would like to see a new type of plugin that is a single template. A
> view plugin will then consist of a default *.fv file and a set of
> support files (such as CSS). The *.fv file describes which templates
> should be used. Forrest will download these templates as and when needed
> (as with plugins).

I think the functionality of "views" should move into the Forrest core -- 
meaning that it should just enable the use of views (and not provide 
implementations).

Then, I think we should build up a publicly available repository of the 
following:

o contracts
o views
o skins

contracts: As a very crude analogy, think of these as "components" in a portal 
or "thinggies" that you add to your "My Yahoo!" page for instance. People can 
submit and pull in contracts from the repository to mix and match as they 
please

views: these are just aggregates of contracts that people have come up with.

skins: these are just CSSes to render the views. Note that a skin may not be 
able to provide CSS rules for all contracts in the repository.

The purpose of this public repository is to encourage the use of views -- the 
more reusable components people have, and the easier we make it for them to 
modify, customize and use them on their own, the better it will be for views.

Of course, to get started, Forrest should ship with a default "look-and-feel" 
package -- consisting of a default set of contracts, a default view and a 
default CSS.

> These views will be able to take a configuration saying what format we
> want the output in (XHTML, FO, PDF, Text, POD, VoiceXML etc.) and will
> select the correct type of templates accordingly:

I'm sure this is a good point looking forward, but frankly speaking, I don't 
know how much sense it makes to write views for other formats. For example, 
what is a use case for using views in the text format? Things like menus and 
tabs and credits and compliance links and fontsizing etc don't make a lot of 
sense with text. People may argue that they are applicable to PDF, but I 
can't envision myself writing custom views for PDFs.

> Does it make sense to lump all the output formats together into a single
> view or should it be:
> 
> org.apache.forrest.output.xhtml.Pelt
> org.apache.forrest.output.pdf.Pelt
> org.apache.forrest.output.text.Pelt
> org.apache.forrest.output.voiceXML.Pelt

Relates to what I've said above. Just my 2c. I mean, what does "Pelt" for text 
mean? Or for PDF? When I use a name such as "Pelt" internally the immediate 
picture that I get in my head is of the XHTML rendition. I can't translate 
that in any meaningful way to text or PDF. Which is why I think its important 
to decouple views (structure) from skins (presentation).

> It looks to me like views are an ideal opportunity for us to switch to a
> subest of XHTML2 as our internal format. We are going to mess with the
> internals of Forrest in order to get the views stuff in there.

I agree. I'm all for moving to XHTML2 as soon as possible :)

> But what, exactly, is involved?

o input plugins for doc-v13 and doc-v20 formats
o rewriting/refactoring of views/skins
o lots of other things I'm just beginning to explore :)

Diwaker
-- 
Web/Blog/Gallery: http://floatingsun.net