Return-Path: 
 <dev-return-15491-apmail-forrest-dev-archive=forrest.apache.org@forrest.apache.org>
Delivered-To: apmail-forrest-dev-archive@www.apache.org
Received: (qmail 20942 invoked from network); 31 Mar 2005 23:06:19 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199)
  by minotaur.apache.org with SMTP; 31 Mar 2005 23:06:19 -0000
Received: (qmail 79829 invoked by uid 500); 31 Mar 2005 23:06:18 -0000
Delivered-To: apmail-forrest-dev-archive@forrest.apache.org
Received: (qmail 79635 invoked by uid 500); 31 Mar 2005 23:06:18 -0000
Mailing-List: contact dev-help@forrest.apache.org; run by ezmlm
Precedence: bulk
list-help: <mailto:dev-help@forrest.apache.org>
list-unsubscribe: <mailto:dev-unsubscribe@forrest.apache.org>
List-Post: <mailto:dev@forrest.apache.org>
Reply-To: dev@forrest.apache.org
Delivered-To: mailing list dev@forrest.apache.org
Received: (qmail 79621 invoked by uid 99); 31 Mar 2005 23:06:18 -0000
X-ASF-Spam-Status: No, hits=0.0 required=10.0
	tests=
X-Spam-Check-By: apache.org
Received-SPF: neutral (hermes.apache.org: local policy)
Received: from ns3.wkwyw.net (HELO ns3.wkwyw.net) (217.199.181.91)
  by apache.org (qpsmtpd/0.28) with SMTP; Thu, 31 Mar 2005 15:06:16 -0800
Received: (qmail 6972 invoked from network); 31 Mar 2005 23:06:13 -0000
Received: from 82-69-78-226.dsl.in-addr.zen.co.uk (HELO ?192.168.0.4?)
 (82.69.78.226)
  by ns3.wkwyw.net with SMTP; 31 Mar 2005 23:06:13 -0000
Message-ID: <424C8263.3020306@apache.org>
Date: Fri, 01 Apr 2005 00:06:11 +0100
From: Ross Gardler <rgardler@apache.org>
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: dev@forrest.apache.org
Subject: Re: [DISCUSS] feeder plugin contract in the view
References: <1112171306.5310.29.camel@localhost.localdomain>
	 <424B4A81.4080606@apache.org>
	 <1112270905.4655.53.camel@localhost.localdomain>
	 <424C00EF.9050405@apache.org>
	 <1112288238.4655.150.camel@localhost.localdomain>
	 <424C3503.4060803@apache.org>
 <1112308134.19552.74.camel@localhost.localdomain>
In-Reply-To: <1112308134.19552.74.camel@localhost.localdomain>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Checked: Checked
X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N

Thorsten Scherler wrote:
> On Thu, 2005-03-31 at 18:36 +0100, Ross Gardler wrote:
> 
> <snip what="lots of agreed stuff"/>
> 
>>>>Lets return to your observation that "a forrest:view is comparable with 
>>>>a view on a table of a db. It is a subset of data". The key thing about 
>>>>a view in a database is that it does not contain any data, it only 
>>>>contains information about what data should be presented.
>>>>
>>>
>>>
>>>exactly. 
>>>
>>>...but you can parse params to the view to specify which sets of data
>>>you want have returned, right?
>>
>>Lets keep it simple at first - no paramaters (yet).
> 
> 
> Hmm, what about
> <forrest:contract name="feedback-dyn">
> <forrest:properties contract="feedback-dyn">
>   <forrest:property name="main">
>     <feedback to="webmaster@foo.com"
> href="mailto:webmaster@foo.com?subject=Feedback&#160;" >
>     Send DYNAMIC feedback about the website to:
>    </feedback>
>   </forrest:property>
> </forrest:properties>
> </forrest:contract>
> 
> That would be a configuration that is used in the implementation
> (skinning stage). 

Isn't that meta-data ("who is the site maintainer")?

Meta-data belongs with the content.

Which makes me think I was right to say:

>>>Does this mean that:
>>><forrest:properties contract="feeder">
>>>  <forrest:property name="feeder" nugget="get.nugget.feeder">
>>>    <url>/feeds/somefeed.xml
>>>  </forrest:property>
>>></forrest:properties>
>>>

...

>>
>>I guess it should be in the content since the user should be defining 
>>what is going to be displayed.

Given your other example above I am now fairly sure this statement is 
correct, since the URL of the document generated from the feed is also 
site data.

but ...

> It seems you suggesting to add roles to the views. You recommend to keep
> a shadow xdocs structure of views depending on roles.

Yes, I was suggesting that, but now looking at you explaining it back to 
me I'm not sure I was heading in the right direction. There's too much 
duplication in the file structures. It reminds me of when we had a raw 
content directory and an xdocs directory. We got rid of that becasue it 
was too clunky. Now here I am coming up with the same idea for a 
different use case - not good.

So...

> Another alternative to implement such mechanism would be to add
> something like the following in the view. In the spirit of
> http://struts.apache.org/userGuide/struts-logic.html#notPresent
> 
> <forrest:view type="xhtml">
>  <logic:notPresent name="user">
>   <forrest:contract name="login.form"/> 
>  </logic:notPresent>
> </forrest:view>

This is much nicer and keeps the directory structure cleaner.

...

> Now we found out that views are separated from skinning but I still
> think that both stages can (and should) share the same config file. 
> 
> The view is requesting a subset of data. This data will be later on
> prepared for presentation. IMO this connection makes it necessary to
> share a configuration file.

I have some reservations. But I think you should just do what you need 
to do for now and I'll look for problems in the real code rather than in 
the idea.

(the real meaning of this previous sentence is "it feels wrong, but I 
just tried to explain why it is wrong and got myself all confused" ;-))

> I would now like to create leather again as skin implementation of the
> view concept. That means I will as well drop the leather-dev skin
> because it will grow to the leather plugin (aka fbits).

WHatever you need to do to explore your ideas is fine by me, I'll do my 
best to keep up.

>>This is all starting to feel much more comfortable for me now. I think 
>>we are tuning this nicely  :-))
>>
> 
> 
> Yeah, thanks for you patients (looking on the date of the linked post)
> to wait for the proof of concept. ;-)

I thought you'd got it together pretty quick. Funny how people see these 
things differently.

> Your feedback really helped me to understand my problems.

Even more importantly, at least for me, I think I am understanding what 
you are doing now.

>>We are witnessing the major addition for Forrest 0.8 (if only we could 
>>get 0.7 out ;-))
>>
> 
> 
> Yeah, sorry that I am not a great help for 0.7.

That's not what I meant. I'm annoyed at myself for not finding more time 
for the 0.7 release - it's my usual problem - I'm getting excited by the 
new stuff and not finishing the old.

Still I got a couple of patches done tonight.

Ross