On Sun, 2005-07-31 at 00:31 +0100, Ross Gardler wrote:
> [NOTE: this is my summary of my interpretation of *part* of the
> discussion at the views workshop at Apachecon. In other words I have
> tried to represent the views of those present, but may have got some
> bits wrong - this is a document for discussion not a final document.
>
> You can get the audio from that workshop at
> http://svn.apache.org/viewcvs.cgi/forrest/events/apachecon-eu-2005/workshop.ogg?rev=225666&view=log
>
> ]
>
> What *is* a forrest:view?
> -------------------------
>
> Some of the confusion over Views seems to have come about because they
> do much more than just replace skins. They add a whole new feature
> set.
> We therefore decided to define some terminology to help clarify the
> situation.
>
[NOTE: I have cut and modified parts of original mails from Ross,
Ferdinand and David to fit them in my explanations. Thanks for this
excellent work! The summary of this mails describes forrest:views in
very detail, I actually just collected the pieces and added some more
explanations about the pattern they follow]
[NOTE: I changed forrest:view(s) when referring to the DSL and used
forrest:structurer instead]
[NOTE: You should read [1]-[5] before reading this mail that will help
to understand what problems forrest:views is trying to solve and the
proposed implementation for a solution]
What *is* forrest:views (f:v)?
************************
forrest:views is the codename for a forrest based implementation of the
Core J2EE Pattern - Dispatcher View [1]. The following explanation is
from [1] with their equivalent implementation in forrest:views.
Problems which we have with old fashion skins (html)
****************************************************
The problem is a combination of the problems solved by the Front
Controller and View Helper patterns in the presentation tier. There is
no centralized component for managing access control, content retrieval
or view management, and there is duplicate control code scattered
throughout various views. Additionally, business logic and presentation
formatting logic are intermingled within these views, making the system
less flexible, less reusable, and generally less resilient to change.
In our case an old fashion skin are build by 4 different view helper
(book2menu.xsl, document2html.xsl, site2xhtml.xsl and tab2menu.xsl). In
this different files we have typically non modularized presentation
formatting logic. Which makes it hard to reuse certain components in a
flexible way. Some recent usecases wanted e.g. to generate a certain
menu independent from our site.xml. Till now the menu is produced by
book2menu.xsl, if you want to override it you need to create a new skin.
The following limitations described by Ferdinand apply to this
stylesheet.
On Mon, 2005-09-05 at 09:47 +0200, Ferdinand Soethe wrote:
> - structure of site:
>
> The structure of the complete site and the position of a document
> within it. This is currently defined by the grammar and limitations
> of
> site.xml and implemented by the author or editor assembling a site
> from different data sources.
Solution
*********
Combine a controller and dispatcher with views and helpers to handle
client requests and prepare a dynamic presentation as the response.
Controllers do not delegate content retrieval to helpers, because these
activities are deferred to the time of view processing. A dispatcher is
responsible for view management and navigation and can be encapsulated
either within a controller, a view, or a separate component.
Our basic prototype (codename: forrest:views) is implementing the
following components to achieve above written.
dispatcher - match="prepare.view.**"
**********************************
The dispatcher is ATM within the internal.xmap of the internal.view
plugin (i.v-p). The match="prepare.view.**" is responsible to dispatch
the right view to process for the current request.
view - default.fv
*****************
A view represents and displays information to the client. The
information that is used in a display is retrieved from a model. Helpers
(forrest:contracts, forrest:hooks and forrest:properties) support views
by encapsulating and adapting a model for use in a display.
helper - forrest:contracts, forrest:hooks and forrest:properties
*****************************************************************
A helper is responsible for helping a view or controller complete its
processing. Thus, helpers have numerous responsibilities, including
gathering data required by the view (done by forrest:properties) and
storing this intermediate model, in which case the helper is sometimes
referred to as a value bean. Additionally, helpers may adapt this data
model for use by the view (done by forrest:contracts). Helpers can
service requests for data from the view by simply providing access to
the raw data or by formatting the data as Web content.
businessService - input plugins
********************************
The business service is a role that is fulfilled by the service the
client is seeking to access. Typically, the business service is accessed
via a business delegate. The business delegate's role is to provide
control and protection for the business service (see "Business Delegate"
on page 248).
Processing pipeline
*******************
> Currently our processing pipeline looks something like this:
>
> src -> input plugins -> core -> skinning -> output plugins. -> out
>
> Both skinning and output plugins are optional, so we could do any of
> the
> following processes when working on, for example and OOo document:
>
> OOo -> OOo plugin -> core -> skinning (html) -> HTML
>
> or
>
> OOo -> OOo plugin -> core -> skinning (FO) -> output plugins -> PDF
>
> or
>
> OOo -> OOo plugin -> core -> output plugins -> TEXT
>
> Views currently only produce HTML and the process looks like this (at
> least I think it does ;-)):
>
> OOo -> OOo plugin -> core (views) -> HTML
> We can see that forrest:views remove the skinning system. But what
> about
> the look and feel of the page. A view does not provide that. When
> forrest:views output XHTML we use CSS for the look and feel:
>
>
> CSS
> |
> \|/
> OOo -> OOo plugin -> core (views) -> HTML
>
> =======================================================
> Themes are the look and feel of a forrest output format
> =======================================================
>
...
forrest:structurer
******************
On Mon, 2005-09-05 at 09:47 +0200, Ferdinand Soethe wrote:
> The structuring of the assembled page where all content is in place
> and structured with
forrest:hooks to provide hooks for theming.
On Sun, 2005-07-31 at 00:31 +0100, Ross Gardler wrote:
> In order to enable themes to consist of nothing more than Look and
> Feel
> configurations there needs to be some structure to the document that
> allows the theme designer to correctly apply the theme to the output
> generated by Forrest.
It is the job of a forrest:structurer to define this structure. The
structurer uses for this a couple of helper classes forrest:contracts,
forrest:hooks and forrest:properties. But there is more to a
forrest:structurer than just structure.
The structurer is not limited to a documents but can aggregate,
structure and contact from multiple input sources. Far more actually
because it provides logical conditions for presentation formatting logic
(to be implemented by basing the structurer on jxTemplates).
> Sometimes the structurer defines content that should be aggregated
> with the source
> file. For example it may define the copyright information, a search
> box
> or even some dynamic content, such as an RSS feed.
On Fri, 2005-08-19 at 04:27 +1000, David Crossley wrote:
> The name "structurer" still works, this time as a doing word
> The structurer needs to marshall the content to help it
> to build the structure.
The combination of forrest:contracts and forrest:properties allows this
aggregation of different input sources.
> So now we have:
>
>
> theme
> |
> \|/
> OOo -> OOo plugin -> core (views) -> HTML
> | /|\
> \|/ |
> forrest:contracts
forrest:properties
> Here the forrest:contracts define the templated content that should
> be
> inserted into the final document.
A contract can use forrest:properties to:
> These may create a new request in
> order to generate the content, such as an RSS feed, or they may
> insert
> statically defined content, such as a copyright notice.
>
> Now, we need to be able to re-introduce different output formats, so
> the
> final processing for views looks like this:
Actually the following graphic is not the original one because the
contracts as viewHelper should come *from* the output plugin.
forrest:contracts are basically xsl:templates which adapt and transforms
the presentation model to the final output.
theme
|
\|/
src -> input plugin -> core (views) -> output plugin -> output
/|\ | /|\
| \|/ |
+------------------+
|forrest:contracts |
|forrest:properties|
+------------------+
forrest:structurer
> ....
>
> forrest:structurer add a structure to the generated page that
> clearly identifies all the content in the final output. This is
> achieved through the use of
forrest:hooks. forrest:hooks is a concept of defining format independent
hooks to structure the output. In xhtml this hooks a transformed into
<span/>s and <div/>s. For example:
<forrest:hook name="testIdDiv"/>
*or*
<forrest:hook name="testIdDiv" type="div"/>
will be transformed into
<div name="testIdDiv" />
The same is true for @class attribute for forrest:hooks.
<forrest:hook class="testClassDiv"/>
*or*
<forrest:hook class="testClassDiv" type="div"/>
will be transformed into
<div class="testClassDiv" />
Another feature is that you can as well output span elements for
forrest:hooks instead of div elements.
<forrest:hook name="testId" type="span"/>
will be transformed into
<span id="testId" />
> =================================================================
> Hooks are only used to define the structure in our output that is
> required to enable a theme to apply its look and feel.
> =================================================================
>
> The final job of views is to define where content should be placed
> within the structure of the page. This is done by using a
> forrest:contract. For example:
>
> <forrest:contract name="content-title"/>
>
> =================================================================
> Contracts define templates that are used to place content in
> a Forrest document.
> =================================================================
>
Helpers (forrest:contracts) mainly adapt and transform the presentation
model (pm) for the view, but also help with any limited business
processing that is initiated from the view (forrest:properties) (cp. [3]
& [4])
> NOTE: contracts may be static or dynamic.
A static contract expects a certain presentation model and will simply
transform the pm.
<forrest:contract name="content-title"/>
A dynamic contract simply adapt to the pm and can use data from the view
for it.
<forrest:contract name="branding-tagline">
<forrest:properties contract="branding-tagline">
<forrest:property name="branding-tagline-name">new
seed</forrest:property>
<forrest:property name="branding-tagline-tagline">powered by
forrest:views</forrest:property>
</forrest:properties>
</forrest:contract>
But a dynamic contract can as well service requests for data from the
view by simply providing access to the raw data or by formatting the
data.
<forrest:contract name="content-feeder">
<forrest:properties contract="content-feeder">
<forrest:property name="content-feeder"
nugget="get.nugget.feeder">
<url>/feeds/somefeed.xml</url>
</forrest:property>
</forrest:properties>
</forrest:contract>
Grouping of forrest:structure elements
**************************************
You can group elements to a template and call it from any
forrest:structure. e.g.
<forrest:hook name="export-link">
<forrest:contract name="content-xml-link"/>
<forrest:contract name="content-pdf-link"/>
</forrest:hook>
can be called as <forrest:call-template name="export-link"/>
when saved as {project:resources}/templates/export-link.vt.xml
[NOTE: This featured will be obsolete when we use jxtemplates]
>
> View FAQs
> =========
>
> Does a view define how the page is displayed?
>
> No. A view defines *what* is displayed
and how this *what* is structured.
> How it is displayed is defined
> by the Theme.
>
> ----
>
> What does a view define?
>
> A view defines the structure of a
request and the contracts (helper classes) that are to
> be placed within that structure.
Further it can as well initiated limited business processing with the
contracts.
>
> ----
>
> Why does a view define a document structure?
>
> The view structure is used to allow a theme to be created
> independently
> of the view.
This means as well format independent.
>
> ----
>
> What is a Theme?
>
> A theme is a description of how a page is to be displayed. It
> describes
> the look and feel of the page, but does not define any content.
>
> ----
>
> What does a contract define?
>
> A contract defines what content will be placed at a specific point in
> the document structure described by a View.
>
> ----
>
> What is a nugget?
>
> A nugget is a small piece of dynamic content described by a contract.
>
<snip org="David Crossley" rep="Ross">
> Style
> Presentation
> Theme
I think all these terms became encapsulated in theme as I defined it in
the start of this thread.
Style is usually used in the context of an HTML output. Presentation is
more generic, referring to the look and feel of an output format.
Theme is the Forrest:Views term for both of these together.
> Nugget
Is a bit of dynamic content inclued in a forest:view by a
forrest:contract. By dynamic we mean that it may change between
invocations of Forrest (or between requests if Forrest is running
dynamicaly).
> Aggregate
Forrrest:views aggregate various nuggets (which include the src
document) in a single output document.
</snip>
In addition to nugget, Nicola told me I used that in another way then he
refers to them. I see nuggets as helpers, that can service requests for
data from the view by simply providing access to the raw data or by
formatting the data.
I hope this summarizes the thread till now appropriately and adds some
more explanation to the terminology mess. I would like to encourage all
to add further thoughts to this, especially naming harmonizations under
the given background.
salu2
[1]
http://java.sun.com/blueprints/corej2eepatterns/Patterns/DispatcherView.html
[2]
http://svn.apache.org/viewcvs.cgi/*checkout*/forrest/trunk/site-author/content/xdocs/TR/2004/WD-forrest10.html
[3]
http://corej2eepatterns.com/Patterns2ndEd/ViewHelper.htm
[4]
http://java.sun.com/blueprints/corej2eepatterns/Patterns/ViewHelper.html
[5]
http://corej2eepatterns.com/Patterns2ndEd/DispatcherView.htm
On Sun, 2005-07-31 at 00:31 +0100, Ross Gardler wrote:
> --------------------------------------------------------------
>
> I do hope someone will take the time to put this into the
> forrest:views
> documentation once the content has been discussed and agreed.
>
>
>
--
thorsten
"Together we stand, divided we fall!"
Hey you (Pink Floyd)
