You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@forrest.apache.org by Cyriaque Dupoirieux <Cy...@pcotech.fr> on 2005/07/07 14:13:13 UTC
Plugs in or skins ?
Hi,
I'm working on a plug in of my own (the first one !) to understand
well the architecture.
Now, I am nearly able to use the standard pelt skin instead of a sub
skin I had created.
But I wander where is the frontier between skins and plugs in ?
* For instance, the download example in the forrest documentation or
the Faqs, don't you consider they should have been developed as
plugs in just as ProjectInfo ?
Since everything works as I wanted with my new plug in, I start to
think that I don't need to create my own skin any more :
if I want to extend the DTD to taken into account new tags, I can
create an input plug in,
If I want to change the layout of an existing tag, I can create an
output plug in.
Am I right ?
(Maybe views will answer my existential questions...)
--
Cyriaque,
Re: Plugs in or skins ?
Posted by Thorsten Scherler <th...@apache.org>.
On Thu, 2005-07-07 at 18:11 +0200, Cyriaque Dupoirieux wrote:
> >>> (Maybe views will answer my existential questions...)
> >>>
> >>>
> >>Yes, they will!
> >>
> >>
> >>
> >
> >Yes, please, Cyriaque, have a look into views.
> >
> >
> Waouh ! It's amazing.
> My plug in can be shrinked to two small contracts !
:)
I was expecting something like this. ;-)
> And I really like the distinction between head and body which
> automatically includes scripts in the header !
> I will continue my study tomorrow, but I think it's the solution I was
> looking for for ages.
>
:) nice to hear, welcome to views. ;-)
> The only thing is I was used to the pelt skin...
> I am going to see what I can do.
>
Actually we have to provide all contract that we are using right now on
forrest.apache.org before we can call our default.fv default. ;-)
It would be really nice to see pelt done with views. Maybe we can even
fix he floating searchbox css bug. ;-)
> Thanks a lot,
>
> >I reckon what you really want to do is writing your own viewHelper.xhtml
> >plugin. This plugin can be compared with the traditional "skin-packages"
> >like pelt. It provides contracts, css and a default view implementation
> >(html skeleton) like a skin with the advantage that a designer can
> >easily change parts or the whole lot of the skin without touching
> >contracts (xsl-code).
> >
> >Please join us on developing views.
> >
> >
> Why not,
>
:)
> >salu2
> >
> >
> Cyriaque,
>
salu2
--
thorsten
"Together we stand, divided we fall!"
Hey you (Pink Floyd)
Re: Plugs in or skins ?
Posted by Cyriaque Dupoirieux <Cy...@pcotech.fr>.
Thorsten Scherler a écrit :
>On Thu, 2005-07-07 at 13:58 +0100, Ross Gardler wrote:
>
>
>>Cyriaque Dupoirieux wrote:
>>
>>
>>>Hi,
>>>
>>> I'm working on a plug in of my own (the first one !) to understand
>>>well the architecture.
>>> Now, I am nearly able to use the standard pelt skin instead of a sub
>>>skin I had created.
>>> But I wander where is the frontier between skins and plugs in ?
>>>
>>>
>>There are three types of plugin:
>>
>>input - converts an input format to our internal format (currently xdoc)
>>output - converts our internal format to an *unskinned* output format
>>internal - changes internal behaviour of Forrest (advanced users only)
>>
>>As you can see a plugin should *never* affect the skinning process.
>>
>>If you look at views you will find that they are currently an internal
>>plugin and a related output plugin. This is one of the reasons they are
>>still in the whiteboard. We will (probably) be creating a new kind of
>>plugin to handle skinning, and the current internal views plugin will
>>become part of core.
>>
>>
>>
>>> * For instance, the download example in the forrest documentation or
>>> the Faqs, don't you consider they should have been developed as
>>> plugs in just as ProjectInfo ?
>>>
>>>
>>Yes, but they are examples of extending a project without using plugins.
>>That is legacy documentation from before the existence of plugins. You
>>raise an interesting point - do we still need this feature? I agree that
>>the download example should certainly be a plugin and if we are to keep
>>the project extension mechanism we should think of a more appropriate
>>use case.
>>
>>
>>
>>> Since everything works as I wanted with my new plug in, I start to
>>>think that I don't need to create my own skin any more :
>>>
>>> if I want to extend the DTD to taken into account new tags, I can
>>> create an input plug in,
>>> If I want to change the layout of an existing tag, I can create an
>>> output plug in.
>>>
>>> Am I right ?
>>>
>>>
>>Your first statement is correct, but your second is not. An output
>>plugin creates an output format (HTML, voiceXML, text, POD etc.) it is
>>not responsible for describing how the document is laid out. Of course,
>>there are overlaps, for example text does not have a method of defining
>>presentation separately, but HTML certainly does.
>>
>>
>>
>>> (Maybe views will answer my existential questions...)
>>>
>>>
>>Yes, they will!
>>
>>
>>
>
>Yes, please, Cyriaque, have a look into views.
>
>
Waouh ! It's amazing.
My plug in can be shrinked to two small contracts !
And I really like the distinction between head and body which
automatically includes scripts in the header !
I will continue my study tomorrow, but I think it's the solution I was
looking for for ages.
The only thing is I was used to the pelt skin...
I am going to see what I can do.
Thanks a lot,
>I reckon what you really want to do is writing your own viewHelper.xhtml
>plugin. This plugin can be compared with the traditional "skin-packages"
>like pelt. It provides contracts, css and a default view implementation
>(html skeleton) like a skin with the advantage that a designer can
>easily change parts or the whole lot of the skin without touching
>contracts (xsl-code).
>
>Please join us on developing views.
>
>
Why not,
>salu2
>
>
Cyriaque,
Re: Plugs in or skins ?
Posted by Thorsten Scherler <th...@apache.org>.
On Thu, 2005-07-07 at 13:58 +0100, Ross Gardler wrote:
> Cyriaque Dupoirieux wrote:
> > Hi,
> >
> > I'm working on a plug in of my own (the first one !) to understand
> > well the architecture.
> > Now, I am nearly able to use the standard pelt skin instead of a sub
> > skin I had created.
> > But I wander where is the frontier between skins and plugs in ?
>
>
> There are three types of plugin:
>
> input - converts an input format to our internal format (currently xdoc)
> output - converts our internal format to an *unskinned* output format
> internal - changes internal behaviour of Forrest (advanced users only)
>
> As you can see a plugin should *never* affect the skinning process.
>
> If you look at views you will find that they are currently an internal
> plugin and a related output plugin. This is one of the reasons they are
> still in the whiteboard. We will (probably) be creating a new kind of
> plugin to handle skinning, and the current internal views plugin will
> become part of core.
>
> > * For instance, the download example in the forrest documentation or
> > the Faqs, don't you consider they should have been developed as
> > plugs in just as ProjectInfo ?
>
> Yes, but they are examples of extending a project without using plugins.
> That is legacy documentation from before the existence of plugins. You
> raise an interesting point - do we still need this feature? I agree that
> the download example should certainly be a plugin and if we are to keep
> the project extension mechanism we should think of a more appropriate
> use case.
>
> > Since everything works as I wanted with my new plug in, I start to
> > think that I don't need to create my own skin any more :
> >
> > if I want to extend the DTD to taken into account new tags, I can
> > create an input plug in,
> > If I want to change the layout of an existing tag, I can create an
> > output plug in.
> >
> > Am I right ?
>
> Your first statement is correct, but your second is not. An output
> plugin creates an output format (HTML, voiceXML, text, POD etc.) it is
> not responsible for describing how the document is laid out. Of course,
> there are overlaps, for example text does not have a method of defining
> presentation separately, but HTML certainly does.
>
> > (Maybe views will answer my existential questions...)
>
> Yes, they will!
>
Yes, please, Cyriaque, have a look into views.
I reckon what you really want to do is writing your own viewHelper.xhtml
plugin. This plugin can be compared with the traditional "skin-packages"
like pelt. It provides contracts, css and a default view implementation
(html skeleton) like a skin with the advantage that a designer can
easily change parts or the whole lot of the skin without touching
contracts (xsl-code).
Please join us on developing views.
salu2
--
thorsten
"Together we stand, divided we fall!"
Hey you (Pink Floyd)
Re: Plugs in or skins ?
Posted by Ross Gardler <rg...@apache.org>.
Cyriaque Dupoirieux wrote:
> Hi,
>
> I'm working on a plug in of my own (the first one !) to understand
> well the architecture.
> Now, I am nearly able to use the standard pelt skin instead of a sub
> skin I had created.
> But I wander where is the frontier between skins and plugs in ?
There are three types of plugin:
input - converts an input format to our internal format (currently xdoc)
output - converts our internal format to an *unskinned* output format
internal - changes internal behaviour of Forrest (advanced users only)
As you can see a plugin should *never* affect the skinning process.
If you look at views you will find that they are currently an internal
plugin and a related output plugin. This is one of the reasons they are
still in the whiteboard. We will (probably) be creating a new kind of
plugin to handle skinning, and the current internal views plugin will
become part of core.
> * For instance, the download example in the forrest documentation or
> the Faqs, don't you consider they should have been developed as
> plugs in just as ProjectInfo ?
Yes, but they are examples of extending a project without using plugins.
That is legacy documentation from before the existence of plugins. You
raise an interesting point - do we still need this feature? I agree that
the download example should certainly be a plugin and if we are to keep
the project extension mechanism we should think of a more appropriate
use case.
> Since everything works as I wanted with my new plug in, I start to
> think that I don't need to create my own skin any more :
>
> if I want to extend the DTD to taken into account new tags, I can
> create an input plug in,
> If I want to change the layout of an existing tag, I can create an
> output plug in.
>
> Am I right ?
Your first statement is correct, but your second is not. An output
plugin creates an output format (HTML, voiceXML, text, POD etc.) it is
not responsible for describing how the document is laid out. Of course,
there are overlaps, for example text does not have a method of defining
presentation separately, but HTML certainly does.
> (Maybe views will answer my existential questions...)
Yes, they will!
Ross