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="[EMAIL PROTECTED]" > > href="mailto:[EMAIL PROTECTED] " > > > 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)
