views dependency (was: Re: svn commit: r190919)

[Thorsten Scherler <th...@apache.org>]

On Thu, 2005-06-16 at 17:20 +0100, Ross Gardler wrote:
> Thorsten Scherler wrote:
> > On Thu, 2005-06-16 at 14:01 +0000, rgardler@apache.org 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)

Re: views dependency

[Ross Gardler <rg...@apache.org>]

Nicola Ken Barozzi wrote:
> Thorsten Scherler wrote:
> ...
> 
>>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.
> 
> 
> IMO the views are part of core Forrest, they are not plugins.
> This would solve both dependency and documentation problems.

I agree that the controlling portion of the view is in fact part of core 
(i.e. the stuff in o.a.f.p.internal.view). However, the parts that 
define the contracts (i.e. o.a.f.p.output.viewHelper.xhtml) are not, 
there may be different versions of these, like we have different skins 
at present.

However, they should not be called "plugins", that will serve to 
confuse. A plugin adds functionality, it does not change the look of the 
final document. I think they need to be called "views" (a name that will 
be freed up if we move the view "plugin" into core).

Ultimately, what I think would be great to see is the provision of each 
contract as an independently downloadable unit. Views (aka skins) would
then define a collection of related contracts via the default.fv file.

Allowing contracts to be downloaded and used independently provides a 
set of building blocks for view designers. For example, someone could 
choose to have the AJAX enabled search contract from the (fictitious) 
fully dynamic view, but the static navigation menu contract from another 
view.

With careful CSS design the look and feel of the resulting page will be 
consistent.

I suspect that this is what Thorsten has had in mind all along, I'm only 
seeing it now I have had chance to have a little play.

Ross

Re: views dependency

[Thorsten Scherler <th...@apache.org>]

On Fri, 2005-06-17 at 10:51 +0200, Nicola Ken Barozzi wrote:
> Thorsten Scherler wrote:
> ...
> > 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.
> 
> IMO the views are part of core Forrest, they are not plugins.
> This would solve both dependency and documentation problems.
> 

Yes I can remember that you always said that. ;-) Thx to throw that back
into the discussion. :)

That is fine with me, but the viewHelper.{format} can be in any possible
output format and they should like Ross stated become a new typ of
plugin (view plugin). The default xhtml implementation that we have now
(viewHelper.xhtml) goes into the core. ...but it has to be easy to
provide own implementation.

Now in regards to any other new view skin that can provide their own
implementation of the contracts (*.ft), views (*.fv) and style (*.css)
as a view plugin. Then we solved the "new skin" problematic in a nice
clear way. Actually that brings back "good" similarities with the
situation we have now with skins.

WDYT? 

salu2
-- 
thorsten

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

Re: views dependency

[Nicola Ken Barozzi <ni...@apache.org>]

Thorsten Scherler wrote:
...
> 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.

IMO the views are part of core Forrest, they are not plugins.
This would solve both dependency and documentation problems.

-- 
Nicola Ken Barozzi                   nicolaken@apache.org
            - verba volant, scripta manent -
   (discussions get forgotten, just code remains)
---------------------------------------------------------------------