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