Mailing-List: contact dev-help@forrest.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@forrest.apache.org
Received-SPF: pass (hermes.apache.org: domain of
 cjxaf-forrest-dev-1@m.gmane.org designates 80.91.229.2 as permitted sender)
To: dev@forrest.apache.org
From: Nicola Ken Barozzi <nicolaken@apache.org>
Subject: Re: [Discuss] Templating language - forrest:templates and Struts
   Tiles
Date: Tue, 23 Nov 2004 15:03:11 +0100
Lines: 102
Message-ID: <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>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103)
In-Reply-To: <1101209101.3383.84.camel@gci>
Sender: news <news@sea.gmane.org>

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.

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

> Besides this corium will add the view/theme information in site.xml. 

Wait a sec, this has to be decided still.

>>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 :-)

> 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.

-- 
Nicola Ken Barozzi                   nicolaken@apache.org
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)
---------------------------------------------------------------------