Mailing-List: contact dev-help@forrest.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@forrest.apache.org
Received-SPF: neutral (hermes.apache.org: local policy)
Subject: Re: [Discuss] Templating language - forrest:templates and Struts
	Tiles
From: Thorsten Scherler <thorsten@apache.org>
To: forrest dev <dev@forrest.apache.org>
In-Reply-To: <cnvfv0$70p$1@sea.gmane.org>
References: <1101076181.3535.2.camel@gci>  <cns9je$v73$1@sea.gmane.org>
	 <1101123748.3852.69.camel@gci>  <41A1E25C.4060200@apache.org>
	 <1101141492.3852.194.camel@gci>  <41A2183F.7010202@apache.org>
	 <1101147073.3852.286.camel@gci>  <41A23881.3040903@apache.org>
	 <1101151929.3829.0.camel@gci>  <cnuuo0$mdo$1@sea.gmane.org>
	 <1101209101.3383.84.camel@gci>  <cnvfv0$70p$1@sea.gmane.org>
Content-Type: text/plain; charset=iso-8859-1
Message-Id: <1101227187.3383.105.camel@gci>
Mime-Version: 1.0
Date: Tue, 23 Nov 2004 17:26:27 +0100
Content-Transfer-Encoding: 8bit

El mar, 23-11-2004 a las 15:03, Nicola Ken Barozzi escribi�:
> Thorsten Scherler wrote:
> > El mar, 23-11-2004 a las 10:09, Nicola Ken Barozzi escribi�:
> > 
> >>Thorsten Scherler wrote:
> >>
> >>>El lun, 22-11-2004 a las 20:05, Ross Gardler escribi�:
> >>...
> >>>>Cool!
> >>>
> >>>:) cheers ;-)
> >>
> >>:-)
> >>
> >>It still seems too complicated for the user... The normal user would 
> >>want to simply say "add this newsfeed" and get done with it. Same for 
> >>filtering.
> > 
> > That is what corium will be all about. ;-)
> > 
> > Corium can only be run in webapp mod because the user can change the
> > look & feel of his/her project via forms. Corium is a view editor. 
> > -> Press a button /add new element/ 
> > -> define the source dir/file or contract
> > = New nugget is in the view
> > 
> > In corium the usages of f:t is internal. The forms will produce f:t
> > snippet that will be inserted in the view dir. 
> 
> Adding a tool on top of something difficult still keeps the thing 
> difficult ;-)
> 
> Seriously, it *must* be easy to use also by hand.

Agree. I reckon if we have the first working sample you will see that it
is piece of cake. ;-)

> 
> This can be done if we insert the concept of "groups", where many 
> nuggets can reside in the same view "group".
> 

Nice, thought.

> > Besides this corium will add the view/theme information in site.xml. 
> 
> Wait a sec, this has to be decided still.
> 

future music. ;-) Agree

> >>IMHO the templating language must be used only by the skin/theme/view 
> >>(gosh, so many! ;-) designer, and not by the user.
> > 
> > I agree that we now have to many (skin/view/theme) and that f:t are
> > aimed on designer and advanced user but like I said we will use this
> > work in corium again. ;-)
> > 
> >>(BTW, I think I agree with your distinction between skin, view and 
> >>theme, I just have to digest it a bit more to make it mine)
> > 
> > IMO we should drop *skins*.
> ...
> 
> Yes, I agree.
> 

:) 

> >>I think we have come to an initial possible architecture. Thorsten, do 
> >>you have time to edit the forrest 0.1 document to insert these things?
> > 
> > docs-author/content/xdocs/TR/2004/WD-forrest10.html 
> > 
> > you mean?
> 
> Yes.
> 
> > I am unsure about the skins.
> >  
> > *skin* produces placeholder for nuggets/fbits skelleton.
> > *views* can use certain placeholder and add design information to the
> > skin.
> > *themes* add the final design implementation for the view in form of
> > css-files.
> 
> Yes. That's why I want you to edit it :-)
> 

LOL. Ok I will change it, like I think and we can discuss this changes
afterwards.

> > IMO we should just provide all placeholder for registered nuggets/fbits
> > by default as input in the *filtering stage*. The filtering state will
> > then only filter the markup of the nuggets/fbits that are needed in the
> > view in comparing it with the *.ft.
> > 
> > I mean we do not have to generate content that is not needed. That means
> > we create here a subset of all contracts and produce their markup.
> > 
> > Step 4 should be called "Viewing" and add a link to the f:t docs.
> > Besides that I would like to change the appearances of skin to view. 
> > We agreed that nuggets are as well view dependant. 
> > We still need the new format for the skinconf. 
> > I as well suggest that we change that to viewconf.xml. Here the *user*
> > (and not so much the designer) can alter the view without altering f:t.
> > In viewconf the information about the theming (<color>,...) should go as
> > well.
> 
> Wait a sec, one thing at a time :-)
> IMHO first we need to agree on the main phases, then we can show how a 
> document evolves in the stages, then we can start discussing how the 
> config files look like. Let's nail this part first.

Agree. I will add the results of this discussion.

Cheers for your constant input. 

-- 
thorsten

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