Re: [RT] Publets, Portlets, Blocks, Publiations, Configuration Management and the good old SoC (was Re: Contrib directory)

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

On Wed, 2005-03-02 at 11:10 -0500, Gregor J. Rothfuss wrote:
> Thorsten Scherler wrote:
> 
> > No that is not really true. The only skinconf that you will find in each
> > plugin is the one for documenting the plugin. Each plugin contains the
> > documentation in itself. 
> 
> ok, good to know.
> 
> > Besided that ATM we are thinking about a new format of skinconf which
> > should be more abtract and independent. I am working on so called
> > forrest:views. Actually I think it would be a nice thing in lenya as
> > well, to have a file that controls the skin like the skinconf in forrest
> > does.
> > 
> > I actually integrated a Indesign plugin that I wrote as forrest plugin
> > into a lenya app without any problems. The nice thing on plugin is as
> > you said the packaging. You have everything in one plugin that you will
> > need. To connect a forrest plugin to lenya one only have to mount the
> > main plugin sitemap from lenya (and may be change some matches).
> 
> very interesting. i saw your post that you cannot release the indesign 
> plugin yet, but can you explain how you did the integration? hopefully, 
> we could do it in a way that does not require sitemap changes.
> 

Well, actually I had to adjust the sitemap of the plugin a wee bit (one
match that gets the user data) but that was because the plugin itself
did not supported different user data from the beginning. 

The nature of the plugin is semi-abstract. Trying to say it can be used
for different use cases but so far I only have tested it in one special.
That means part of the code would have to extracted to make it more
customizable. 

The plugin is an output-plugin. It will transform user-data and
inx-templates into an inx-document, which than can be opened in
Indesign. I just added the folowing to the publication-sitemap (lenya):

    <map:match pattern="inx/**">

     <map:mount
        uri-prefix="inx"
        src="{global:inxPlugin}/output.xmap"
        check-reload="true"
        reload-method="synchron"
       />
    </map:match> 

On the site of the plugin I will look up the user data (which path is
configured by an ant target, this data are not stored in the plugin
itself) and use the design templates from the plugin. 

Like I said I only had to change the path of the user data within the
plugin, but thx to ant that is quite customizable.


> 
> >>and seems stuck in the DTD world. (note that i did not take a very close 
> >>look, so i might be wrong)
> > 
> > Yeah, you kind of right. In forrest we are using heaps of dtd. :(
> 
> are they nice to haves or required? 

Not all required but we have some internal validation of e.g. the
skinconf before we doing an e.g. export. I would say 50 % of the dtd are
required. In the long run we want to give up the xdocs and I think we
should use the doctypes approach (wit RelaxNG) that we have here.

> while i don't think DTD have much of 
> a future, we could use MSV to validate against DTD as needed. though 
> them not having namespaces is a serious problem..
> 

I reckon future plugins will use schema but I will ask Ross what he
thinks about that because he is McPlugin. ;-)

> >>it is also easy enough to come up with a directory layout, so maybe we 
> >>should do that too.
> > 
> > Hmm, doesn't that structure highly depends on the publet?
> 
> why? i was thinking of a similar structure to todays publication, sorted 
> by file type. that should accomodate different publets, no?
> 

Ok, I see. I thought about forrest plugins as a possible lenya publets.
The plugin can e.g. provide the possibility to export given content into
another format or read different format and represent it on the web as
xhtml.

That means we only have to define one interface. I reckon a simple mount
(see above) would do it in most cases. I need to integrate some more
plugins from Ross to see whether it is always that easy. ;-)
-- 
thorsten

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


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org

Re: [RT] Publets, Portlets, Blocks, Publiations, Configuration Management and the good old SoC (was Re: Contrib directory)

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

On Wed, 2005-03-02 at 13:31 -0500, Gregor J. Rothfuss wrote:
> Thorsten Scherler wrote:
...
> > Ok, I see. I thought about forrest plugins as a possible lenya publets.
> > The plugin can e.g. provide the possibility to export given content into
> > another format or read different format and represent it on the web as
> > xhtml.
> > 
> > That means we only have to define one interface. I reckon a simple mount
> > (see above) would do it in most cases. I need to integrate some more
> > plugins from Ross to see whether it is always that easy. ;-)
> 
> this is a very valuable experiment. what we could do is to svn:externals 
> to the forrest plugins, and mount them inside the default publication to 
> try things out. would you be interested to try that and document your 
> findings?
> 

Yeah, I was up to integrate the wiki plugin Ross announced a couple of
month ago. I will give it a go and if it is working I will commit it to
the default pub and will document it. 

salu2
-- 
thorsten

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


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org

Re: [RT] Publets, Portlets, Blocks, Publiations, Configuration Management and the good old SoC (was Re: Contrib directory)

["Gregor J. Rothfuss" <gr...@apache.org>]

Thorsten Scherler wrote:


> On the site of the plugin I will look up the user data (which path is
> configured by an ant target, this data are not stored in the plugin
> itself) and use the design templates from the plugin. 
> 
> Like I said I only had to change the path of the user data within the
> plugin, but thx to ant that is quite customizable.

sounds reasonable.

> Not all required but we have some internal validation of e.g. the
> skinconf before we doing an e.g. export. I would say 50 % of the dtd are
> required. In the long run we want to give up the xdocs and I think we
> should use the doctypes approach (wit RelaxNG) that we have here.

agreed :)


> Ok, I see. I thought about forrest plugins as a possible lenya publets.
> The plugin can e.g. provide the possibility to export given content into
> another format or read different format and represent it on the web as
> xhtml.
> 
> That means we only have to define one interface. I reckon a simple mount
> (see above) would do it in most cases. I need to integrate some more
> plugins from Ross to see whether it is always that easy. ;-)

this is a very valuable experiment. what we could do is to svn:externals 
to the forrest plugins, and mount them inside the default publication to 
try things out. would you be interested to try that and document your 
findings?

-- 
Gregor J. Rothfuss
COO, Wyona       Content Management Solutions    http://wyona.com
Apache Lenya                              http://lenya.apache.org
gregor.rothfuss@wyona.com                       gregor@apache.org

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org