You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cocoon.apache.org by Andrzej Jan Taramina <an...@chaeron.com> on 2003/10/17 16:56:54 UTC
Re: Serializing to a request attribute & Database Actions questions....
Steve
> I'm just getting this to work myself... Have you taken a look at the
> modular db samples in 2.1? You'll have to pick your way through the sample;
> there is a lot going on there.
Yup...I have looked at that in detail, and have my first Database Add action
almost working.
> Also this doc shows a one liner about doing what you describe:
>
> http://cocoon.apache.org/2.1/userdocs/actions/database-actions.html
>
> Specifically:
> <table name="user_groups">
> <keys>
> <key name="uid" type="int">
> <mode name="request" type="request">
> <parameter>user_groups.uid</parameter>
> </mode>
> <mode name="attribute" type="attrib">
> <parameter>org.apache.cocoon.components.modules.output.OutputModule:user.uid[0
> ]</parameter>
> </mode>
> </key>
> <key name="gid" type="int" set="master">
> <mode name="request" type="all">
> <parameter>user_groups.gid</parameter>
> </mode>
> </key>
> </keys>
> </table>
What confuses me a bit still is how the modes actually work. It seems that
you can specify multiple modes and then select them, which will in turn cause
the input/output data to be read/written to different places.
In the example above, I'm not sure what the <parameter> tag is doing. Is it
writing a request attribute with the name
"org.apache.cocoon.components.modules.output.OutputModule:user.uid[0" and a
value of that key column?
> An important thing to know is that the mode name corresponds to the input
> module name in the cocoon.xconf file. So with the latest 2.1 code you'd want
> to substitute <mode name="request-attr" above. The mode type can be set to
> "all" to make it work in all cases. What the above does is allow the request
> to contain the attribute user.uid (the modules always return a list - so if
> there is always one field you need index 0) to database field uid in table
> user_groups.
Which mode are you suggesting doing the substitute on, the "request" or the
"attribute" one? And what do the type designators do?
> Unfortunately, that's about all I can help with...
Every little bit helps! Thanks!
Andrzej Jan Taramina
Chaeron Corporation: Enterprise System Solutions
http://www.chaeron.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Serializing to a request attribute & Database Actions questions....
Posted by Andrzej Jan Taramina <an...@chaeron.com>.
Chris:
> > What confuses me a bit still is how the modes actually work. It seems
> that
> > you can specify multiple modes and then select them, which will in turn
> > cause the input/output data to be read/written to different places.
>
> Yes. Only input, though. Output is configured from sitemap.
I finally figured it out with a lot of experimentation, turning on debug
tracing and reading the code.
I guess the real issue in my mind is that the documentation for Modular DB
Actions is not very clear and could use some more clarification and examples.
For example, in a <mode> tag it was not clear what the difference between the
name and the type attributes were.....took some work to figure out that the
@name is the actual input module name you want to use, like request-attr, and
the @type is just an internal label categorizing the mode inside the database
metadata definition. The examples use the same value for both fields which
makes things very confusing. <mode name="request-attr" type="mytype"/> would
have been clearer.
If/when I get the time/inclination I might consider redoing some of the
documentation to be a bit clearer.
Mind you, this is probably the biggest beef I have with Cocoon itself, not
just the DB Modules. It's a phenomenally powerful tool. But with power
comes complexity (or at least many choices) and the documentation SUCKS.
It's fragmented, incomplete and many times forces you to do code-level
debugging.
I believe that this one issue alone is blocking Cocoon from wider adoption.
Andrzej Jan Taramina
Chaeron Corporation: Enterprise System Solutions
http://www.chaeron.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Serializing to a request attribute & Database Actions questions....
Posted by Christian Haul <ha...@informatik.tu-darmstadt.de>.
Andrzej Jan Taramina wrote:
> What confuses me a bit still is how the modes actually work. It seems that
> you can specify multiple modes and then select them, which will in turn cause
> the input/output data to be read/written to different places.
Yes. Only input, though. Output is configured from sitemap.
> In the example above, I'm not sure what the <parameter> tag is doing. Is it
> writing a request attribute with the name
> "org.apache.cocoon.components.modules.output.OutputModule:user.uid[0" and a
> value of that key column?
No, it's reading from it. Output defaults to using the request attribute
output module which adds the "org.apache....OutputModule:" prefix. This
can be configured in cocoon.xconf BTW.
>>An important thing to know is that the mode name corresponds to the input
>>module name in the cocoon.xconf file. So with the latest 2.1 code you'd want
>>to substitute <mode name="request-attr" above. The mode type can be set to
>>"all" to make it work in all cases. What the above does is allow the request
>>to contain the attribute user.uid (the modules always return a list - so if
>>there is always one field you need index 0) to database field uid in table
>>user_groups.
>
>
> Which mode are you suggesting doing the substitute on, the "request" or the
> "attribute" one? And what do the type designators do?
Uh? Don't understand the question.
Chris.
--
C h r i s t i a n H a u l
haul@informatik.tu-darmstadt.de
fingerprint: 99B0 1D9D 7919 644A 4837 7D73 FEF9 6856 335A 9E08
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org