forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thorsten Scherler <thors...@apache.org>
Subject Re: [views] Dir specific view
Date Thu, 07 Jul 2005 20:32:29 GMT
On Thu, 2005-07-07 at 16:48 +0100, Ross Gardler wrote:
> Thorsten Scherler wrote:
> > I added the dir specific view matcher to the location map. Will try to
> > merge tomorrow the view specific stuff back to trunk. 
> 
> OK, I'm using this now, just playing to start with. Here is what I want 
> to do:
> 
> I'm using the branding contracts. On the home page I just have the 
> branding-tagline-name contract, but on subsections (i.e. 
> sub-directories) I want to include a branding-tagline-tagline contract 
> as well. All other parts of the view remain the same.
> 

http://marc.theaimsgroup.com/?l=forrest-dev&m=110107619329543&w=2

"You can as well mix atomic parts with grouping templates.
<forrest:view output-format="xhtml, fo" name="intro">
  <forrest:hook name="intro">
   <forrest:nugget name="grouplogo"/>
   <forrest:call-template name="sports"/>
  </forrest:hook>
</forrest:view>"

The nuggets/fbits are called contracts.

This feature is not yet implemented but like you see IMO that will have to come pretty soon.
It is easy to implement because it is just a transformation to a xinclude tag away. ;-)

> I can create the effect I want by copying the default.fv from the root 
> into my subdir and adding the branding contrat that I need. However, 
> this causes a problem for maintenance since most of my default.fv 
> content is duplicated.
> 

Yes IMO the solution is to group the elements into forrest:templates
like e.g. (from the same link)
<forrest:template name="sports" output-format="fo">
<forrest:hook name="sports">
  <forrest:nugget name="sportNewsAbstract"/>
</forrest:hook>
</forrest:template>

Then we can reduce the maintainment work you describe. *but* reading
http://marc.theaimsgroup.com/?l=forrest-dev&m=111989070109905&w=2 again:
"Well this is cleaner, I like that. What I am uncomfortable with is the 
creation of yet another file we need to edit in order to get the page to 
look the way we want it. Admittedly it is unlikely that we will need to 
create all three files for many pages."

IMO there is a trade off, small overrides in external files (many files, no overhead) 
or putting all in one file (one file, but a lot of overhead). 
Yourself noticed now that for maintainment it makes not too much sense to have it in
one file, because you now ask:

> Is there a way of just setting the content of the 
> branding-tagline-tagline contract?
> 

Yes, described in
http://marc.theaimsgroup.com/?l=forrest-dev&m=111988914128794&w=2

"The forrest:properties should go in a file for their own. that would
make: 
in *.fv:
<forrest:contract name="feeder"/>
    
and in *.prop.xml:
<forrest:properties contract="feeder">
 <forrest:property name="feeder" nugget="get.nugget.feeder">
   <url>/feeds/somefeed.xml</url>
 </forrest:property>
</forrest:properties>

Actually here you see that it is a kind of skinconf, but especially for
the one file. That is the reason why we need to harmonize the
skinconf/forrest:properties. Where I see the skinconf as
default.prop.xml. ;-)"

The idea to have the same mechanism for default.prop.xml and default.fv.xml (I reckon I should
drop the fancy extension) ;-)

[OT] One could use as well default.xml as kind of file not found fallback. of course as well
on a per-dir basis. ;-)

> If not how would you suggest I go about making this happen?


We need to harmonize the skinconf.xml that it can become the
default.prop.xml. Then we need to add all matches for *.prop.xml into
the view plugin and add it to the aggregation. 

BTW http://marc.theaimsgroup.com/?l=forrest-dev&m=111989070109905&w=2
"[ASIDE] I think we need to create a more generic contract instead of 
this feeder one, it looks exactly the same and behaves exactly the same, 
but it is called "embed" or something like that. This can be used to 
embed any content within a view based page - this gives us a portal."

*hust*businessHelper*hust* ;-)

I was at a client yesterday and he showed me his own portlet implementation for cocoon (no
java spec. one, but 
more a modified cocoon portal one) and I showed him views. 

Guess what, we developed similar solutions without knowing from each other. 
Yes views gives us a portal. Even right now, but I agree we need a more generic contract.
My client used
*.xmap as businessHelper that where linked with a portlet. 

I mean we can allow each contract to resolve the model trough a contract specific sitemap.
Since yesterday
I cannot stop thinking about it. It follows the KISS approach which rocks. :)

José Ignacio the head dev from this client even donated me some code that I can use for views.
:) Like I said 
we solved the same problems. The trickiest one was to include dynamically xsl in the final
xsl.
I solved it with plain xsl and a couple of pipes (last call: getStylesheet.*.**) 
he with a custom generator. 

I may use it when we add view to the core to refactor some code. 

...but Antonio once said to me what I need is a transformer
and not a generator ;-)

salu2
-- 
thorsten

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


Mime
View raw message