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 Thu, 31 Mar 2005 22:28:54 GMT
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). 

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


Mime
View raw message