You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@lenya.apache.org by jw...@apache.org on 2005/04/13 09:31:58 UTC
svn commit: r161162 -
lenya/trunk/src/java/org/apache/lenya/cms/site/usecases/Create.java
lenya/trunk/src/java/org/apache/lenya/cms/site/usecases/CreateDocument.java
Author: jwkaltz
Date: Wed Apr 13 00:31:55 2005
New Revision: 161162
URL: http://svn.apache.org/viewcvs?view=rev&rev=161162
Log:
[minor change] use already available publication instead of lookup
Modified:
lenya/trunk/src/java/org/apache/lenya/cms/site/usecases/Create.java (contents, props changed)
lenya/trunk/src/java/org/apache/lenya/cms/site/usecases/CreateDocument.java
Modified: lenya/trunk/src/java/org/apache/lenya/cms/site/usecases/Create.java
URL: http://svn.apache.org/viewcvs/lenya/trunk/src/java/org/apache/lenya/cms/site/usecases/Create.java?view=diff&r1=161161&r2=161162
==============================================================================
--- lenya/trunk/src/java/org/apache/lenya/cms/site/usecases/Create.java (original)
+++ lenya/trunk/src/java/org/apache/lenya/cms/site/usecases/Create.java Wed Apr 13 00:31:55 2005
@@ -1,5 +1,5 @@
/*
- * Copyright 1999-2004 The Apache Software Foundation
+ * Copyright 1999-2005 The Apache Software Foundation
*
* Licensed under the Apache License, Version 2.0 (the "License");
* you may not use this file except in compliance with the License.
@@ -46,7 +46,7 @@
/**
* Abstract superclass for usecases to create a resource.
*
- * @version $Id: Create.java 123982 2005-01-03 15:01:19Z andreas $
+ * @version $Id$
*/
public abstract class Create extends AbstractUsecase {
@@ -212,6 +212,15 @@
private Publication publication;
+ /**
+ * Access to the current publication.
+ * Use this when the publication is not yet known in the usecase:
+ * e.g. when creating a global asset. When adding a resource or a child
+ * to a document, access the publication via that document's interface
+ * instead.
+ *
+ * @return the publication in which the use-case is being executed
+ */
protected Publication getPublication() {
if (this.publication == null) {
PublicationFactory factory = PublicationFactory.getInstance(getLogger());
@@ -223,4 +232,4 @@
}
return this.publication;
}
-}
\ No newline at end of file
+}
Propchange: lenya/trunk/src/java/org/apache/lenya/cms/site/usecases/Create.java
------------------------------------------------------------------------------
svn:keywords = Id
Modified: lenya/trunk/src/java/org/apache/lenya/cms/site/usecases/CreateDocument.java
URL: http://svn.apache.org/viewcvs/lenya/trunk/src/java/org/apache/lenya/cms/site/usecases/CreateDocument.java?view=diff&r1=161161&r2=161162
==============================================================================
--- lenya/trunk/src/java/org/apache/lenya/cms/site/usecases/CreateDocument.java (original)
+++ lenya/trunk/src/java/org/apache/lenya/cms/site/usecases/CreateDocument.java Wed Apr 13 00:31:55 2005
@@ -1,5 +1,5 @@
/*
- * Copyright 1999-2004 The Apache Software Foundation
+ * Copyright 1999-2005 The Apache Software Foundation
*
* Licensed under the Apache License, Version 2.0 (the "License");
* you may not use this file except in compliance with the License.
@@ -31,7 +31,7 @@
/**
* Usecase to create a document.
*
- * @version $Id:$
+ * @version $Id$
*/
public class CreateDocument extends Create {
@@ -51,7 +51,7 @@
setParameter(PARENT_ID, "");
}
- String[] languages = getPublication().getLanguages();
+ String[] languages = parent.getPublication().getLanguages();
setParameter(LANGUAGES, languages);
}
@@ -68,7 +68,7 @@
try {
documentManager = (DocumentManager) this.manager.lookup(DocumentManager.ROLE);
String[] messages = documentManager.canCreate(getDocumentIdentityMap(),
- getPublication(),
+ parent.getPublication(),
getArea(),
parent,
nodeId,
@@ -103,7 +103,8 @@
Publication publication = parent.getPublication();
String area = parent.getArea();
- Document document = parent.getIdentityMap().get(getPublication(),
+
+ Document document = parent.getIdentityMap().get(publication,
area,
documentId,
language);
@@ -138,4 +139,4 @@
protected String getDocumentTypeName() {
return getParameterAsString(DOCUMENT_TYPE);
}
-}
\ No newline at end of file
+}
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@lenya.apache.org
For additional commands, e-mail: commits-help@lenya.apache.org
Re: [trunk] usecases: stateless services or objects ? (Was Re: svn
commit: r161162 - lenya/trunk/src/java/org/apache/lenya/cms/site/usecases/Create.java
lenya/trunk/src/java/org/apache/lenya/cms/site/usecases/CreateDocument.java)
Posted by "Gregor J. Rothfuss" <gr...@apache.org>.
Andreas Hartmann wrote:
>> BTW I wonder what Cocoon does if the continuation is never called. I
>> would suppose the continuation stays active as long as the session
>> exists, along with the objects involved. So that shouldn't be a
>> problem, thx to session timeouts.
i am pretty sure there is a reaper thread that cleans up continuations
after the continuation livetime is up.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: [trunk] usecases: stateless services or objects ? (Was Re: svn
commit: r161162 - lenya/trunk/src/java/org/apache/lenya/cms/site/usecases/Create.java
lenya/trunk/src/java/org/apache/lenya/cms/site/usecases/CreateDocument.java)
Posted by Andreas Hartmann <an...@apache.org>.
J. Wolfgang Kaltz wrote:
> Andreas Hartmann schrieb:
>
>>> (...)
>>> This is an important point - this means all use cases must be
>>> stateless, right ?
>>
>>
>>
>> Yes, I'm afraid this is true. I'm not pleased with the situation, but
>> the only other solution is to avoid implementing usecases as services
>> so they don't have to be released between the views.
>>
>> WDYT?
>
>
> So the question is what is gained from implementing usecases as services
> vs. "normal" Java objects.
[...]
> BTW I wonder what Cocoon does if the continuation is never called. I
> would suppose the continuation stays active as long as the session
> exists, along with the objects involved. So that shouldn't be a problem,
> thx to session timeouts.
I assume this as well, but I'm not sure.
> If we decide that usecases should not be services:
> since access to usecase instances is handled via the UsecaseResolver,
> the UsecaseResolverImpl encapsulates how usecases are initialized, so it
> transparently handles stuff like usecase configuration & logging
> initialization, even if the usecases were not services. Of course this
> would require significant changes to the UsecaseResolverImpl
> implementation.
Yes, IMO this is the major drawback. The initialization of the usecase
handler could be handled by the resolver as a single entry point to
usecase object creation. But the configuration is very convenient using
the Avalon service deployment in cocoon.xconf ...
Maybe it would be possible to use a builder class for this purpose?
<component-instance name="edit.forms" logger="lenya.publication"
class="org.apache.lenya.cms.usecases.UsecaseBuilder">
<handler class="org.apache.lenya.cms.editors.forms.FormsEditor"/>
<transaction policy="pessimistic"/>
<view template="edit/forms/forms" menu="false"/>
</component-instance>
The usecase resolver would then delegate the usecase POJO initialization to
the usecase builder. Maybe this is the cleaner solution, we could get rid
of the UsecaseProxy.
-- Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
[trunk] usecases: stateless services or objects ? (Was Re: svn commit:
r161162 - lenya/trunk/src/java/org/apache/lenya/cms/site/usecases/Create.java
lenya/trunk/src/java/org/apache/lenya/cms/site/usecases/CreateDocument.java)
Posted by "J. Wolfgang Kaltz" <ka...@interactivesystems.info>.
Andreas Hartmann schrieb:
>> (...)
>> This is an important point - this means all use cases must be
>> stateless, right ?
>
>
> Yes, I'm afraid this is true. I'm not pleased with the situation, but
> the only other solution is to avoid implementing usecases as services
> so they don't have to be released between the views.
>
> WDYT?
So the question is what is gained from implementing usecases as services
vs. "normal" Java objects.
IIUC (please correct if wrong)
having usecases as services delegates (some) responsibility for object
lifecycle, configuration, logging initialization to Avalon. We retrieve
usecase instances by going through the UsecaseResolver (which is a
service). Its implementation currently relies on Avalon service
selection; which is as it should be since the usecases are also
services. The configuration of the usecases is specified in the cocoon.xconf
The problem is the following: when the user requests a (multiple-step)
use-case, a service instance for the use-case is created to handle the
first step. But, since we don't know whether the user will properly
complete the use-case (by pressing save or cancel), the service instance
is released right away. For the next step of the usecase, a usecase
instance is recreated via the UsecaseProxy, which resets all original
parameters - but not field values, obviously. So this means the usecase
implementations must be stateless. We do this so that no dead service
instances lie around; which, especially accumulated over the lifetime of
the servlet container, would hold system resources.
If the usecase wasn't a service, but just a normal Java object retrieved
in the flowscript, Cocoon would handle its state between the views, and
the object reference would disappear at the end of the flow (so it can
be removed by the garbage container sometime after that). So in this
case, the usecases could hold state.
BTW I wonder what Cocoon does if the continuation is never called. I
would suppose the continuation stays active as long as the session
exists, along with the objects involved. So that shouldn't be a problem,
thx to session timeouts.
If we decide that usecases should not be services:
since access to usecase instances is handled via the UsecaseResolver,
the UsecaseResolverImpl encapsulates how usecases are initialized, so it
transparently handles stuff like usecase configuration & logging
initialization, even if the usecases were not services. Of course this
would require significant changes to the UsecaseResolverImpl implementation.
Personally I'm not sure ATM what approach is best; though requiring
usecases to be stateless does seem quite constraining (and risky), so
that would favor not having usecases as services.
Wolfgang
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: svn commit: r161162 - lenya/trunk/src/java/org/apache/lenya/cms/site/usecases/Create.java
lenya/trunk/src/java/org/apache/lenya/cms/site/usecases/CreateDocument.java
Posted by Andreas Hartmann <an...@apache.org>.
J. Wolfgang Kaltz wrote:
> Andreas Hartmann schrieb:
>
>> jwkaltz@apache.org wrote:
>>
>>> Author: jwkaltz
>>> Date: Wed Apr 13 00:31:55 2005
>>> New Revision: 161162
>>>
>>> URL: http://svn.apache.org/viewcvs?view=rev&rev=161162
>>> Log:
>>> [minor change] use already available publication instead of lookup
>>
>>
>>
>> We have to be careful here. The usecase is disposed and re-initialized
>> between the views. The parameters are stored by the UsecaseProxy and
>> handed back to the usecase after re-creation. All field values are lost.
>
>
> This is an important point - this means all use cases must be stateless,
> right ?
Yes, I'm afraid this is true. I'm not pleased with the situation, but
the only other solution is to avoid implementing usecases as services
so they don't have to be released between the views.
WDYT?
> I wonder if we can use some mechanism to enforce that.
That would certainly be helpful. The only thing that comes into my
mind is reflection.
>> I don't know if this will cause problems within the Create usecase, I
>> just
>> wanted to state the problem.
>
>
> In this particular case the change was to use the parent's reference to
> the publication, which already exists,
Maybe this was a remnant from the days before stateless usecases ...
We'll see if any problems occur :)
-- Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: svn commit: r161162 - lenya/trunk/src/java/org/apache/lenya/cms/site/usecases/Create.java
lenya/trunk/src/java/org/apache/lenya/cms/site/usecases/CreateDocument.java
Posted by "J. Wolfgang Kaltz" <ka...@interactivesystems.info>.
Andreas Hartmann schrieb:
> jwkaltz@apache.org wrote:
>
>> Author: jwkaltz
>> Date: Wed Apr 13 00:31:55 2005
>> New Revision: 161162
>>
>> URL: http://svn.apache.org/viewcvs?view=rev&rev=161162
>> Log:
>> [minor change] use already available publication instead of lookup
>
>
> We have to be careful here. The usecase is disposed and re-initialized
> between the views. The parameters are stored by the UsecaseProxy and
> handed back to the usecase after re-creation. All field values are lost.
This is an important point - this means all use cases must be stateless,
right ?
I wonder if we can use some mechanism to enforce that.
>
> I don't know if this will cause problems within the Create usecase, I just
> wanted to state the problem.
In this particular case the change was to use the parent's reference to
the publication, which already exists, instead of re-creating a
publication reference. So shouldn't have anything to do with the issue
above.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: svn commit: r161162 - lenya/trunk/src/java/org/apache/lenya/cms/site/usecases/Create.java
lenya/trunk/src/java/org/apache/lenya/cms/site/usecases/CreateDocument.java
Posted by Andreas Hartmann <an...@apache.org>.
jwkaltz@apache.org wrote:
> Author: jwkaltz
> Date: Wed Apr 13 00:31:55 2005
> New Revision: 161162
>
> URL: http://svn.apache.org/viewcvs?view=rev&rev=161162
> Log:
> [minor change] use already available publication instead of lookup
We have to be careful here. The usecase is disposed and re-initialized
between the views. The parameters are stored by the UsecaseProxy and
handed back to the usecase after re-creation. All field values are lost.
I don't know if this will cause problems within the Create usecase, I just
wanted to state the problem.
-- Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org