forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ross Gardler <rgard...@apache.org>
Subject Re: [RT] businessHelper (was Re: Auto generating site.xml)
Date Sat, 11 Jun 2005 00:04:49 GMT
Thorsten Scherler wrote:
> Actually it sounds that parts of the businessHelper-plugin can be found
> in the auto generating site.xml proposal. 
> 
> The goal of the businessHelper-concept is to offer a framework to access
> different businessServices in a generic way. The businessHelper would be
> responsible to connect to a businessService (e.g. a wiki) and deliver
> the presentation model.

Isn't that the job of an input plugin? Like we did with the RSS feed to 
be included within another contract...

<forrest:contract name="feeder">
    <forrest:properties contract="feeder">
      <forrest:property name="feeder" nugget="get.nugget.feeder">
        <url>/feeds/somefeed.xml</url>
      </forrest:property>
    </forrest:properties>
</forrest:contract>

What is it that makes a businessHelper different from a contract that 
gets its content from a plugin in this way?

> I did some experiments with the inx-plugin I am developing. It is pretty
> generic so far, but still I need to capsule more the customer specific
> business logic, discuss the patent issue on legal@a.o and using more
> flexible triggers to release it to forrest. ATM the inx plugin contains
> both view/businessHelper what means that in general for each format a
> specific businessHelper is expected (like viewHelper.{format}) 

I'm sorry, I've read and re-read the rest of this thread many times. But 
I just don't get it. I suspect it is because you are referring to 
something I can't see and to tools I am not familiar with. I'll 
highlight why I am so lost in my comments, perhaps, when you have time, 
you can re-write this with more background and a use case appropriate to 
Forrest.

> raw.user.data - custom doctype that is coming from a previous stage that
> contains the user data that have to be transformed into indesign.
> Actually this is coming from an editor which defines the dtd to be used.

So this is the raw data from the src, say an RSS feed.

> data.model - this is the result of the transformation (rud2model.xsl) of
> r.u.d into something more generic regarding the containing models (the
> actual data).  A small snippet may show the format:

Sorry, no idea what this means. You are transforming the raw data into 
what? I'm afraid the XML snippet provided sheds no light on it for me 
since there is no explanation of what the tags and attributes are 
intended to mean.

> data.view - this is the result of the transformation (rud2view.xsl) of
> r.u.d into something more generic regarding the presentation of the
> data. A small snippet may show the format (which basicly is a generated
> forrest:view):

Nope, still lost I'm afraid. The XML snippet here shows a set of hooks 
and contracts, I get that part. It also seems to refer to some of the 
stuff in the previous section, but since I don't get that either...

> With the view and the model I then build the inx output. This is done by
> a generic model+view2inx.xsl. This stylesheets connects to the inx
> specific helper classes (here I still have some customer business logic)
> to do the transformation. 

Nope, since I don't know what 	 is this doesn't help either I'm afraid.

> Like you see I do not using the xdocs intermediate format but a custom
> doctype as input. That means for another doctype one have to write
> newDocType2model(/view).xsl.

So is this good or bad? It sounds bad, but I've not followed this far so 
maybe its good ???

> Now looking again into the original mail I can imagine that you can use
> this concept to achieve what you want. The mayor difference between my
> approach and the one you are working on is that I have the following
> processing:
> {request}.inx-> viewDispatcher -> {request}.fv + {request}.model
> ->{response}.inx

This just looks really complicated to do something that is essentially 
really simple (automate the generation of site.xml based on a filtered 
directory listing). What is wrong with my original proposal to just 
write a plugin that generates the necessary site.xml snippet using the 
existing directory generator?

> ...but with this concept you can actually generate only parts of the
> site.xml. The model would contain the dir structure that you want to
> export as plain data and the view will define the hierarchy. Then you
> only need a final transformation model+view2site.xml.xsl. 

This advantage seems to be exactly what I said in the last paragraph. Am 
I missing something in my confusion?

Ross

Mime
View raw message