You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lenya.apache.org by Torsten Schlabach <ts...@apache.org> on 2005/03/01 23:31:13 UTC
[RT] Publets, Portlets, Blocks, Publiations, Configuration Management
and the good old SoC (was Re: Contrib directory)
>>> hopefully, we will not end up with three block-like systems:
>>>
>>> * lenya blocks
>>> * publications
>>> * resource type packages
>>
>>
>>
>> I could imagine that "lenya blocks", "resource type packages" and
>> "publets" can be merged into one concept (see the Publets page in
>> the Wiki).
>
>
> i think so too, and hopefully our research will find out how.
I agree as well. Let's make sure we take the time necessary to do our
homework (the research) and maybe try out some approaches in the
sandbox, then make a clear decision about the way to go.
If we become too tactical (i.e. everyone solving his immediate problem
first and then trying to generalize it) we might end up in a mess. Also
we should not forget to look for open standards and implement them where
appropriate.
I think in the Wiki we have a whole bunch of ideas which are all somehow
related and all not yet thought through thorrowly, such as:
http://wiki.apache.org/lenya/PublicationTemplating
http://wiki.apache.org/lenya/PubletsProposal
http://wiki.apache.org/lenya/PluginApiProposal
http://wiki.apache.org/lenya/ResourceTypePackages
http://wiki.apache.org/lenya/XIncludeAggregationProposal
http://wiki.apache.org/lenya/PageFragmentEditingProposal
+ someone once said that editors (Kupu, BXE, others ...) should be pluggable
I think we should try to consolidate all this some time soon.
A major step might be to challenge our current concept of "publication".
Today a publication is content + functionality to edit the content
(where it overrides or adds to the basic capabilities that the Lenya
core provides). IMO, we should not start to make the Lenya core modular
and introduce publication level modular functionaliy as well. (I said
functionaliy, not content.)
Also with repository integration it might be necessary to better
separate content from editing functionality.
Please share your views.
Regards,
Torsten
---------------------------------------------------------------------
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)
Posted by "Gregor J. Rothfuss" <gr...@apache.org>.
Andreas Hartmann wrote:
>> Also with repository integration it might be necessary to better
>> separate content from editing functionality.
>
>
> That would be a perfect world :)
>
> But I see a huge barrier there. Currently the editor configuration
> is strongly related to the document structure. Disentangling this
> could mean for instance to generate a forms editor XSLT from an XSD
> schema ...
BXE 2.0 is able to use the same XSL for editing that you use for
viewing, so this should become much simpler. once chregu is back from
his nice vacations we can think about switching trunk to bxe 2.0
the one form editor already supports that :)
it is probably possible to generate XSL for the forms editor from the
schema, at least for relatively simple schemas. another question is of
course the longer-term viability of xupdate (unfortunately a spec with 0
momentum at this time)
kupu is xhtml-only, so it is right out. (although see
http://issues.apache.org/bugzilla/show_bug.cgi?id=33314 to address this
to some extent)
--
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
Re: [RT] Publets, Portlets, Blocks, Publiations, Configuration Management
and the good old SoC (was Re: Contrib directory)
Posted by Michael Wechner <mi...@wyona.com>.
Andreas Hartmann wrote:
> Disentangling this
> could mean for instance to generate a forms editor XSLT from an XSD
> schema ...
this is actually what we originally had in mind for the form editor
and is still possible of course ;-) but never got implemented.
Michi
>
> -- Andreas
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
> For additional commands, e-mail: dev-help@lenya.apache.org
>
>
--
Michael Wechner
Wyona Inc. - Open Source Content Management - Apache Lenya
http://www.wyona.com http://lenya.apache.org
michael.wechner@wyona.com michi@apache.org
---------------------------------------------------------------------
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)
Posted by Andreas Hartmann <an...@apache.org>.
Torsten Schlabach wrote:
[...]
> A major step might be to challenge our current concept of "publication".
> Today a publication is content + functionality to edit the content
> (where it overrides or adds to the basic capabilities that the Lenya
> core provides). IMO, we should not start to make the Lenya core modular
> and introduce publication level modular functionaliy as well. (I said
> functionaliy, not content.)
Would that mean you assemble your publication features
by using different blocks providing the desired functionality?
> Also with repository integration it might be necessary to better
> separate content from editing functionality.
That would be a perfect world :)
But I see a huge barrier there. Currently the editor configuration
is strongly related to the document structure. Disentangling this
could mean for instance to generate a forms editor XSLT from an XSD
schema ...
-- Andreas
---------------------------------------------------------------------
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)
Posted by 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)
Posted by "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
Re: [RT] Publets, Portlets, Blocks, Publiations,
Configuration Management and the good old SoC (was Re: Contrib directory)
Posted by 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)
Posted by "Gregor J. Rothfuss" <gr...@apache.org>.
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.
>>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? 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..
>>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?
--
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
Re: [RT] Publets, Portlets, Blocks, Publiations, Configuration
Management and the good old SoC (was Re: Contrib directory)
Posted by Thorsten Scherler <th...@apache.org>.
On Tue, 2005-03-01 at 18:09 -0500, Gregor J. Rothfuss wrote:
...
>
> from the list above, only publication templating and forrest plugins are
> implemented today, afaik. so it would definitely make sense to take a
> look at what is there today first:
>
> http://svn.apache.org/viewcvs.cgi/forrest/trunk/plugins/
>
> the plus side of forrest plugins is that they exist today and address an
> area where lenya is weak today (resource type packages). on the minus
> side, it seems to rely heavily on skinconf.xml (very forrest-specific)
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.
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).
> 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. :(
> 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?
--
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)
Posted by "Gregor J. Rothfuss" <gr...@apache.org>.
Torsten Schlabach wrote:
> If we become too tactical (i.e. everyone solving his immediate problem
> first and then trying to generalize it) we might end up in a mess. Also
> we should not forget to look for open standards and implement them where
> appropriate.
+1
> I think in the Wiki we have a whole bunch of ideas which are all somehow
> related and all not yet thought through thorrowly, such as:
>
> http://wiki.apache.org/lenya/PublicationTemplating
> http://wiki.apache.org/lenya/PubletsProposal
> http://wiki.apache.org/lenya/PluginApiProposal
> http://wiki.apache.org/lenya/ResourceTypePackages
> http://wiki.apache.org/lenya/XIncludeAggregationProposal
> http://wiki.apache.org/lenya/PageFragmentEditingProposal
> + someone once said that editors (Kupu, BXE, others ...) should be
> pluggable
http://wiki.apache.org/cocoon/BlockBuilderDevDoc
http://svn.apache.org/viewcvs.cgi/forrest/trunk/docs-author/content/xdocs/plugins/pluginInfrastructure.xml?rev=153347&view=markup
i am sure there are more. it *is* a hot topic..
> I think we should try to consolidate all this some time soon.
>
> A major step might be to challenge our current concept of "publication".
> Today a publication is content + functionality to edit the content
> (where it overrides or adds to the basic capabilities that the Lenya
> core provides). IMO, we should not start to make the Lenya core modular
> and introduce publication level modular functionaliy as well. (I said
> functionaliy, not content.)
>
> Also with repository integration it might be necessary to better
> separate content from editing functionality.
the simplest thing to do is to compare and contrast all these
approaches. (do they really address the same things?) and then have a
summary wiki page with goals and *non-goals*.
from the list above, only publication templating and forrest plugins are
implemented today, afaik. so it would definitely make sense to take a
look at what is there today first:
http://svn.apache.org/viewcvs.cgi/forrest/trunk/plugins/
the plus side of forrest plugins is that they exist today and address an
area where lenya is weak today (resource type packages). on the minus
side, it seems to rely heavily on skinconf.xml (very forrest-specific)
and seems stuck in the DTD world. (note that i did not take a very close
look, so i might be wrong)
it is also easy enough to come up with a directory layout, so maybe we
should do that too.
--
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