On Sat, 2005-07-16 at 00:54 -0700, Diwaker Gupta wrote:
> (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
>
Yes, forrest:views tries to follow this simplicity paradigm.
> 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.
>
That is the enabler right now. Do you have an idea to keep the same
flexibility and maintainment behavior?
I talked with Antonio and would it be better to keep everything in the
document? His usecase was about meta-data and that made me think.
I still have to finish the rename proposal and I hope we can harmonize
some things with this.
> <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>
>
Yes, the basic idea is to harmonize the recommended (fresh-site)
structure and still let the user easily override this with the
locationmap.
> 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.
>
That is the idea of having a rep for forrest:views, forrest:contracts
and css-skins (for specific forrest:views).
IMO forrest:views and css-skins *are* coupled in a way [cp. 1].
"Presentation
...
Contrary to what you might be thinking, this isn’t limited to just the
CSS, not even on a site like CSS Zen Garden. It also involves HTML tags
and properties that exist only to provide a handle for the designer to
apply styles to. After all, what use is a .pageheader {…} declaration
block if there is no element with that class on the page?"[1]
forrest:views can provide the html tags for a CSS Zen Garden page. In
other word it would provide the basic structure for the page. Then you
can use all css-skins that Zen provides for a forrest site rendered with
the zen-garden.fv.
The forrest:view is providing the structure for the presentation.
"Presentation and structure
As we have seen, without structural elements, there is no way to apply
styling to the content. Structure cannot be separate from presentation —
nor should it be." [1]
> 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).
>
I am not sure about that anymore. Maybe it is better to first develop
everything in plugins and then use the upcoming cocoon blocks to unite
the work. This way it is easier to reuse forrest:views as a single
component in *any* cocoon based application.
> 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
>
Yes, that is as well my vision.
> views: these are just aggregates of contracts that people have come up with.
>
see above. IMO they are more because of "Presentation and
structure" [1].
> 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.
>
...nor for all views.
skins can support one or more forrest:views. Imagine we will create a
zen-garden.fv in the future. Then we have all css from Zen supporting
this forrest:view but our default.css and pelt.css will not work
anymore.
skins can support certain views and contracts.
> 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.
>
...and for the forrest user. :) As soon as the skinbot is coming that
will be hopefully drag and drop.
> 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.
>
I would limit those to e.g. the pelt view that is Cyriaque developing.
That are the actual contracts that forrest is using for its site. On the
other hand I would like to keep our default.fv as leather.fv.
I started views when developing leather-dev like you know. I would like
that the default.fv will become leather.fv.
> > 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.
>
You would write them for fo and not for PDF. ;-)
You ask for the usecase for views in text format? Maybe that is not the
best example but consider a cellular phone and a normal browser. The
phone will need a different view because it has to render the
information in a different format. Another usecase is the brand new
voice output.
Consider what I said in the other mail:
The basic idea is that forrest:views will be a dispatcher config for
1) including data to the presentation model
2) generating dynamic presentation
> > 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).
>
Pelt *could* provide a config for all this formats but it do not have
to.
> > ...
> Diwaker
[1] http://www.alistapart.com/articles/separationdilemma/
--
thorsten
"Together we stand, divided we fall!"
Hey you (Pink Floyd)
