You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@lenya.apache.org by an...@apache.org on 2005/05/25 17:02:50 UTC
svn commit: r178450 -
/lenya/trunk/src/java/org/apache/lenya/cms/usecase/AbstractUsecase.java
Author: andreas
Date: Wed May 25 08:02:49 2005
New Revision: 178450
URL: http://svn.apache.org/viewcvs?rev=178450&view=rev
Log:
[minor change] added some javadocs
Modified:
lenya/trunk/src/java/org/apache/lenya/cms/usecase/AbstractUsecase.java
Modified: lenya/trunk/src/java/org/apache/lenya/cms/usecase/AbstractUsecase.java
URL: http://svn.apache.org/viewcvs/lenya/trunk/src/java/org/apache/lenya/cms/usecase/AbstractUsecase.java?rev=178450&r1=178449&r2=178450&view=diff
==============================================================================
--- lenya/trunk/src/java/org/apache/lenya/cms/usecase/AbstractUsecase.java (original)
+++ lenya/trunk/src/java/org/apache/lenya/cms/usecase/AbstractUsecase.java Wed May 25 08:02:49 2005
@@ -673,6 +673,13 @@
private String exitUsecaseName = null;
private Map exitUsecaseParameters = new HashMap();
+ /**
+ * Sets the exit usecase of this usecase, i.e. the usecase that should be entered when this
+ * usecase is finished.
+ * @param usecaseName The name of the exit usecase.
+ * @param parameters Parameters to pass to the usecase or <code>null</code> if no parameters
+ * should be passed.
+ */
protected void setExitUsecase(String usecaseName, Map parameters) {
this.exitUsecaseName = usecaseName;
if (parameters != null) {
@@ -680,17 +687,21 @@
}
}
+ /**
+ * Returns the query string to access the exit usecase of this usecase.
+ * @return A query string of the form
+ * <code>?lenya.usecase=...&param1=foo&param2=bar</code>.
+ */
protected String getExitUsecaseQueryString() {
String queryString = "";
if (this.exitUsecaseName != null) {
queryString = "?lenya.usecase=" + this.exitUsecaseName;
- for (Iterator i = this.exitUsecaseParameters.keySet().iterator(); i.hasNext(); ) {
+ for (Iterator i = this.exitUsecaseParameters.keySet().iterator(); i.hasNext();) {
String key = (String) i.next();
String value = (String) this.exitUsecaseParameters.get(key);
queryString += "&" + key + "=" + value;
}
- }
- else {
+ } else {
String exitUsecase = getParameterAsString("lenya.exitUsecase");
if (exitUsecase != null && !"".equals(exitUsecase)) {
queryString = "?lenya.usecase=" + exitUsecase;
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@lenya.apache.org
For additional commands, e-mail: commits-help@lenya.apache.org
Re: svn commit: r178450 - /lenya/trunk/src/java/org/apache/lenya/cms/usecase/AbstractUsecase.java
Posted by Andreas Hartmann <an...@apache.org>.
Gregor J. Rothfuss wrote:
> Andreas Hartmann wrote:
>
>>> OK, I should have read the commit mailing list first, sorry about that.
>>
>>
>> No problem, nobody is supposed to read the commit list :)
>
>
> actually, commiters are
Ah, that's good to know.
-- Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: svn commit: r178450 - /lenya/trunk/src/java/org/apache/lenya/cms/usecase/AbstractUsecase.java
Posted by "Gregor J. Rothfuss" <gr...@apache.org>.
Andreas Hartmann wrote:
>> OK, I should have read the commit mailing list first, sorry about that.
>
> No problem, nobody is supposed to read the commit list :)
actually, commiters are
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: svn commit: r178450 - /lenya/trunk/src/java/org/apache/lenya/cms/usecase/AbstractUsecase.java
Posted by Andreas Hartmann <an...@apache.org>.
J. Wolfgang Kaltz wrote:
> J. Wolfgang Kaltz schrieb:
>
>> Andreas Hartmann schrieb:
[...]
>> Do you mean that the exit-usecase is sometimes a dynamic thing, or are
>> you referring to other types of parameters ?
>> Please give an example :)
>
>
> OK, I should have read the commit mailing list first, sorry about that.
No problem, nobody is supposed to read the commit list :)
> IIUC you meant that the knowledge of which usecase to go upon exit is
> not always sufficient; in some cases you need to pass a parameter as
> well so that the request can be built correctly. For example, after the
> "add group usecase" we want to go to the "group profile" usecase, for
> the group id we just added.
Exactly. I added it to the docs as well (not yet online, only in SVN).
-- Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: svn commit: r178450 - /lenya/trunk/src/java/org/apache/lenya/cms/usecase/AbstractUsecase.java
Posted by "J. Wolfgang Kaltz" <ka...@interactivesystems.info>.
J. Wolfgang Kaltz schrieb:
> Andreas Hartmann schrieb:
>
>> (...)
>> Actually that was my first idea too (with a slightly different syntax):
>>
>> > <component-instance name="admin.deleteGroup" logger="lenya.admin"
>> > class="org.apache.lenya.cms.ac.usecases.DeleteGroup">
>> > <view template="admin/deleteGroup" menu="true"
>> exit-usecase="admin.groups">
>> > <parameter name="tab" value="groups"/>
>> > </view>
>> > </component-instance>
>>
>> But when I noticed that dynamic parameters have to be added in some
>> cases, I realized that we need a Java interface to this functionality
>> anyway.
>
>
> Do you mean that the exit-usecase is sometimes a dynamic thing, or are
> you referring to other types of parameters ?
> Please give an example :)
OK, I should have read the commit mailing list first, sorry about that.
IIUC you meant that the knowledge of which usecase to go upon exit is
not always sufficient; in some cases you need to pass a parameter as
well so that the request can be built correctly. For example, after the
"add group usecase" we want to go to the "group profile" usecase, for
the group id we just added.
--
Wolfgang
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: svn commit: r178450 - /lenya/trunk/src/java/org/apache/lenya/cms/usecase/AbstractUsecase.java
Posted by "J. Wolfgang Kaltz" <ka...@interactivesystems.info>.
Andreas Hartmann schrieb:
> (...)
> Actually that was my first idea too (with a slightly different syntax):
>
> > <component-instance name="admin.deleteGroup" logger="lenya.admin"
> > class="org.apache.lenya.cms.ac.usecases.DeleteGroup">
> > <view template="admin/deleteGroup" menu="true"
> exit-usecase="admin.groups">
> > <parameter name="tab" value="groups"/>
> > </view>
> > </component-instance>
>
> But when I noticed that dynamic parameters have to be added in some
> cases, I realized that we need a Java interface to this functionality
> anyway.
Do you mean that the exit-usecase is sometimes a dynamic thing, or are
you referring to other types of parameters ?
Please give an example :)
>
> I didn't add the configuration option, because I thought that a
> mixture might be confusing.
Hmm, maybe. The usecase configuration we have so far is used in the
flowscript, not in the Java code IIUC. Is this what you mean by a
confusing mixture, if the configuration were also used in the Java code ?
> But maybe it would make sense to configure
> the exit usecase name in cocoon.xconf (which would mean that all usecase
> names are configured there) and the parameters in the Java code
> (parameters are generally declared in the code)?
I guess it depends what the function of the parameters is.
So far the usecase configuration says something about how this usecase
is composed within the CMS (for example, is it part of a group of
usecases). I think the knowledge of "where to go when this usecase is
finished" should also be in the usecase configuration.
(At least, IMO it shouldn't be within the Java implementation, maybe it
should be within a separate "usecase manager configuration file", where
all usecases, how they are assembled, and how they may refer to each
other might be configured; independently of the cocoon.xconf. I don't
think we absolutely need this at this time but maybe a thing to consider
for the future ?)
--
Wolfgang
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: svn commit: r178450 - /lenya/trunk/src/java/org/apache/lenya/cms/usecase/AbstractUsecase.java
Posted by Andreas Hartmann <an...@apache.org>.
J. Wolfgang Kaltz wrote:
[...]
> Regarding the exit usecase :
> would it be possible to configure the exit usecase within the usecase
> configuration, instead of the source code ?
>
> For example, the delete group usecase has this code
> setExitUsecase("admin.groups", null);
> So this means the source code is dependant on the usecase name as
> defined in cocoon.xconf. If we can avoid that, I think we should.
>
> If we could configure it instead in the usecase configuration, for
> example something like
>
> <component-instance name="admin.deleteGroup" logger="lenya.admin"
> class="org.apache.lenya.cms.ac.usecases.DeleteGroup">
> <view template="admin/deleteGroup" menu="true">
> <parameter name="tab" value="groups"/>
> </view>
> <exit name="admin.groups"/>
> </component-instance>
>
> that would avoid the Java code hard-wiring the name of the exit usecase.
> That does make sense or am I missing something ?
Actually that was my first idea too (with a slightly different syntax):
> <component-instance name="admin.deleteGroup" logger="lenya.admin"
> class="org.apache.lenya.cms.ac.usecases.DeleteGroup">
> <view template="admin/deleteGroup" menu="true"
exit-usecase="admin.groups">
> <parameter name="tab" value="groups"/>
> </view>
> </component-instance>
But when I noticed that dynamic parameters have to be added in some
cases, I realized that we need a Java interface to this functionality
anyway.
I didn't add the configuration option, because I thought that a
mixture might be confusing. But maybe it would make sense to configure
the exit usecase name in cocoon.xconf (which would mean that all usecase
names are configured there) and the parameters in the Java code
(parameters are generally declared in the code)?
-- Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: svn commit: r178450 - /lenya/trunk/src/java/org/apache/lenya/cms/usecase/AbstractUsecase.java
Posted by "J. Wolfgang Kaltz" <ka...@interactivesystems.info>.
andreas@apache.org schrieb:
> + /**
> + * Sets the exit usecase of this usecase, i.e. the usecase that should be entered when this
> + * usecase is finished.
> + * @param usecaseName The name of the exit usecase.
> + * @param parameters Parameters to pass to the usecase or <code>null</code> if no parameters
> + * should be passed.
> + */
> protected void setExitUsecase(String usecaseName, Map parameters) {
Regarding the exit usecase :
would it be possible to configure the exit usecase within the usecase
configuration, instead of the source code ?
For example, the delete group usecase has this code
setExitUsecase("admin.groups", null);
So this means the source code is dependant on the usecase name as
defined in cocoon.xconf. If we can avoid that, I think we should.
If we could configure it instead in the usecase configuration, for
example something like
<component-instance name="admin.deleteGroup" logger="lenya.admin"
class="org.apache.lenya.cms.ac.usecases.DeleteGroup">
<view template="admin/deleteGroup" menu="true">
<parameter name="tab" value="groups"/>
</view>
<exit name="admin.groups"/>
</component-instance>
that would avoid the Java code hard-wiring the name of the exit usecase.
That does make sense or am I missing something ?
--
Wolfgang
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org