You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@forrest.apache.org by Thorsten Scherler <th...@apache.org> on 2005/04/01 00:28:54 UTC
Re: [DISCUSS] feeder plugin contract in the view
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 " >
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).
>
> >>The project data directories contain the data and meta-data about the site
> >>
> >
> >
> > Does this mean that:
> > <forrest:properties contract="feeder">
> > <forrest:property name="feeder" nugget="get.nugget.feeder">
> > <url>/feeds/somefeed.xml
> > </forrest:property>
> > </forrest:properties>
> >
> > Should go there as well?
> > Or do you think that can be compared with passing param to a view (see
> > above)?
>
> I guess it should be in the content since the user should be defining
> what is going to be displayed. However, it probably doesn't want to get
> all mixed up with the content.
>
> How about:
>
> content/documentation/xdocs
> content/documentation/views/default
> content/documentation/views/user
> content/documentation/views/guest
>
> etc.
>
to get it straight for myself.
The views are working on a per document base with 2 fallback mechanism.
The fallbacks can be compared with the current situation, all sites will
be rendered the same.
1) If there is no view for the requested document the default.fv of the
project will get rendered.
2) If the project do not have this view the views-plugins default one
will be used.
Having this in the back of my head the above structure looks like a nice
extension of this concept.
It seems you suggesting to add roles to the views. You recommend to keep
a shadow xdocs structure of views depending on roles.
content/documentation/xdocs
content/documentation/xdocs/index.xml
content/documentation/xdocs/aboutUs.fv
content/documentation/views/default.fv
content/documentation/views/user/index.fv
content/documentation/views/user/aboutUs.fv
content/documentation/views/{role}/*.fv
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 should probably be taken to a vote so lets get something working
> now and we'll decide where it actually lives with a vote against your
> proof of concept.
>
;-) jejeje
ok.
> >>The input plugins convert the input data into the internal format
> >>
> >>The views contain information that describes what data should be
> >>displayed in response to a specific request
> >>
> >
> >
> > <forrest:view type="xhtml"/> -> for xhtml requests
> >
> > Agree, but right now it contains as well information about the placing
> > of elements.
> > <forrest:hook name="branding">
> > <forrest:contract name="projectlogo"/>
> > <forrest:contract name="searchbox"/>
> > <forrest:contract name="nav-main"/>
> > </forrest:hook>
> >
> > <forrest:hook/> is a method to add design information to the outcome. It
> > will be render as <div id="{forrest:hook/@name}"/>.
> >
> > Would that be ok? If not what do you suggest?
>
> This feels like the skinning end of things.
Yes. :) ...and that is where everything started. ;-)
> I can imagine a use case in
> which we define a "user" view and then allow each user to define their
> own layout.
>
:) Actually this is what I want to implement in the near future for my
own private website. That makes it necessary to parse the profiling data
to the view.
> Therefore, I suspect that it should be separated out. What do you think?
>
It is the skinning end but the start of all things. ;-)
The fbits plugin started because leather-dev was a dead-end. I learned
that you cannot force designer to use a specific html-skelleton for
their design.
>>From leather-dev comes the idea of contracts. Snippet of html that the
designer can request and add it to their templates. This should
originally be done by the view with hooks and contracts.
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.
> >>The output plugins are responsible for skinning the data for display
> >>
> >
> >
> > Agree. That means all the *.ft that we have now in the view would have
> > to go to a new output plugin, right?
>
> From what I understand so far, yes.
>
Ok, I actually started the fbits plugin under the name of leather.
http://marc.theaimsgroup.com/?l=forrest-dev&m=109916818117512&w=2
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).
> > One question, can I use the view.fv as config file for the skinning
> > stage as well?
>
> Since views are now an internal plugin we can define new document
> schemas for passing information down the pipeline since they will be
> part of the internal system. Therefore, I do not perceive a problem with
> that.
>
ok
> > Resume:
> > project data -> input plugins -> views -> output
> >
> > Request/response circle:
> > 1) The CLIENT requests an url
> > 2) The url is linked to a view which will request
> > 3) the content from an input plugins, which will request the
> > 4) project data
> > 5) then the view sends the aggregation of 3/4 to the
> > 6) skinning stage which will
> > 7) response the CLIENT
> >
> > The next steps would be to move the contracts pipes and implementations
> > to an output plugin. Change the views plugin to an internal plugin.
>
> 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. ;-)
Your feedback really helped me to understand my problems.
> 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.
> Ross
muchas gracias
salu2
--
thorsten
"Together we stand, divided we fall!"
Hey you (Pink Floyd)
Re: [DISCUSS] feeder plugin contract in the view
Posted by Ross Gardler <rg...@apache.org>.
Thorsten Scherler wrote:
> On Fri, 2005-04-01 at 00:06 +0100, Ross Gardler wrote:
>
...
> 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 ;-)
Yes, lets see how it turns out.
>
> ...and IMO we have to discuss index.meta.xml pretty soon because that
> feels pretty right. ;-)
Aha! This is where I turn into a child again and run round shouting
"told you so! told you so!" :-P
As you say, I think we should come back to the whole meta data thing
when we get the views done, we can always move things around. For now,
just implement it the way you feel most comfortable with.
>>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. ;-)
Yes, there is much to be said for writing the code to prove a point. I
must remember that and write more code and less emails.
Ross
Re: [DISCUSS] feeder plugin contract in the view
Posted by Thorsten Scherler <th...@apache.org>.
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 " >
> > 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)
Re: [DISCUSS] feeder plugin contract in the view
Posted by Ross Gardler <rg...@apache.org>.
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 " >
> 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