You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lenya.apache.org by Andreas Hartmann <an...@apache.org> on 2005/01/20 15:09:49 UTC
Wrap RevisionController with publication-specific API?
Hi Lenya developers,
the current implementation of the RevisionController requrires
the knowledge of some directories:
/**
* Creates a new RevisionController object.
*
* @param rcmlDirectory The directory for the RCML files
* @param backupDirectory The directory for the backup versions
* @param rootDirectory The publication directory
*/
public RevisionController(String rcmlDirectory,
String backupDirectory,
String rootDirectory) {
ATM, these directories are configured in targets.xml:
<property name="rcml.dir" value="content/rcml"/>
<property name="rcbak.dir" value="content/rcbak"/>
When I want to call the revision controller from a usecase handler,
what would be the most elegant way to obtain these directories?
1) Can we assume that every publication uses the same RC directory
configuration?
2) Would it make sense to add a publication-API specific constructor
to the RevisionController?
a) public RevisionController(Document document)
or
b) public RevisionController(Publication publication)
(I think (a) is quite appropriate)
3) Or would it make more sense to put the RC directory knowledge
into the Publication interface? That would have the advantage
that the revision controller is completely independent from
the Lenya API.
The main difference between (2) and (3) is if we want to have
something like a facade (3):
+------------------+ +-------------+
| Publication Core |---->| component A |
| | +-------------+
Client ---->| |
| | +-------------+
| |---->| component B |
| | +-------------+
| |
+------------------+
or rather a set of components with publication-specific knowledge (2).
The workflow engine uses a combination of the two approaches:
+-----------------+ +-----------------+
Client ----->|Lenya-specific WF|-------->|Generic WF engine|
|component | extends | |
+-----------------+ +-----------------+
I think that's not the worst choice. In case of the revision
controller this would mean
public class DocumentRevisionController extends RevisionController {
public DocumentRevisionController(Document document) {
super(document.getPublication().getDirectory(...) ...);
}
}
The disadvantage of this solution is that we use inheritance
in favor of delegation which is generally not recommended ...
Additionally, we have to determine an entry point to obtain the
revision controller. Regarding the workflow, there's no really
elegant solution yet (WorkflowFactory).
WDYT?
-- Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: Set the date of publication and the publisher
Posted by Edith Chevrier <ed...@wyona.com>.
Gregor J. Rothfuss wrote:
> Edith Chevrier wrote:
>
>> Hi,
>>
>> at the moment, in the default publication, the date of publication
>> and the publisher are not set when a document is published. I would
>> like to commit this feature, first in lenya-1.2.
>
>
> makes sense (also for trunk)
>
>> Before the document is published, it should be checked out and
>> checked in. So we come back to the dicussion on the Revision
>> Controller and the lenya API :).
>
>
> is there an open issue in bugzilla about this? what happens today when
> you publish?
Today only the document is published and the workflow is set. The meta
are in the document, but not used. There are no open issue in bugzilla
but i can make one :), because i think its a nice feature that should be
in lenya-1.2.
>
>> In lenya-1.2, i think the Document should have the necessary methods
>> checkIn() and checkOut() and get itself the RevisionController. This
>> logic seems also consistent with jackrabbit. Consequently the
>> Document Interface should be changed. I m not sure that everybody
>> will be happy with this changement. As alternative i can implement
>> in the PublicationTask the methods checkIn(Document document),
>> checkOut(Document document). It depends on which future we want to
>> give to lenya -1.2.*
>
>
> how about adding getRevisionController() to the Document interface
> instead? i would be very careful of extending the document interface
> more than necessary.
>
Why? The interface will anyway change without we reach the desired
functionalities. If we change the interface than with the checkIn and
checkOut methods.
> or maybe this should really be in the publication interface, i don't
> know.
>
>> As long as lenya-1.4 isn't based on jackrabbit, i think we should
>> discuss an intermediate solution and then i will commit the new
>> feature in trunc too
>
>
> the publication task is going away in trunk, so i would suggest adding
> it to one of the interfaces
>
The publish task is already away. As intermediate solution i see a
changement of the Document interface too.
--
Edith Chevrier
Wyona Inc. - Open Source Content Management - Apache Lenya
http://wyona.com http://lenya.apache.org
edith.chevrier@wyona.com edith@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: Set the date of publication and the publisher
Posted by "Gregor J. Rothfuss" <gr...@apache.org>.
Edith Chevrier wrote:
> Hi,
>
> at the moment, in the default publication, the date of publication and
> the publisher are not set when a document is published. I would like to
> commit this feature, first in lenya-1.2.
makes sense (also for trunk)
> Before the document is published, it should be checked out and checked
> in. So we come back to the dicussion on the Revision Controller and the
> lenya API :).
is there an open issue in bugzilla about this? what happens today when
you publish?
> In lenya-1.2, i think the Document should have the necessary methods
> checkIn() and checkOut() and get itself the RevisionController. This
> logic seems also consistent with jackrabbit. Consequently the Document
> Interface should be changed. I m not sure that everybody will be happy
> with this changement. As alternative i can implement in the
> PublicationTask the methods checkIn(Document document),
> checkOut(Document document). It depends on which future we want to give
> to lenya -1.2.*
how about adding getRevisionController() to the Document interface
instead? i would be very careful of extending the document interface
more than necessary.
or maybe this should really be in the publication interface, i don't know.
> As long as lenya-1.4 isn't based on jackrabbit, i think we should
> discuss an intermediate solution and then i will commit the new feature
> in trunc too
the publication task is going away in trunk, so i would suggest adding
it to one of the interfaces
--
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: Set the date of publication and the publisher
Posted by "Gregor J. Rothfuss" <gr...@apache.org>.
Andreas Hartmann wrote:
> it is not taken care of releasing the RC component automatically.
> But if you have
>
> document.checkIn()
>
> you can encapsulate the whole RC resolving in a single method.
that is a benefit, indeed. although you could argue that doing that
could be done in a servlet filter.. the hibernate sample uses this approach.
http://wiki.apache.org/cocoon/CocoonAndHibernateTutorial
> One problem is that the document needs a ServiceManager which
> it does not own at the moment, or it needs a way to delegate the
> task to a Serviceable.
>> and after a while, document will have countless methods..
>
> Yes, this is not very nice but IMO it has a minor priority
> compared to an easy-to-use API.
fair enough!
--
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: Set the date of publication and the publisher
Posted by Andreas Hartmann <an...@apache.org>.
Gregor J. Rothfuss wrote:
> Andreas Hartmann wrote:
>
>> That would conform to the Facade approach which hides the RC
>> implementation behind the publication API.
>
>
> hmmm. looking at the Publication interface, i see
>
> getSiteManager
> getDocumentBuilder
>
> what makes you wish to use the facade approach in this case?
Actually I can't tell. Personally, I'd prefer using the service
approach:
RevisionController controller = null;
try {
controller = (RevisionController)
this.manager.lookup(RevisionController.ROLE);
controller.checkIn(document);
}
finally {
if (controller != null) {
this.manager.release(controller);
}
}
If we want to allow different revision controller implementations
for different publications, we can add a resolver:
RevisionControllerResolver resolver = null;
RevisionController controller = null;
try {
resolver = (RevisionControllerResolver)
this.manager.lookup(RevisionControllerResolver.ROLE);
controller = resolver.resolve(document.getPublication());
controller.checkIn(document);
}
finally {
if (resolver != null) {
if (controller != null) {
resolver.release(controller);
}
this.manager.release(resolver);
}
}
That's quite a lot of code for a single checkIn() operation.
If you have
document.getRevisionController()
it is not taken care of releasing the RC component automatically.
But if you have
document.checkIn()
you can encapsulate the whole RC resolving in a single method.
One problem is that the document needs a ServiceManager which
it does not own at the moment, or it needs a way to delegate the
task to a Serviceable.
>> Apparently it is quite similar to the solution being chosen by the
>> Jackrabbit team, so I'm +1 for this approach, at least in 1.4-dev.
>>
>> Would it make sense to summarize the API changes beforehand?
>> checkIn() and checkOut() won't suffice, we'll need methods to obtain
>> the version history etc.
>
>
> and after a while, document will have countless methods..
Yes, this is not very nice but IMO it has a minor priority
compared to an easy-to-use API.
-- Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: Set the date of publication and the publisher
Posted by Edith Chevrier <ed...@wyona.com>.
Gregor J. Rothfuss wrote:
> Andreas Hartmann wrote:
>
>
>> IMO we should keep the API as stable as possible. Adding the methods
>> to the PublicationTask seems sufficient for 1.2, as the Ant task
>> concept is the recommended way to do things there.
>
>
> ok, that buys us time while we talk API for 1.4
>
Ok, i will commit the new feature first only in lenya-1.2. I implement
the checkIn/Out in the PublicationTask.
Edith
--
Edith Chevrier
Wyona Inc. - Open Source Content Management - Apache Lenya
http://wyona.com http://lenya.apache.org
edith.chevrier@wyona.com edith@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: Set the date of publication and the publisher
Posted by "Gregor J. Rothfuss" <gr...@apache.org>.
Andreas Hartmann wrote:
> That would conform to the Facade approach which hides the RC
> implementation behind the publication API.
hmmm. looking at the Publication interface, i see
getSiteManager
getDocumentBuilder
what makes you wish to use the facade approach in this case?
> Apparently it is quite similar to the solution being chosen by the
> Jackrabbit team, so I'm +1 for this approach, at least in 1.4-dev.
>
> Would it make sense to summarize the API changes beforehand?
> checkIn() and checkOut() won't suffice, we'll need methods to obtain
> the version history etc.
and after a while, document will have countless methods..
>> I m not sure that everybody will be happy with this changement. As
>> alternative i can implement in the PublicationTask the methods
>> checkIn(Document document), checkOut(Document document). It depends on
>> which future we want to give to lenya -1.2.*
>
>
> IMO we should keep the API as stable as possible. Adding the methods
> to the PublicationTask seems sufficient for 1.2, as the Ant task
> concept is the recommended way to do things there.
ok, that buys us time while we talk API for 1.4
--
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: Set the date of publication and the publisher
Posted by Andreas Hartmann <an...@apache.org>.
Edith Chevrier wrote:
> Hi,
>
> at the moment, in the default publication, the date of publication and
> the publisher are not set when a document is published. I would like to
> commit this feature, first in lenya-1.2.
> Before the document is published, it should be checked out and checked
> in. So we come back to the dicussion on the Revision Controller and the
> lenya API :).
>
> In lenya-1.2, i think the Document should have the necessary methods
> checkIn() and checkOut() and get itself the RevisionController. This
> logic seems also consistent with jackrabbit. Consequently the Document
> Interface should be changed.
That would conform to the Facade approach which hides the RC
implementation behind the publication API.
Apparently it is quite similar to the solution being chosen by the
Jackrabbit team, so I'm +1 for this approach, at least in 1.4-dev.
Would it make sense to summarize the API changes beforehand?
checkIn() and checkOut() won't suffice, we'll need methods to obtain
the version history etc.
> I m not sure that everybody will be happy
> with this changement. As alternative i can implement in the
> PublicationTask the methods checkIn(Document document),
> checkOut(Document document). It depends on which future we want to give
> to lenya -1.2.*
IMO we should keep the API as stable as possible. Adding the methods
to the PublicationTask seems sufficient for 1.2, as the Ant task
concept is the recommended way to do things there.
-- Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Set the date of publication and the publisher
Posted by Edith Chevrier <ed...@wyona.com>.
Hi,
at the moment, in the default publication, the date of publication and
the publisher are not set when a document is published. I would like to
commit this feature, first in lenya-1.2.
Before the document is published, it should be checked out and checked
in. So we come back to the dicussion on the Revision Controller and the
lenya API :).
In lenya-1.2, i think the Document should have the necessary methods
checkIn() and checkOut() and get itself the RevisionController. This
logic seems also consistent with jackrabbit. Consequently the Document
Interface should be changed. I m not sure that everybody will be happy
with this changement. As alternative i can implement in the
PublicationTask the methods checkIn(Document document),
checkOut(Document document). It depends on which future we want to give
to lenya -1.2.*
As long as lenya-1.4 isn't based on jackrabbit, i think we should
discuss an intermediate solution and then i will commit the new feature
in trunc too
Edith
--
Edith Chevrier
Wyona Inc. - Open Source Content Management - Apache Lenya
http://wyona.com http://lenya.apache.org
edith.chevrier@wyona.com edith@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: Wrap RevisionController with publication-specific API?
Posted by "Gregor J. Rothfuss" <gr...@apache.org>.
Andreas Hartmann wrote:
> Hi Lenya developers,
>
> the current implementation of the RevisionController requrires
> the knowledge of some directories:
> When I want to call the revision controller from a usecase handler,
> what would be the most elegant way to obtain these directories?
>
>
> 1) Can we assume that every publication uses the same RC directory
> configuration?
this is a detail of the rc that should not be exposed. it might change
in the future when the repository takes over rc duties.
> 2) Would it make sense to add a publication-API specific constructor
> to the RevisionController?
>
> a) public RevisionController(Document document)
> or
> b) public RevisionController(Publication publication)
>
> (I think (a) is quite appropriate)
a)
> 3) Or would it make more sense to put the RC directory knowledge
> into the Publication interface? That would have the advantage
> that the revision controller is completely independent from
> the Lenya API.
i do not think that the revision controller needs to be independent from
the lenya API, especially given that jackrabbitt provides a superior
implementation:
http://www.day.com/maven/jsr170/javadocs/jcr-0.16.1-pfd/javax/jcr/version/package-summary.html
i therefore expect our revision controller to go away sooner or later.
in light of jsr 170, it may make sense to ponder how the various jsr
features should interact with the lenya api.
--
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: Wrap RevisionController with publication-specific API?
Posted by Andreas Hartmann <an...@apache.org>.
Jean Pierre LeJacq wrote:
> On Thu, 20 Jan 2005, Andreas Hartmann wrote:
[...]
> I recommend using the Facade Pattern pattern (option 3) though
> I'm not sure that Publication is the correct choice for the
> facade. In general, I would see the Facade as implementing the
> scenarios (maybe the lenya usecases) that a user interface
> provides. This would work nicely with Cocoon forms/flow where we
> would have a separate flowscript for each scenario with one or
> more forms using form binding to interface to the facade. An
> example scenario might be publish a document.
>
> So, modifying your very nice diagram:
>
> +-----------+ +------------+ +------+ +------+ +--------+
> | Web |--->| scenario A |--->| flow |--->| form |--->| facade |
> | Interface | +------------+ +------+ | bind | | |
> --->| | +------+ | |
> | | +------------+ | |
> | |--->| scenario B |---> ... +--------+
> | | +------------+
> | |
> +-----------+
The facade certainly has some benefits, but I'm not sure if it
is sufficient when it comes to the framework character of Lenya.
If we use a facade, we have to rely on the stability of the APIs of
the underlying components:
+------------------+ +--------------+
| facade |---->| component A |
| | +--------------+
pub_1 ---->| |
| | +--------------+
pub_2 ---->| |---->| component A' |
| | +--------------+
| |
+------------------+
Let's assume pub_2 uses a customized version A' of component A
(let's say the access controller). If we use the facade pattern,
pub_2 can't make use of an extended interface of A'. Actually I think
that's the way things should work, but I'm not sure if all
developers agree .... :)
For example: The access controller A' supports authentication for
departements (an additional accreditable). If the facade provides only
getUser() and getMachine() methods, the publication will not get
the chance to obtain the currently authenticated departement.
--------------------
As far as the usecase framework is concerned, your diagram might
look like this:
+-----------+ +-----------+ +--------+
| Web |--->| usecase A |--->| facade |
| Interface | +-----------+ | |
| | | | |
| | +------+ | |
| | | flow | | |
| | +------+ | |
--->| | | | |
| | +-----------+ | |
| |--->| usecase B |--->| |
| | +-----------+ +--------+
| |
+-----------+
One single flowscript is shared by all usecases. Note that there
is no connection from the flowscript to the facade, it acts as a
controller only. I'm aware of the fact that the usecase framework
cannot be used as the base of all kinds of usecases.
I didn't use forms because IMO it is overkill for most of the
typical Lenya usecases. My experience with forms is that they
require a lot of customization if you need something beyond the
typical Username+Password+Address schema. But maybe I just don't
have enough experience. Nevertheless, the usecase framework proved
quite useful up to now :)
Thanks for your comments!
-- Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: Wrap RevisionController with publication-specific API?
Posted by "Gregor J. Rothfuss" <gr...@apache.org>.
Jean Pierre LeJacq wrote:
> Yes and its a good question. I'm not sure how lenya's usecase
> framework should interact with cocoon flow. There's clearly a lot
> of overlap. In general my preference would be to use a more widely
> use facility if possible. In either case, the basic architecture
> pattern would be the same.
http://wiki.apache.org/lenya/UsecaseFramework has the details, and this
is implemented in the trunk today. it does use jx instead of cforms for
the view.
--
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: Wrap RevisionController with publication-specific API?
Posted by Jean Pierre LeJacq <jp...@quoininc.com>.
On Thu, 20 Jan 2005, Gregor J. Rothfuss wrote:
> Jean Pierre LeJacq wrote:
>
> > I recommend using the Facade Pattern pattern (option 3) though
> > I'm not sure that Publication is the correct choice for the
> > facade. In general, I would see the Facade as implementing the
> > scenarios (maybe the lenya usecases) that a user interface
> > provides. This would work nicely with Cocoon forms/flow where we
> > would have a separate flowscript for each scenario with one or
>
> we want to keep the number of flow scripts to an absolute minimum.
> have you considered the usecase framework when you wrote your
> reply?
Yes and its a good question. I'm not sure how lenya's usecase
framework should interact with cocoon flow. There's clearly a lot
of overlap. In general my preference would be to use a more widely
use facility if possible. In either case, the basic architecture
pattern would be the same.
--
JP
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: Wrap RevisionController with publication-specific API?
Posted by "Gregor J. Rothfuss" <gr...@apache.org>.
Jean Pierre LeJacq wrote:
> I recommend using the Facade Pattern pattern (option 3) though
> I'm not sure that Publication is the correct choice for the
> facade. In general, I would see the Facade as implementing the
> scenarios (maybe the lenya usecases) that a user interface
> provides. This would work nicely with Cocoon forms/flow where we
> would have a separate flowscript for each scenario with one or
> more forms using form binding to interface to the facade. An
> example scenario might be publish a document.
>
> So, modifying your very nice diagram:
>
> +-----------+ +------------+ +------+ +------+ +--------+
> | Web |--->| scenario A |--->| flow |--->| form |--->| facade |
> | Interface | +------------+ +------+ | bind | | |
> --->| | +------+ | |
> | | +------------+ | |
> | |--->| scenario B |---> ... +--------+
> | | +------------+
> | |
> +-----------+
we want to keep the number of flow scripts to an absolute minimum. have
you considered the usecase framework when you wrote your reply?
--
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: Wrap RevisionController with publication-specific API?
Posted by Jean Pierre LeJacq <jp...@quoininc.com>.
On Thu, 20 Jan 2005, Andreas Hartmann wrote:
> the current implementation of the RevisionController requrires
> the knowledge of some directories:
>
>
> /**
> * Creates a new RevisionController object.
> *
> * @param rcmlDirectory The directory for the RCML files
> * @param backupDirectory The directory for the backup versions
> * @param rootDirectory The publication directory
> */
> public RevisionController(String rcmlDirectory,
> String backupDirectory,
> String rootDirectory) {
>
>
> ATM, these directories are configured in targets.xml:
>
> <property name="rcml.dir" value="content/rcml"/>
> <property name="rcbak.dir" value="content/rcbak"/>
>
>
> When I want to call the revision controller from a usecase handler,
> what would be the most elegant way to obtain these directories?
>
>
> 1) Can we assume that every publication uses the same RC directory
> configuration?
>
> 2) Would it make sense to add a publication-API specific constructor
> to the RevisionController?
>
> a) public RevisionController(Document document)
> or
> b) public RevisionController(Publication publication)
>
> (I think (a) is quite appropriate)
>
> 3) Or would it make more sense to put the RC directory knowledge
> into the Publication interface? That would have the advantage
> that the revision controller is completely independent from
> the Lenya API.
>
>
> The main difference between (2) and (3) is if we want to have
> something like a facade (3):
>
>
> +------------------+ +-------------+
> | Publication Core |---->| component A |
> | | +-------------+
> Client ---->| |
> | | +-------------+
> | |---->| component B |
> | | +-------------+
> | |
> +------------------+
>
> or rather a set of components with publication-specific knowledge (2).
>
>
> The workflow engine uses a combination of the two approaches:
>
>
>
> +-----------------+ +-----------------+
> Client ----->|Lenya-specific WF|-------->|Generic WF engine|
> |component | extends | |
> +-----------------+ +-----------------+
>
> I think that's not the worst choice. In case of the revision
> controller this would mean
>
> public class DocumentRevisionController extends RevisionController {
>
> public DocumentRevisionController(Document document) {
> super(document.getPublication().getDirectory(...) ...);
> }
>
> }
>
> The disadvantage of this solution is that we use inheritance
> in favor of delegation which is generally not recommended ...
> Additionally, we have to determine an entry point to obtain the
> revision controller. Regarding the workflow, there's no really
> elegant solution yet (WorkflowFactory).
>
> WDYT?
I recommend using the Facade Pattern pattern (option 3) though
I'm not sure that Publication is the correct choice for the
facade. In general, I would see the Facade as implementing the
scenarios (maybe the lenya usecases) that a user interface
provides. This would work nicely with Cocoon forms/flow where we
would have a separate flowscript for each scenario with one or
more forms using form binding to interface to the facade. An
example scenario might be publish a document.
So, modifying your very nice diagram:
+-----------+ +------------+ +------+ +------+ +--------+
| Web |--->| scenario A |--->| flow |--->| form |--->| facade |
| Interface | +------------+ +------+ | bind | | |
--->| | +------+ | |
| | +------------+ | |
| |--->| scenario B |---> ... +--------+
| | +------------+
| |
+-----------+
--
JP
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: Workflow for sitetree editing
Posted by "Gregor J. Rothfuss" <gr...@apache.org>.
Jean Pierre LeJacq wrote:
> I agree. I don't suggest we tackle this. However, as we move to a
> repository, it makes sense to decouple identity from the document's
> current URI. URN might be a nice solution.
you said a while ago that you'd research jsr 170 for its relevance for
site management. did you have a chance to look into that yet? i'd prefer
to use that API than our one-off sitetree api.
--
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: Workflow for sitetree editing
Posted by Jean Pierre LeJacq <jp...@quoininc.com>.
On Thu, 20 Jan 2005, Michael Wechner wrote:
> Jean Pierre LeJacq wrote:
>
> > This is a consequence of the identity of the
> >document being the same as the URI which is probably a mistake.
> >
>
> I think so too and it seems to me that we have to totally
> refactor this, which basically means opening Pandora's box ;-)
I agree. I don't suggest we tackle this. However, as we move to a
repository, it makes sense to decouple identity from the document's
current URI. URN might be a nice solution.
--
JP
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: Workflow for sitetree editing
Posted by Michael Wechner <mi...@wyona.com>.
Jean Pierre LeJacq wrote:
> This is a consequence of the identity of the
>document being the same as the URI which is probably a mistake.
>
I think so too and it seems to me that we have to totally
refactor this, which basically means opening Pandora's box ;-)
Michi
> URN
>would be a better solution.
>
>Is this correct? If so, the only complaint I have is that we should
>provide an option to allow deactivation of all the children of a
>document.
>
>
>
--
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: Workflow for sitetree editing
Posted by Andreas Hartmann <an...@apache.org>.
Gregor J. Rothfuss wrote:
> Jean Pierre LeJacq wrote:
>
>> This is a consequence of the identity of the
>> document being the same as the URI which is probably a mistake. URN
>> would be a better solution.
>
>
> this was chosen because of performance concerns. a site with 100'000
> nodes might be quite slow with a URN lookup. then again, with the
> expertise gained since that call was made (about 2 years ago), this can
> probably be overcome.
>
> interestingly, there is currently a debate on cocoon dev whether URN can
> be user friendly or not. worth a read. (it's the thread [proposal}
> cocoon documentation system)
>
>> Is this correct? If so, the only complaint I have is that we should
>> provide an option to allow deactivation of all the children of a
>> document.
>
>
> this would work the same way as the recursive publishing. andreas, what
> is the status of that feature? has it been integrated into the trunk?
No, not yet. I'll take care of that when I refactor the publish
and deactivate usecases using the usecase framework.
-- Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: Workflow for sitetree editing
Posted by "Gregor J. Rothfuss" <gr...@apache.org>.
Jean Pierre LeJacq wrote:
> That's a great idea. Only on publishing would you need to resolve
> the URNs to URIs. And since URNs are a subset of URIs, they can
> serve as is while in the authoring environment.
if you mean static publishing you are right, otherwise with every request.
--
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: Workflow for sitetree editing
Posted by Jean Pierre LeJacq <jp...@quoininc.com>.
On Thu, 20 Jan 2005, Gregor J. Rothfuss wrote:
> Jean Pierre LeJacq wrote:
>
> > Hmmm, I not sure why this would be necessary. I would think of URNs
> > as representing the identity of a document. You would still use a
> > user friendly URI for accessing it. An analogy would be an IP
> > address versus a DNS name.
>
> if you go to the trouble of introducing URN, you might as well go all
> the way, and use URN for internal links. correspondingly, you'd need a
> mechanism to resolve these. that would have the benefit that links never
> break, and moving things around becomes easy.
That's a great idea. Only on publishing would you need to resolve
the URNs to URIs. And since URNs are a subset of URIs, they can
serve as is while in the authoring environment.
--
JP
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: Workflow for sitetree editing
Posted by "Gregor J. Rothfuss" <gr...@apache.org>.
Jean Pierre LeJacq wrote:
> Hmmm, I not sure why this would be necessary. I would think of URNs
> as representing the identity of a document. You would still use a
> user friendly URI for accessing it. An analogy would be an IP
> address versus a DNS name.
if you go to the trouble of introducing URN, you might as well go all
the way, and use URN for internal links. correspondingly, you'd need a
mechanism to resolve these. that would have the benefit that links never
break, and moving things around becomes easy.
> What I'm doing is using the dublin core source attribute to hold the
> urn of a served document.
ok
--
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: Workflow for sitetree editing
Posted by Jean Pierre LeJacq <jp...@quoininc.com>.
On Thu, 20 Jan 2005, Gregor J. Rothfuss wrote:
> Jean Pierre LeJacq wrote:
>
> > This is a consequence of the identity of the
> > document being the same as the URI which is probably a mistake. URN
> > would be a better solution.
>
> this was chosen because of performance concerns. a site with 100'000
> nodes might be quite slow with a URN lookup. then again, with the
> expertise gained since that call was made (about 2 years ago), this can
> probably be overcome.
>
> interestingly, there is currently a debate on cocoon dev whether URN can
> be user friendly or not. worth a read. (it's the thread [proposal}
> cocoon documentation system)
I zoned out of that thread when it was clear they weren't interested
in lenya :-)
Hmmm, I not sure why this would be necessary. I would think of URNs
as representing the identity of a document. You would still use a
user friendly URI for accessing it. An analogy would be an IP
address versus a DNS name.
What I'm doing is using the dublin core source attribute to hold the
urn of a served document.
--
JP
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: Workflow for sitetree editing
Posted by "Gregor J. Rothfuss" <gr...@apache.org>.
Jean Pierre LeJacq wrote:
> This is a consequence of the identity of the
> document being the same as the URI which is probably a mistake. URN
> would be a better solution.
this was chosen because of performance concerns. a site with 100'000
nodes might be quite slow with a URN lookup. then again, with the
expertise gained since that call was made (about 2 years ago), this can
probably be overcome.
interestingly, there is currently a debate on cocoon dev whether URN can
be user friendly or not. worth a read. (it's the thread [proposal}
cocoon documentation system)
> Is this correct? If so, the only complaint I have is that we should
> provide an option to allow deactivation of all the children of a
> document.
this would work the same way as the recursive publishing. andreas, what
is the status of that feature? has it been integrated into the trunk?
--
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
Workflow for sitetree editing
Posted by Jean Pierre LeJacq <jp...@quoininc.com>.
Hi Devs,
I'm wondering if the workflow for sitetree editing (moving up,
moving down, cut, paste) makes sense or is consistent. Here's what
I observe as the current workflow.
* If the document has been published to the live area, sitetree
editing is disabled.
* The document (and all its children) must be deactivated before
sitetree editing is enabled.
I think this makes sense in that if we allowed sitetree editing of
an activated document, we lose the association between the live and
authoring documents. This is a consequence of the identity of the
document being the same as the URI which is probably a mistake. URN
would be a better solution.
Is this correct? If so, the only complaint I have is that we should
provide an option to allow deactivation of all the children of a
document.
--
JP
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org