On Thu, 2005-06-16 at 17:20 +0100, Ross Gardler wrote:
> Thorsten Scherler wrote:
> > On Thu, 2005-06-16 at 14:01 +0000, [EMAIL PROTECTED] wrote:
> > 
> > 
> >>@@ -110,7 +110,7 @@
> >>   <plugin name="org.apache.forrest.plugin.internal.view"
> >>         type="internal"
> >>         author="Apache Forrest Project"
> >>-        
> >>website="http://forrest.apache.org/docs/plugins/org.apache.forrest.plugin.view";
> >>+        
> >>website="http://forrest.apache.org/pluginDocs/plugins_0_70/org.apache.forrest.plugin.view";
> >>         url="http://forrest.apache.org/plugins/";
> >>         version="0.1-dev">
> >>     <description>
> >>
> > 
> > 
> > Actually not all whiteboard plugins are listed in your commit nor in the
> > docu. e.g. viewHelper is missing.
> 
> To appear in the plugins index they need to be in the plugins.xml or 
> whiteboard-plugins.xml. You never added viewHelper, so it is not there. 
> I have not added it myself because I thought there may be a reason for 
> it not being present since you had added view (so I assumed you knew you 
> needed to do this).

Actually David was so kind and added view to the plugin.xml AFAIK. I
have build the view plugin once it was in the official plugin dir. I did
not add it to the plugin.xml because I was not aware that I had to do
that. David helped me out and added it but I forgot about that. Now I
remember. ;-)

> 
> I'm not very happy with the fact that view and viewHelper have created a 
> dependency in the plugins. 

Yeah, I know and totally agree. :(

Can you remember that we decided that we have to split it because the
old (all in one) view plugin mixed internal and output plugin. 

Now I added a third one that is an internal plugin. It allows us to see
all possible contracts (with description, usage, path) that a designer
can use in the forrest:view.

> I want to sort this out when we start working 
> on views as a community. 

I am *really* looking forward that the community will help to figure out
what we can do with this prototype implementations. They are prototypes
after all. ;-)

I am more then open for your advice as we start the work. I am still
learning the plugins concept and looking forward for new stuff to learn
from McPlugin et. al. 

> viewHelper is not really a plugin because it 
> doesn't actually do anything on its own. 

Yes and no. It delivers contracts and right now responsible for the last
pipeline step in the process, trying to say it delivers the final
response.

I agree on what you said because they really should concentrate only to
deliver view helper classes for the contracts. 

> I believe there should be a 
> fourth type of plugin, a view plugin. Things like viewHelper.xhtml will 
> go into there.
> 

Agree, like I said above views now reached all possible types of
plugins. Which have all dependencies on each other. For that reason I
started to speak about view package. 

In the code you will find some comments like:
<!--
    FIXME:
    The next pipes have to be refactored and then to go into the
view-interface (internal plugin)
    -->

I would like a concept of interface and implementation but was not able
to make it running. I am looking forward that we enhance that code. ;-)

> We will still be able to use the same download mechanism it will just 
> stop the plugin list getting confused by the viewHelpers. It is this 
> reasoning that I thought you had left out the viewHelper plugin.
> 

No, see above why, but you are right. It should stay like it is, I am
totally fine with that.

>  > Can it be that we have to publish (ant build) whiteboard plugins as
>  > well?
> 
> I'm not publishing most of the whiteboard plugins since they are 
> unstable and I think it would be better if only developers have access 
> to them. Some of them have been published because they were in the main 
> plugins directory originally. But none of the new ones have been published.
> 

That explains as well why view is listed. 

> If you want to publish the docs for them (in order to prevent 404 links 
> you can do so with "ant deploy-docs" (I will be doing all plugin and 
> docs deployments tomorrow after the release candidate has been built).
> 

Actually I am thinking about to gather them in the how to. The problem
(like you mentioned above) is that they are depend on each other and it
is quite a pain to read the docu of all the plugins involved right now.
I reckon I should add it to the how-to then we have a central place to
document views.

WDYT?

> Ross
> 

salu2
-- 
thorsten

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

Reply via email to