forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thorsten Scherler <thors...@apache.org>
Subject Re: [DISCUSS] feeder plugin contract in the view
Date Fri, 01 Apr 2005 07:31:34 GMT
On Fri, 2005-04-01 at 00:06 +0100, Ross Gardler wrote:
> 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:

<snip what="lots of agreed stuff"/>

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

<snip what="lots of agreed stuff"/>

> 
> 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" ;-))
> 

Seeing your reply and understanding you (hopefully) a wee bit better, I
must say we have a trade off between clean dir structure (view contains
meta and get mocked up) or a clean view and a shadow dir structure of
*.meta (see your concerns above). 

You tend to split the things apart to better reuse them. ;-) That means
as logical consequence we not only have a view file for the data but
also a meta data file (forrest:properties would go there and not in the
view).

data: index.xml
view: index.fv
meta: index.meta.xml

The way I have implemented it (metadata in the view) can (and I reckon,
will) be changed in the future if we see the views get to mocked up (I
think they'll tend to do so -> logic:..., ...). Lets see the way we
doing it right now as a later entry point in the pipe (after the
aggregation of *.meta and *.fv). Maybe that feels better ;-)

...and IMO we have to discuss index.meta.xml pretty soon because that
feels pretty right. ;-)

<snip what="lots of agreed stuff"/>

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

:) 

hmm, yeah I am still learning forrest and plugins, ... besides that if
you know something is not 100% right in your concept you will spend a
great deal of time to understand what it is. Now splitting views from
skins feels way better. ...and hopefully it will be now finished pretty
soon.

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

gracias, por fin, uno que. ;-) 

Actually you are not the only one that told me, (s)he do not understand
the problematic and how to fit it with my suggestions. Greetings to
Antonio and CheChe. ;-)

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

:) I guess that is another reason I was not faster because I am like
this too. 

salu2
-- 
thorsten

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


Mime
View raw message