On Thu, 2005-06-23 at 20:54 +0100, Ross Gardler wrote:
> Tim Williams wrote:
> > On 6/23/05, Diwaker Gupta <[EMAIL PROTECTED]> wrote:
> > 
> >>Now that the release is just around the corner (since the website is
> >>already updated, I guess we're just waiting for the announcement,
> >>perhaps we should jot down a priority list of new features for 0.8.
> >>
> >>Personally, I'd like to see the following happening:
> >>...

> > I'd add...
> > o Metadata -- I'd personally like to see support for inline dublin
> > core "meta" tags, custom metadata, and external [RDF-based] metacards.
> 
> This is a definite need, I'm not sure it will make into 0.8 though. If 
> someone is available to implement it for 0.8 then it goes in. I can 
> imagine myself looking into this for 0.9 if it hasn't already been done.

...
> 
> > o Perspectives/Logic:Views as described
> > http://marc.theaimsgroup.com/?l=forrest-dev&m=111942914210799&w=2\
> 
> I think we need more discussion on a design for this. I'd be more 
> comfortable if this kind of information was in the document metadata 
> rather than in the view. +1 to the concept though, just not sure how and 
> when. It should certainly be in the issue tracker.

lol

I reckon the whole design of views needs discussion (I will never stop
on saying this). ;-)

Seriously, coming back to metadata: 
I recommend to split the forrest:properties from the view. Ross was
never really comfortable with their existence in the view and I agreed
saying they are right now a later entry point into the processing
pipeline (that I have in mind). 

I agree on an earlier mail from nicola (about metadata) and suggest:
index.fv
index.prop
index.meta
index.xml

or:
index.fv.xml
index.prop.xml
index.meta.xml
index.xml

Actually I am unsure which one is better because one invents fancy (e.g.
*.meta) extensions, the other is reserving this extensions in the naming
(*.meta.xml). 

The *.prop would contain the view specific extra content dispatcher
(nuggets) that are now stored in the view. 

What is now missing is the logic:views part, because IMO that part has
to stay in the view. The logic:view part is for the designer like the
whole view. logic:view is handling *only* presentation logic to the
view. 

Now one can argue that an earlier stage of forrest should do that but I
do not see this. I see that designer need to create designs that are
dependent on simple conditions to add (or not) contracts (and/or hooks)
to the view.

Views are following the dispatcher-view pattern which means that the
view dispatches all nuggets (business helper) and contracts (view
helper). logic:view is a filter which determines what to dispatch.

How to activate this logic in the view I agree that need discussion. ;-)

salu2
-- 
thorsten

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

Reply via email to