Properties for views (Re: logic filters in views)

[Ross Gardler <rg...@apache.org>]

Thorsten Scherler wrote:
> On Mon, 2005-06-27 at 16:00 +0100, Ross Gardler wrote:
> 
>>Thorsten Scherler wrote:

...

>>>The *.prop would contain the view specific extra content dispatcher
>>>(nuggets) that are now stored in the view. 
>>
>>Sorry, I'm not familiar enough with views terminology yet. Can you give 
>>me this in English, or even with a code example?
>>
> 
> 
> Actually our favorite example: ;-)
> <forrest:contract name="feeder">
>     <forrest:properties contract="feeder">
>       <forrest:property name="feeder" nugget="get.nugget.feeder">
>         <url>/feeds/somefeed.xml</url>
>       </forrest:property>
>     </forrest:properties>
> </forrest:contract>

I thought that was what you meant, I'm not sure I agree. Lets explore...

> The forrest:properties should go in a file for their own. that would
> make: 
> in *.fv:
> <forrest:contract name="feeder"/>

Well this is cleaner, I like that. What I am uncomfortable with is the 
creation of yet another file we need to edit in order to get the page to 
look the way we want it. Admittedly it is unlikely that we will need to 
create all three files for many pages. This brings me back again to the 
per directory config (see below)

> and in *.prop.xml:
> <forrest:properties contract="feeder">
>  <forrest:property name="feeder" nugget="get.nugget.feeder">
>    <url>/feeds/somefeed.xml</url>
>  </forrest:property>
> </forrest:properties>

[ASIDE] I think we need to create a more generic contract instead of 
this feeder one, it looks exactly the same and behaves exactly the same, 
but it is called "embed" or something like that. This can be used to 
embed any content within a view based page - this gives us a portal.

> Actually here you see that it is a kind of skinconf, but especially for
> the one file. That is the reason why we need to harmonize the
> skinconf/forrest:properties. Where I see the skinconf as
> default.prop.xml. ;-)

This is also why we need the per directory configs. Imagine a site with, 
for example, a number of subsections, lets say Human Resources, Product 
News and Market Analysis. The RSS feed for each section will be 
different, but it will not be different for each page within each section.

Without per directory we need three files for every page - bad.

With per directory config we need three files for each directory - good.

Of course, you said you think you can make this work. I'm now saying I 
think we *have* to make this work, unless...

> Another thing that I noticed that each contract/properties should be
> linked via unique id, to better reuse dynamic contracts in the view. 

Does this impace my concern abouve?

Ross

Re: Properties for views (Re: logic filters in views)

[Thorsten Scherler <th...@apache.org>]

On Mon, 2005-06-27 at 10:33 -0700, Diwaker Gupta wrote:
> > Without per directory we need three files for every page - bad.
> 
> I agree. If Forrest requires me to create 3 files for each page, I'm
> going to be concerned.
> 

Yeah, I will try to implement it today. 

One question:
<map:match pattern="prepare.view.**">
      <map:select type="exists">
        <!--
          Here we will have to test, whether the requested page needs a
specific view.
          This will be assumed as soon there is a .fv
          e.g. index.xml + index.fv
          -->
        <map:when test="{project:content.xdocs}{1}.fv">
          <map:generate src="{project:content.xdocs}{1}.fv"/>
        </map:when>

Now after this match we need to add the directory default view. How can
I determine the dir part (substring-before the last '/') in that match.
Has somebody an idea?

> > With per directory config we need three files for each directory - good.
> 
> And of course, Forrest should always fall back to a default
> configuration should these files be not present. IMHO, per file
> configuration should be made possible (I'm sure there are some use
> cases where this is required), but not mandated; and a per directory
> configuration should be preferred; while the default stays how it is
> now (or something close)


Yes, the default.fv from the view-skin is the ultimate fallback always.
The processing should become:
1) page-specific
2) dir-specific
3) project-default
4) view-skin-default

Views *are* and *should be* fully functional even if the user do not add
any config files. If (s)he provide them they will change the default
behavior. 

salu2
-- 
thorsten

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

Re: Properties for views (Re: logic filters in views)

[Diwaker Gupta <di...@gmail.com>]

> Without per directory we need three files for every page - bad.

I agree. If Forrest requires me to create 3 files for each page, I'm
going to be concerned.

> With per directory config we need three files for each directory - good.

And of course, Forrest should always fall back to a default
configuration should these files be not present. IMHO, per file
configuration should be made possible (I'm sure there are some use
cases where this is required), but not mandated; and a per directory
configuration should be preferred; while the default stays how it is
now (or something close)
-- 
Diwaker Gupta
http://resolute.ucsd.edu/diwaker