You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lenya.apache.org by Michael Wechner <mi...@wyona.com> on 2004/04/13 18:44:33 UTC
Clone Proposal
On IRC we did some brainstorming on introducing a clone "build file" for
publications.
Each publication has some generic and some specific parts, therefore it
would probably make sense to do it as follows:
.../lenya/bin/clone.xml (for the generic parts)
and
.../lenya/pubs/@PUB@/bin/clone.xml (for the specific parts)
whereas I guess the specific clone.xml imports the generic one (or is it
the opposite way around).
Anyway, for the beginning we could do this for the default and blog
publication.
Also I think we should add two new publication instances:
my-default and my-blog where we have slight changes re the layout for
instance.
Makes sense?
Michi
--
Michael Wechner
Wyona Inc. - Open Source Content Management - Apache Lenya
http://www.wyona.com http://cocoon.apache.org/lenya/
michael.wechner@wyona.com michi@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: lenya-dev-unsubscribe@cocoon.apache.org
For additional commands, e-mail: lenya-dev-help@cocoon.apache.org
Re: Clone Proposal
Posted by Michael Wechner <mi...@wyona.com>.
Gregor J. Rothfuss wrote:
>
>> Also I think we should add two new publication instances:
>>
>> my-default and my-blog where we have slight changes re the layout for
>> instance.
>
>
> -1 in cvs, +1 in the build process. or even better, accessible from
> the admin area. should be an easy excercise for someone to have a flow
> page trigger the ant task.
I think there is a misunderstaning. This has nothing to do with the
execution of the
clone process, but rather to show people how one has to setup one's own
publication
based on another publication. We won't have to explain anymore how to
use the cloning
because "my-default" and "my-blog" will illustrate it. We will probably
still have to
point to it though, but this is similar to "RTFM".
>
> -gregor
>
--
Michael Wechner
Wyona Inc. - Open Source Content Management - Apache Lenya
http://www.wyona.com http://cocoon.apache.org/lenya/
michael.wechner@wyona.com michi@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: lenya-dev-unsubscribe@cocoon.apache.org
For additional commands, e-mail: lenya-dev-help@cocoon.apache.org
Re: Clone Proposal
Posted by "Gregor J. Rothfuss" <gr...@apache.org>.
Michael Wechner wrote:
> whereas I guess the specific clone.xml imports the generic one (or is it
> the opposite way around).
the other way round from what i can see
> Anyway, for the beginning we could do this for the default and blog
> publication.
+1
> Also I think we should add two new publication instances:
>
> my-default and my-blog where we have slight changes re the layout for
> instance.
-1 in cvs, +1 in the build process. or even better, accessible from the
admin area. should be an easy excercise for someone to have a flow page
trigger the ant task.
-gregor
--
Gregor J. Rothfuss
Wyona Inc. - Open Source Content Management - Apache Lenya
http://wyona.com http://cocoon.apache.org/lenya
gregor.rothfuss@wyona.com gregor@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: lenya-dev-unsubscribe@cocoon.apache.org
For additional commands, e-mail: lenya-dev-help@cocoon.apache.org
Re: Clone Proposal
Posted by Rolf Kulemann <ro...@apache.org>.
On Tue, 2004-04-13 at 19:40, Michael Wechner wrote:
> Rolf Kulemann wrote:
>
> >
> >Can u please explain what they are for?
> >
>
> very little changes in order to show people the idea of cloning a
> publication, e.g.
>
> michi@neptun:~/src/cocoon-lenya$ ls src/webapp/lenya/pubs/my-default/
> publication.xml xslt
> michi@neptun:~/src/cocoon-lenya$ ls src/webapp/lenya/pubs/my-default/xslt/
> page2xhtml.xsl
Ah yes ok.
+1 to add my-* pubs :)
--
Regards,
Rolf Kulemann
---------------------------------------------------------------------
To unsubscribe, e-mail: lenya-dev-unsubscribe@cocoon.apache.org
For additional commands, e-mail: lenya-dev-help@cocoon.apache.org
Re: Clone Proposal
Posted by Michael Wechner <mi...@wyona.com>.
Rolf Kulemann wrote:
>
>Can u please explain what they are for?
>
very little changes in order to show people the idea of cloning a
publication, e.g.
michi@neptun:~/src/cocoon-lenya$ ls src/webapp/lenya/pubs/my-default/
publication.xml xslt
michi@neptun:~/src/cocoon-lenya$ ls src/webapp/lenya/pubs/my-default/xslt/
page2xhtml.xsl
> What is the difference to blog
>and default?
>
>
difference between blog and default with regard to cloning?
--
Michael Wechner
Wyona Inc. - Open Source Content Management - Apache Lenya
http://www.wyona.com http://cocoon.apache.org/lenya/
michael.wechner@wyona.com michi@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: lenya-dev-unsubscribe@cocoon.apache.org
For additional commands, e-mail: lenya-dev-help@cocoon.apache.org
Re: Clone Proposal
Posted by Rolf Kulemann <ro...@apache.org>.
On Tue, 2004-04-13 at 18:44, Michael Wechner wrote:
> On IRC we did some brainstorming on introducing a clone "build file" for
> publications.
>
> Each publication has some generic and some specific parts, therefore it
> would probably make sense to do it as follows:
>
>
> .../lenya/bin/clone.xml (for the generic parts)
>
> and
>
> .../lenya/pubs/@PUB@/bin/clone.xml (for the specific parts)
>
> whereas I guess the specific clone.xml imports the generic one (or is it
> the opposite way around).
>
> Anyway, for the beginning we could do this for the default and blog
> publication.
+1
>
> Also I think we should add two new publication instances:
>
> my-default and my-blog where we have slight changes re the layout for
> instance.
Can u please explain what they are for? What is the difference to blog
and default?
--
Regards,
Rolf Kulemann
---------------------------------------------------------------------
To unsubscribe, e-mail: lenya-dev-unsubscribe@cocoon.apache.org
For additional commands, e-mail: lenya-dev-help@cocoon.apache.org
Re: Clone Proposal
Posted by Dale Christ <de...@yahoo.com>.
--- Michael Wechner <mi...@wyona.com> wrote:
> On IRC we did some brainstorming on introducing a clone "build file" for
> publications.
>
> Each publication has some generic and some specific parts, therefore it
> would probably make sense to do it as follows:
>
>
> .../lenya/bin/clone.xml (for the generic parts)
>
> and
>
> .../lenya/pubs/@PUB@/bin/clone.xml (for the specific parts)
>
> whereas I guess the specific clone.xml imports the generic one (or is it
> the opposite way around).
>
> Anyway, for the beginning we could do this for the default and blog
> publication.
>
> Also I think we should add two new publication instances:
>
> my-default and my-blog where we have slight changes re the layout for
> instance.
>
> Makes sense?
>
> Michi
>
Michi--
Makes a lot of sense. It takes quite a bit of time to clone my blog
publication to my (GrosserHund) publication. Something like that would be
really cool.
+1 (+10 if I could)
--Dale
__________________________________
Do you Yahoo!?
Yahoo! Small Business $15K Web Design Giveaway
http://promotions.yahoo.com/design_giveaway/
---------------------------------------------------------------------
To unsubscribe, e-mail: lenya-dev-unsubscribe@cocoon.apache.org
For additional commands, e-mail: lenya-dev-help@cocoon.apache.org
Re: Odd directory content for default publication
Posted by Michael Wechner <mi...@wyona.com>.
Jean Pierre LeJacq wrote:
>On Tue, 13 Apr 2004, Michael Wechner wrote:
>
>
>
>>Jean Pierre LeJacq wrote:
>>
>>
>>
>>>The default publication contains several directories that don't seem
>>>to make sense. Specifically:
>>>
>>> java
>>>
>>>
>>>
>>Java classes which are specific to the default publication, which are
>>being used within
>>
>>config/menus/generic.xsp
>>config/tasks/tasks.xconf
>>
>>
>
>I see. These are need only during build time, not in the deployed
>directory. Correct?
>
>
the Java classes are being compiled during the build process and added
to the core classes within WEB-INF/classes. Or do you mean the
generic.xsp and tasks.xconf?
btw, have you had chance to further work on the Debian package for Lenya?
--
Michael Wechner
Wyona Inc. - Open Source Content Management - Apache Lenya
http://www.wyona.com http://cocoon.apache.org/lenya/
michael.wechner@wyona.com michi@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: lenya-dev-unsubscribe@cocoon.apache.org
For additional commands, e-mail: lenya-dev-help@cocoon.apache.org
Re: Odd directory content for default publication
Posted by Jean Pierre LeJacq <jp...@quoininc.com>.
On Tue, 13 Apr 2004, Michael Wechner wrote:
> Jean Pierre LeJacq wrote:
>
> >The default publication contains several directories that don't seem
> >to make sense. Specifically:
> >
> > java
> >
> Java classes which are specific to the default publication, which are
> being used within
>
> config/menus/generic.xsp
> config/tasks/tasks.xconf
I see. These are need only during build time, not in the deployed
directory. Correct?
--
JP
---------------------------------------------------------------------
To unsubscribe, e-mail: lenya-dev-unsubscribe@cocoon.apache.org
For additional commands, e-mail: lenya-dev-help@cocoon.apache.org
Re: Odd directory content for default publication
Posted by Michael Wechner <mi...@wyona.com>.
Jean Pierre LeJacq wrote:
>I'm trying to define a minimal template publication starting from
>the default publication since this seems to be the best maintained.
>
>The default publication contains several directories that don't seem
>to make sense. Specifically:
>
> WEB-INF (empty directory structure)
>
>
no clue where this comes from. It seems it once contained a forrest library
> bin (empty)
>
>
the clone build will go in here
> java
>
>
Java classes which are specific to the default publication, which are
being used
within
config/menus/generic.xsp
config/tasks/tasks.xconf
> lenya (mostly empty with a few xsl and xsp)
>
>
the formeditor XSLTs are definitely needed, but there are a lot of other
directories which are certainly not necessary
> test
>
>
webtest
>>>From some limited testing, none seem necessary. Removing them would
>make it easier for someone to understand the default publication.
>
>
agreed, but only the ones which are not necessary ;-)
>If no one objects, I'll file a bug report to have these removed.
>
>
sure
Thanks
Michi
P.S. I am using "update -P" such that I don't see the empty directories
--
Michael Wechner
Wyona Inc. - Open Source Content Management - Apache Lenya
http://www.wyona.com http://cocoon.apache.org/lenya/
michael.wechner@wyona.com michi@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: lenya-dev-unsubscribe@cocoon.apache.org
For additional commands, e-mail: lenya-dev-help@cocoon.apache.org
Odd directory content for default publication
Posted by Jean Pierre LeJacq <jp...@quoininc.com>.
I'm trying to define a minimal template publication starting from
the default publication since this seems to be the best maintained.
The default publication contains several directories that don't seem
to make sense. Specifically:
WEB-INF (empty directory structure)
bin (empty)
java
lenya (mostly empty with a few xsl and xsp)
test
>From some limited testing, none seem necessary. Removing them would
make it easier for someone to understand the default publication.
If no one objects, I'll file a bug report to have these removed.
--
JP
---------------------------------------------------------------------
To unsubscribe, e-mail: lenya-dev-unsubscribe@cocoon.apache.org
For additional commands, e-mail: lenya-dev-help@cocoon.apache.org
Re: Clone Proposal
Posted by Rolf Kulemann <ro...@apache.org>.
On Fri, 2004-04-16 at 09:35, Andreas Hartmann wrote:
> Rolf Kulemann wrote:
>
> > On Fri, 2004-04-16 at 01:57, Michael Wechner wrote:
> >
> >>[...]
> >>these are two totally different publications and I don't think they
> >>should be merged. As I tried to point in previous emails we should think
> >>about the concept of subpublications, which can be mounted at various nodes.
> >
> >
> > The "subpublication" u are talking about are "modules" in my opinion.
> > Those modules provide crosscutting functionality across publications.
> > But is also ok to call modules subpublications...nice idea
>
> I like the term "modules" even better, because it implies
> reusability. Or what about "plug-ins" (just brainstorming ...)?
Plugins, Modules...what sound better for marketing? I used the term
module since I know those kind of things from other cmss.
>
> > Those modules have to be capable of managing its specific data for many
> > publications. Imagine a news or a newsletter module which can serve
> > multiple publications, which I can think could be needed.
> >
> > IMHO this is what Lenya really needs. I started to follow those ideas
> > and have developed a newsletter and a news module. Those modules are
> > made to be "plugged" into a publication lets say as subpublications.
>
> Is there already some conceptual documentation? I'm sure there
> are some mails in the list, I have to browse it again after 1.2
> is released.
No conceptual docs yet, but the code...
The problem is have some deadlines and projects which need my "modules".
The concept is still evolving. The both modules I have, have lots of
things in common and some things not. I.e. the sitemap hooks for the
default pub, auto mounting of modules and some fallbacks for xslts and
stuff is common.
But one module uses webdav rep. the other hdsqlb....so after my
deadlines I will try to do some conceptual docs. Sorry.
>
> > Those modules have the requirement to access workflow and publication
> > mechanisms as well as notification etc.
> >
> > To make my module dream come true (btw. they already do a good job for
> > me) is a better publication API, easier accessible workflow
>
> What do you have in mind here? The new publication API will
> support a more direct access to workflow (resource.triggerWorkflow()).
Yes, exactly that kind of stuff. But maybe each module has its own
workflow i.e. the workflow for news has 2 states and the one for normal
docs three...or so.
>
> > and no more
> > direct acting on the filesystem. IMHO we should at least act on sources.
> >
> > The problem at the mom is, my modules are NOT yet connected to workflow
> > and use their own storage (webdav). I hope I can merge it in the future.
> > I also thought about avalonizing Lenya a bit (splitt into blocks??), but
> > this is maybe a bit off topic. I could think of a publication component
> > as well as of a workflow component...easy to use from inside flow...
>
> This is certainly worth a discussion.
Yes. Imagine my news module which needs to publish a news item or
triggers the workflow after edit. The news module is mainly done in
javascript accessing direct a repository. I want my module to use a more
general publication and workflow layer.
<code>
var pubMgr = cocoon.getComponent(PublicationManager.ROLE);
var wfMgr = = cocoon.getComponent(WFManager.ROLE);
and/or
wfMgr.getWF(NewsModuleIdentifier);
</code>
or sth like that dunno exactly at the mom.
--
Regards,
Rolf Kulemann
---------------------------------------------------------------------
To unsubscribe, e-mail: lenya-dev-unsubscribe@cocoon.apache.org
For additional commands, e-mail: lenya-dev-help@cocoon.apache.org
Re: Clone Proposal
Posted by Andreas Hartmann <an...@apache.org>.
Rolf Kulemann wrote:
> On Fri, 2004-04-16 at 01:57, Michael Wechner wrote:
>
>>[...]
>>these are two totally different publications and I don't think they
>>should be merged. As I tried to point in previous emails we should think
>>about the concept of subpublications, which can be mounted at various nodes.
>
>
> The "subpublication" u are talking about are "modules" in my opinion.
> Those modules provide crosscutting functionality across publications.
> But is also ok to call modules subpublications...nice idea
I like the term "modules" even better, because it implies
reusability. Or what about "plug-ins" (just brainstorming ...)?
> Those modules have to be capable of managing its specific data for many
> publications. Imagine a news or a newsletter module which can serve
> multiple publications, which I can think could be needed.
>
> IMHO this is what Lenya really needs. I started to follow those ideas
> and have developed a newsletter and a news module. Those modules are
> made to be "plugged" into a publication lets say as subpublications.
Is there already some conceptual documentation? I'm sure there
are some mails in the list, I have to browse it again after 1.2
is released.
> Those modules have the requirement to access workflow and publication
> mechanisms as well as notification etc.
>
> To make my module dream come true (btw. they already do a good job for
> me) is a better publication API, easier accessible workflow
What do you have in mind here? The new publication API will
support a more direct access to workflow (resource.triggerWorkflow()).
> and no more
> direct acting on the filesystem. IMHO we should at least act on sources.
>
> The problem at the mom is, my modules are NOT yet connected to workflow
> and use their own storage (webdav). I hope I can merge it in the future.
> I also thought about avalonizing Lenya a bit (splitt into blocks??), but
> this is maybe a bit off topic. I could think of a publication component
> as well as of a workflow component...easy to use from inside flow...
This is certainly worth a discussion.
> But what is done are sitemap hooks for the default pub, simple woody
> integration, versioning. Still a lot of work to do.
>
> Im very interested to get more cms functionality into the defaultpub or
> maybe pub independent as I described.
>
> This should not sound geek but is sth. I'm working on and sth. I need
> for my personal projects.
>
> Michi, maybe its worth a doc where we/u explain what a publication is
> and what not, with possible sample scenarios.
+1
-- Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: lenya-dev-unsubscribe@cocoon.apache.org
For additional commands, e-mail: lenya-dev-help@cocoon.apache.org
Re: Clone Proposal
Posted by Rolf Kulemann <ro...@apache.org>.
On Fri, 2004-04-16 at 01:57, Michael Wechner wrote:
> [...]
> these are two totally different publications and I don't think they
> should be merged. As I tried to point in previous emails we should think
> about the concept of subpublications, which can be mounted at various nodes.
The "subpublication" u are talking about are "modules" in my opinion.
Those modules provide crosscutting functionality across publications.
But is also ok to call modules subpublications...nice idea
Those modules have to be capable of managing its specific data for many
publications. Imagine a news or a newsletter module which can serve
multiple publications, which I can think could be needed.
IMHO this is what Lenya really needs. I started to follow those ideas
and have developed a newsletter and a news module. Those modules are
made to be "plugged" into a publication lets say as subpublications.
Those modules have the requirement to access workflow and publication
mechanisms as well as notification etc.
To make my module dream come true (btw. they already do a good job for
me) is a better publication API, easier accessible workflow and no more
direct acting on the filesystem. IMHO we should at least act on sources.
The problem at the mom is, my modules are NOT yet connected to workflow
and use their own storage (webdav). I hope I can merge it in the future.
I also thought about avalonizing Lenya a bit (splitt into blocks??), but
this is maybe a bit off topic. I could think of a publication component
as well as of a workflow component...easy to use from inside flow...
But what is done are sitemap hooks for the default pub, simple woody
integration, versioning. Still a lot of work to do.
Im very interested to get more cms functionality into the defaultpub or
maybe pub independent as I described.
This should not sound geek but is sth. I'm working on and sth. I need
for my personal projects.
Michi, maybe its worth a doc where we/u explain what a publication is
and what not, with possible sample scenarios. Maybe I have mixed things
up here as well. Please correct me if I'm wrong.
--
Regards,
Rolf Kulemann
---------------------------------------------------------------------
To unsubscribe, e-mail: lenya-dev-unsubscribe@cocoon.apache.org
For additional commands, e-mail: lenya-dev-help@cocoon.apache.org
Re: Clone Proposal
Posted by "Gregor J. Rothfuss" <gr...@apache.org>.
Andreas Hartmann wrote:
> I share this opinion. Could we write it down on the documentation
> index page (http://cocoon.apache.org/lenya/docs/index.html)?
> Maybe a simple diagram would also help.
+1 on opinion and diagrams. we throw around lenya-specific terms here
that newbies may have trouble with.
>> these are two totally different publications and I don't think they
>> should be merged. As I tried to point in previous emails we should
>> think about the concept of subpublications, which can be mounted at
>> various nodes.
+1
i have recently done quite some experimenting with mod_proxy which led
me to some ideas how to organize lenya publications. there is a mount
point concept in publication.xconf that i need to document ..
--
Gregor J. Rothfuss
Wyona Inc. - Open Source Content Management - Apache Lenya
http://wyona.com http://cocoon.apache.org/lenya
gregor.rothfuss@wyona.com gregor@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: lenya-dev-unsubscribe@cocoon.apache.org
For additional commands, e-mail: lenya-dev-help@cocoon.apache.org
Re: Clone Proposal
Posted by Andreas Hartmann <an...@apache.org>.
Michael Wechner wrote:
[...]
> Maybe we need to explain the concept of Lenya better. The default
> publication is NOT Lenya and I think it's a
> very bad idea to make people believe this. Lenya consist out of the
> *Lenya core*, which I consider as a
> Content Management Framenwork and the *Lenya publications*, which each
> could be considered as a specific CMS
> (whatever that means)
I share this opinion. Could we write it down on the documentation
index page (http://cocoon.apache.org/lenya/docs/index.html)?
Maybe a simple diagram would also help.
>> As the blog publication is quite different (and interesting, too) I
>> would suggest to merge blog with default.
>
> these are two totally different publications and I don't think they
> should be merged. As I tried to point in previous emails we should think
> about the concept of subpublications, which can be mounted at various
> nodes.
+1
Let's discuss that again when 1.2 is released.
Thanks for your clarifying statements!
-- Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: lenya-dev-unsubscribe@cocoon.apache.org
For additional commands, e-mail: lenya-dev-help@cocoon.apache.org
Re: Clone Proposal
Posted by Michael Wechner <mi...@wyona.com>.
Markus Vaterlaus wrote:
>
> Hi all,
>
> while reading this, it came to my mind, that we should avoid to use -
> and therefore maintain - to many publications (and instances of them).
> I think it would be easier just to maintain one demo publication,
> however with more depth. This means with more documenttypes (at least
> one more) than default has today.
I really don't think this is a good idea. I think it's much better to
provide parallel to "default" a "my-default" with an
additional document type and a different layout, or for instance a
"wiki" publication based on the default publication,
whereas both "my-default" and "wiki" can be clones of the default or
some other publication.
Maybe we need to explain the concept of Lenya better. The default
publication is NOT Lenya and I think it's a
very bad idea to make people believe this. Lenya consist out of the
*Lenya core*, which I consider as a
Content Management Framenwork and the *Lenya publications*, which each
could be considered as a specific CMS
(whatever that means)
> As the blog publication is quite different (and interesting, too) I
> would suggest to merge blog with default.
these are two totally different publications and I don't think they
should be merged. As I tried to point in previous emails we should think
about the concept of subpublications, which can be mounted at various nodes.
> The resulting new demo publication features two different doctypes
> with their specific workflows.
the original default publication had two different doctypes, but which
were too similar and hence one
was obsolete. Again we can do this by offering a "my-default"
publication which offers such an additional
doctype, e.g. DocBook or NITF or a Wiki-DocType
(http://www.xml.com/pub/a/2004/03/03/sgmlwiki.html)
> However, an intelligent mechanism to support easy cloning of
> publications would be appreciated.
yes, we are working on it. I hope to be able to check in something next
week.
Michi
>
> Sorry, think, I'm a bit OT
>
> --mv
>
>> Clone is sufficient for the first point but not really for the
>> second. Instead of cloning, I recommend just a simple template
>> publication with only the mandatory files and directory structure.
>> Its then relatively simple to use a SCM to keep existing
>> publications in sync with the Lenya standard template using
>> branches.
>>
>> --
>> JP
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: lenya-dev-unsubscribe@cocoon.apache.org
>> For additional commands, e-mail: lenya-dev-help@cocoon.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: lenya-dev-unsubscribe@cocoon.apache.org
> For additional commands, e-mail: lenya-dev-help@cocoon.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: lenya-dev-unsubscribe@cocoon.apache.org
For additional commands, e-mail: lenya-dev-help@cocoon.apache.org
Re: Clone Proposal
Posted by Markus Vaterlaus <mv...@mus.ch>.
Am 13.04.2004 um 23:38 schrieb Jean Pierre LeJacq:
> On Tue, 13 Apr 2004, Michael Wechner wrote:
>
>> Each publication has some generic and some specific parts, therefore
>> it
>> would probably make sense to do it as follows:
>>
>> ...
>>
>> Also I think we should add two new publication instances:
>>
>> my-default and my-blog where we have slight changes re the layout for
>> instance.
>
> This would be a good step forward, but it doesn't meet all the
> requirements that I have:
>
> * Simple starting point (template) for a new publication.
>
> * Ability to synchronize existing publication as the template
> evolves.
>
Hi all,
while reading this, it came to my mind, that we should avoid to use -
and therefore maintain - to many publications (and instances of them).
I think it would be easier just to maintain one demo publication,
however with more depth. This means with more documenttypes (at least
one more) than default has today. As the blog publication is quite
different (and interesting, too) I would suggest to merge blog with
default. The resulting new demo publication features two different
doctypes with their specific workflows. However, an intelligent
mechanism to support easy cloning of publications would be appreciated.
Sorry, think, I'm a bit OT
--mv
> Clone is sufficient for the first point but not really for the
> second. Instead of cloning, I recommend just a simple template
> publication with only the mandatory files and directory structure.
> Its then relatively simple to use a SCM to keep existing
> publications in sync with the Lenya standard template using
> branches.
>
> --
> JP
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: lenya-dev-unsubscribe@cocoon.apache.org
> For additional commands, e-mail: lenya-dev-help@cocoon.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: lenya-dev-unsubscribe@cocoon.apache.org
For additional commands, e-mail: lenya-dev-help@cocoon.apache.org
Re: Clone Proposal
Posted by Michael Wechner <mi...@wyona.com>.
Jean Pierre LeJacq wrote:
>On Tue, 13 Apr 2004, Michael Wechner wrote:
>
>
>
>>Each publication has some generic and some specific parts, therefore it
>>would probably make sense to do it as follows:
>>
>>...
>>
>>Also I think we should add two new publication instances:
>>
>>my-default and my-blog where we have slight changes re the layout for
>>instance.
>>
>>
>
>This would be a good step forward, but it doesn't meet all the
>requirements that I have:
>
>* Simple starting point (template) for a new publication.
>
>* Ability to synchronize existing publication as the template
> evolves.
>
>Clone is sufficient for the first point but not really for the
>second.
>
agreed, but the idea is to use the clone actually for the syncronizing
as well,
so maybe clone is not such a good word. Also in some cases some files only
need to be patched at certain places and don't need to be overwritten
entirely.
Mozilla is using overlays. I am not sure if this is better than just
plain XSLTs.
I guess we will figure out when we make some progress.
> Instead of cloning, I recommend just a simple template
>publication with only the mandatory files and directory structure.
>Its then relatively simple to use a SCM to keep existing
>publications in sync with the Lenya standard template using
>branches.
>
>
>
--
Michael Wechner
Wyona Inc. - Open Source Content Management - Apache Lenya
http://www.wyona.com http://cocoon.apache.org/lenya/
michael.wechner@wyona.com michi@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: lenya-dev-unsubscribe@cocoon.apache.org
For additional commands, e-mail: lenya-dev-help@cocoon.apache.org
Re: Clone Proposal
Posted by Jean Pierre LeJacq <jp...@quoininc.com>.
On Tue, 13 Apr 2004, Michael Wechner wrote:
> Each publication has some generic and some specific parts, therefore it
> would probably make sense to do it as follows:
>
> ...
>
> Also I think we should add two new publication instances:
>
> my-default and my-blog where we have slight changes re the layout for
> instance.
This would be a good step forward, but it doesn't meet all the
requirements that I have:
* Simple starting point (template) for a new publication.
* Ability to synchronize existing publication as the template
evolves.
Clone is sufficient for the first point but not really for the
second. Instead of cloning, I recommend just a simple template
publication with only the mandatory files and directory structure.
Its then relatively simple to use a SCM to keep existing
publications in sync with the Lenya standard template using
branches.
--
JP
---------------------------------------------------------------------
To unsubscribe, e-mail: lenya-dev-unsubscribe@cocoon.apache.org
For additional commands, e-mail: lenya-dev-help@cocoon.apache.org